Re: DDNS IESG Issue resolution.
Ted Lemon
turn out to have been constructive. Basically, Sam agrees that it's
unlikely that we will need to change the hash algorithm in the future, but
won't go so far as to say that he's sure we won't.
So what he asked us to do is to put an algorithm identifier on the DHCID, but
not make any other changes (we could change to SHA-1 or SHA-256 as our
initial algorithm, and that might mollify some folks; since it's basically a
search and replace on the document, I think it's worth doing).
The idea is that in the unlikely event that we at some future date need to
change the hash, then AT THAT TIME we write a draft that tells us how to do
updates in the transitional state where more than one hash might still be
present in the DNS. For now, we just put the identifier there and don't
change anything else.
This seems like a reasonable compromise - since we're claiming that we're
never going to need the additional complexity, hopefully this postpones the
work to describe and implement that complexity forever; if it turns out that
we're wrong, we have a path forward.
I can go more into the reasons why we agreed on this particular approach if
anyone's interested, but unless you are, I'll just leave it at that.
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Ralph Droms
Otherwise, sounds like a reasonable compromise. Late binding to pay the
price when we need to solve the problem.
- Ralph
Ralph Droms
- Ralph
On 2/8/06 4:56 PM, "Ted Lemon" <Ted....@nominum.com> wrote:
> On Wednesday 08 February 2006 14:18, Ralph Droms wrote:
>> Are there any export or other restrictions on SHA-1 or SHA-256 at this
>> time?
>
> They're hash algorithms, not encruption algorithms, so while I suppose
> anything's possible, it seems unlikely.
Ted Lemon
Ted Lemon
Ralph Droms
Ralph Droms
Otherwise, sounds like a reasonable compromise. Late binding to pay the
price when we need to solve the problem.
- Ralph
On 2/8/06 4:13 PM, "Ted Lemon" <Ted....@nominum.com> wrote:
> I just had a conversation on the phone with Sam Hartman, which I hope will
> turn out to have been constructive. Basically, Sam agrees that it's
> unlikely that we will need to change the hash algorithm in the future, but
> won't go so far as to say that he's sure we won't.
>
> So what he asked us to do is to put an algorithm identifier on the DHCID, but
> not make any other changes (we could change to SHA-1 or SHA-256 as our
> initial algorithm, and that might mollify some folks; since it's basically a
> search and replace on the document, I think it's worth doing).
>
> The idea is that in the unlikely event that we at some future date need to
> change the hash, then AT THAT TIME we write a draft that tells us how to do
> updates in the transitional state where more than one hash might still be
> present in the DNS. For now, we just put the identifier there and don't
> change anything else.
>
> This seems like a reasonable compromise - since we're claiming that we're
> never going to need the additional complexity, hopefully this postpones the
> work to describe and implement that complexity forever; if it turns out that
> we're wrong, we have a path forward.
>
> I can go more into the reasons why we agreed on this particular approach if
> anyone's interested, but unless you are, I'll just leave it at that.
>
Ted Lemon
Sam Hartman
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
>>>>> "Ted" == Ted Lemon <Ted....@nominum.com> writes:
Ted> So what he asked us to do is to put an algorithm identifier
Ted> on the DHCID, but not make any other changes (we could change
Ted> to SHA-1 or SHA-256 as our initial algorithm, and that might
Ted> mollify some folks; since it's basically a search and replace
Ted> on the document, I think it's worth doing).
I'd also ask you to note that registering new algorithms requires
standards action.
The reason that it would require standards action is that you'd need
to describe the update mechanism at the second registration.
David W. Hankins
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
--zjcmjzIkjQU2rmur
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 08, 2006 at 04:18:07PM -0500, Ralph Droms wrote:
> Are there any export or other restrictions on SHA-1 or SHA-256 at this ti=
me?
ISC DHCP is a consumer of this protocol, I see no reason why it can't
adopt SHA-*.
We already have sources we're familiar with which I understand can be
bent to this purpose.
I have no complaints with this compromise.
--=20
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
--zjcmjzIkjQU2rmur
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD6mVycXeLeWu2vmoRAmvZAJ41NFLFgS9/aUOQZ4WtucgXzQqHvACfbchR
DxFE38DcyY0mrj6WU7aYe6k=
=N4kz
-----END PGP SIGNATURE-----
--zjcmjzIkjQU2rmur--
Ben Laurie
> On Wednesday 08 February 2006 14:18, Ralph Droms wrote:
>> Are there any export or other restrictions on SHA-1 or SHA-256 at this
>
> They're hash algorithms, not encruption algorithms, so while I suppose
> anything's possible, it seems unlikely.
There haven't been troublesome export restrictions even on encryption
for some time - from the US.
But if you are going to worry about export, then you have to bear in
mind that the IETF is international. US export laws are hardly the
issue. There are plenty of jurisdictions where _use_, let alone export,
of crypto is completely illegal.
Also, FWIW, hash algorithms are perfectly usable as encryption algorithms.
Cheers,
Ben.
Alex Bligh
--On 10 February 2006 19:30 +0000 Ben Laurie <b...@algroup.co.uk> wrote:
> Also, FWIW, hash algorithms are perfectly usable as encryption algorithms.
Pardon? One of the features of most hashes is that they are not invertible,
and another features is that the range is far smaller than the domain. I
agree that most encryption algorithms are usable as hash algorithms (as
without the decrypt key, a good encryption algorithm is not invertible) if
a subset of the output range is taken (i.e. a limited number of bits), but
encryption algorithms with a range of less size than their domain are not
in general helpful, so the converse as far as I know is not true.
But we'd all be grateful for the SHA-256 "decryption" algorithm if you
have one!
Alex
Ben Laurie
>
>
> --On 10 February 2006 19:30 +0000 Ben Laurie <b...@algroup.co.uk> wrote:
>
>> Also, FWIW, hash algorithms are perfectly usable as encryption
>> algorithms.
>
> Pardon? One of the features of most hashes is that they are not invertible,
> and another features is that the range is far smaller than the domain. I
> agree that most encryption algorithms are usable as hash algorithms (as
> without the decrypt key, a good encryption algorithm is not invertible) if
> a subset of the output range is taken (i.e. a limited number of bits), but
> encryption algorithms with a range of less size than their domain are not
> in general helpful, so the converse as far as I know is not true.
>
> But we'd all be grateful for the SHA-256 "decryption" algorithm if you
> have one!
I didn't say you could decrypt a hash function, I said you could use one
for encryption.
The construction is known as "Chaffing and Winnowing", was invented by
Ron Rivest, is hugely inefficient and was designed to show the
foolishness of crypto export laws.
http://theory.lcs.mit.edu/~rivest/chaffing.txt
Cheers,
Ben.
Alex Bligh
--On 11 February 2006 18:48 +0000 Ben Laurie <b...@algroup.co.uk> wrote:
>>> Also, FWIW, hash algorithms are perfectly usable as encryption
>>> algorithms.
>>
>> Pardon?
...
> I didn't say you could decrypt a hash function, I said you could use one
> for encryption.
>
> The construction is known as "Chaffing and Winnowing", was invented by
> Ron Rivest, is hugely inefficient and was designed to show the
> foolishness of crypto export laws.
This is merely a semantic point (meaning of the word encryption). Even the
author of the paper explicitly describes both stenography and chaffing &
winnowing as "not employ[ing] encryption".
>From the paper:
There are two major techniques for achieving confidentiality: ...
Stenography ... Encryption ... This paper introduces a new
technique, which we call ``chaffing and winnowing''
Then: "Winnowing does not employ encryption"
His perfectly adequate definition of encryption is:
Encryption: transforming the message to a ciphertext such that
an adversary who overhears the ciphertext can not determine
the message sent. The legitimate receiver possesses a secret
decryption key that allows him to reverse the encryption
transformation and retrieve the message. The sender may have
used the same key to encrypt the message (with symmetric
encryption schemes) or used a different, but related key
(with public-key schemes). DES and RSA are familiar
examples of encryption schemes.
A hash function doesn't do that. Chaffing & winnowing doesn't do that. The
hash/MAC function is just a component of the algorithm here, and is no more
an "encryption" function here than when (say) it is used to produce a
private key from a secret string. If we go this way, addition could be
described as encryption on the basis it's used in just about every
encryption algorithm. The key thing he's doing is adding chaff, PLUS the
original plaintext (wheat), giving a range space FAR larger than the
original domain (as is the case in stenography, under whose bracket
one might argue this technique actually falls).
(and back on topic)
And whilst indeed the point he is making (well) is that that crypto export
laws are dumb, he himself says:
We have the transformation of appending a MAC thus:
packet --> packet, MAC
The packet is still ``in the clear''; no encryption has been
performed. We note that software that merely authenticates
messages by adding MACs is automatically approved for export, as it
is deemed not to encrypt.
So at least this generation of dumb crypto laws do not cover MAC (hash)
functions, which is what was, I think, the original question. Unfortunately
pointing out laws are dumb does not allow us to ignore them.
Alex
Christian Huitema
> >>> Also, FWIW, hash algorithms are perfectly usable as encryption
> >>> algorithms.
> >>
> >> Pardon?
> ...
by
> > Ron Rivest, is hugely inefficient and was designed to show the
> > foolishness of crypto export laws.
> This is merely a semantic point (meaning of the word encryption). Even
the
> author of the paper explicitly describes both stenography and chaffing
&
> winnowing as "not employ[ing] encryption".
Clearly, Ron Rivest's chaffin and winnowing construct is more a gedanken
experiment than a practical tool. However, hash functions can be used to
hide data, using a different construct: generate a bit string by hashing
a shared secret and a random number present in the message, and then XOR
the message text with that bit string. That construct is actually used
in the Radius specification (RFC 2685, section 5.2 "Passords", page 27):
On transmission, the password is hidden. The password is first
padded at the end with nulls to a multiple of 16 octets. A one-
way MD5 hash is calculated over a stream of octets consisting of
the shared secret followed by the Request Authenticator. This
value is XORed with the first 16 octet segment of the password and
placed in the first 16 octets of the String field of the User-
Password Attribute.
The Radius specification used MD5, but that construct can actually be
used with pretty much any hash function.=20
> So at least this generation of dumb crypto laws do not cover MAC
(hash)
> functions, which is what was, I think, the original question.
> Unfortunately
> pointing out laws are dumb does not allow us to ignore them.
Let's say that these laws do not prevent the use of hash functions for
message authentication purposes, and leave it at that.
-- Christian Huitema