Subject: Re: DDNS IESG Issue resolution.

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2006 14:13:19 -0700

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.   

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 08 Feb 2006 16:18:07 -0500

Are there any export or other restrictions on SHA-1 or SHA-256 at this time?

Otherwise, sounds like a reasonable compromise.  Late binding to pay the
price when we need to solve the problem.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2006 14:56:24 -0700

> 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.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 08 Feb 2006 16:58:16 -0500

Agreed,.  Just checking...

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 8 Feb 2006 13:41:06 -0800

> Are there any export or other restrictions on SHA-1 or SHA-256 at this time?

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.

-- 
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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Feb 2006 16:18:11 -0500

[ Moderators note: Post was moderated, either because it was posted by
   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 <[email-masked]> 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.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 10 Feb 2006 19:30:56 +0000

> 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.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 11 Feb 2006 00:06:07 +0000

> 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

---

From: Ben Laurie <[email-masked]>
Date: Sat, 11 Feb 2006 18:48:05 +0000

> But we'd all be grateful for the SHA-256 "decryption" algorithm if you

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.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 11 Feb 2006 19:48:25 +0000

(Rapidly moving off-topic)

--On 11 February 2006 18:48 +0000 Ben Laurie <[email-masked]> wrote:

>> Pardon?
...
> 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

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 12 Feb 2006 09:21:40 -0800

> 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. 

> 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