Subject: RE: [ietf-dkim] Supporting alternate algorithms

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Feb 2006 06:57:43 -0800

SHA256 is a full NIST standard.

Its just suspect because it is based on the SHA1/Md5 technology amd
likely to be replaced 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, February 21, 2006 6:21 PM
> To: Ned Freed
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Supporting alternate algorithms
> 
> Ned Freed wrote:
>  > Exactly so, and given the current hash function situation 
> that algorithm  > needs  > to be SHA-256.
> 
> Is this really the case, or is SHA-256 a sort of generic 
> placeholder for "something better than SHA-1"? I haven't paid 
> very much attention to what the cryptographers have been 
> saying about this, but it doesn't seem clear to me that 
> SHA-256 has been settled on as The short term replacement. Or has it?
> 
> 		Mike
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://dkim.org/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Feb 2006 09:11:09 -0800

> Its just suspect because it is based on the SHA1/Md5 technology amd

   Ok, but that doesn't exactly answer my question. Is it really the
   case that sha-256 will be The annointed successor for the time
   being? Especially in light of the above? Transitions are never
   easy and forcing one might be a cure worse than the disease.

		Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Feb 2006 09:17:31 -0800

>    easy and forcing one might be a cure worse than the disease.

As I understand it, NIST says that SHA-256 is it for the next
few years. Certainly, there's nothing else in the pipeline at
even remotely the same level of development.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 18:26:26 +0100

>   easy and forcing one might be a cure worse than the disease.
It is for now.  That's what the SAAG meeting was all about.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Feb 2006 09:30:20 -0800

> It is for now.  That's what the SAAG meeting was all about.

Well, it's not *exactly* it: there's still SHA-1. Two upgrades
in the space of a few years is going to be painful. Maybe inevitable,
but still painful.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Feb 2006 09:35:01 -0800

> in the space of a few years is going to be painful. Maybe inevitable,

DKIM's base spec already has a mechanism that supports alternate algorithms.

Are there any changes to the mechanism that anyone is suggesting?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 18:37:48 +0100

> Are there any changes to the mechanism that anyone is suggesting?
No, we're still on MUSTs and SHOULDs for which ones.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Feb 2006 09:51:42 -0800

> Are there any changes to the mechanism that anyone is suggesting?

Unless we're resigned to signers generating two signatures in the
interim, it's not quite this simple. There's an inherent chicken/egg
problem with signers only generating the new/better signature.

		Mike

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 09:40:56 -0800 (PST)

> Its just suspect because it is based on the SHA1/Md5 technology amd

Yep, in particular, it's the use of invertible combining functions that have
group structure in the inner loop. The entire family has this in common.

But such weaknesses cut both ways. The properties of this inner loop are well
understood. If, say, we replace the existing operation with a quasigroup
operation (as Gligloroski et al have proposed), we eliminate the existing
attacks but are we sure we haven't introduced a new one in the process?

This is even more of a problem for entirely different designs. Are we sure that
Whirlpool, or Tiger, or FORK-256, or any of the numerous other hashes that have
been proposed won't fall to some entirely new attack? The answer, of course, is
that we don't know until people have analyzed the designs extensively. But if
the past is any indication, most of them will be found to have exploitable
flaws sooner rather than later.

SHA-256 is quite simply the hash people have the most confidence in for now.

Hopefully some day a practical hash function with provable collision resistance
will emerge. (Such functions exist but currently they are too slow to use.)

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Feb 2006 10:07:33 -0800

Folks,

> No, we're still on MUSTs and SHOULDs for which ones.

As I understand the current situation, there are only two candidate algorithms 
being discussed, SHA-1 and SHA-256.  There is also the question of an 
alternative to SHA-256.  The security community's assessment of a preferred 
longer-term choice is underway and will, someday, converge in some formal way.

Until then, we need language in the DKIM specification that a) deals with the 
concerns about SHA-1 at least by allowing specification of alternative 
algorithms, and b) cites at least one other "preferred" algorithm in some 
fashion.  Again, at the moment, I've only seen SHA-256 as the candidate.

We already have satisfied a), with the algorithm-choice mechanism.

As Ned's note this morning has reminded us all:  The key to interoperability is 
defining a core of requirements that everyone must satisfy.

(My unkind response to anyone suggesting that we not satisfy this basic 
requirement is that the IETF is the wrong forum for the work, and they need to 
move to some environment like OSI community had, since it enjoyed creating 
non-interoperable specifications.)

In the case of DKIM, I believe that specifying what a *validator* MUST support 
is all that is essential to ensure interoperability.

That is, if we say that a validator MUST support SHA-1 and SHA-256, we have 
solved the interoperability problem.  A signer that chooses any other algorithm 
risks non-interoperability.  They are free to go down that path, but they had 
better have some basis for the choice.

In other words, we are trying to juggle two different requirements: 
interoperability and security.  The problem is that the latter one is a bit 
fuzzy at the moment. *Better still is that this working group can't resolve it.*

As I say, defining what the validator MUST support solves our requirement to 
ensure an interoperable base.

If we say that a signer SHOULD use SHA-256, then I think we have solved the 
security-strength concerns, for the moment.

If the security community converges on a different preference, prior to our WG 
Last Call for the base, then we can plug in something other than SHA-256.  It's 
a minor change.

However I think the model for the spec language is clear:

    A validator MUST support {SHA-1, SHA-256}.

    A signer SHOULD use {SHA-256}.

We can, of course, add discussion about the trade-offs.  This might lead to the 
somewhat unusual alternative for signer language, along the lines of:

    A signer MAY use {SHA-1} for its lower overhead, in spite of potentially 
reduced security strength.  A signer SHOULD use {SHA-256} for its higher 
security strength.

Ok, folks.  What have I missed?

d/

-- 

Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Wed, 22 Feb 2006 13:20:40 -0500

I vote for Dave's language to be added to ietf-dkim-base.

	Tony

Dave Crocker wrote:
> As I understand the current situation, there are only two candidate
> algorithms being discussed, SHA-1 and SHA-256.  There is also the
> question of an alternative to SHA-256.  The security community's
> assessment of a preferred longer-term choice is underway and will,
> someday, converge in some formal way.
> 
> Until then, we need language in the DKIM specification that a) deals
> with the concerns about SHA-1 at least by allowing specification of
> alternative algorithms, and b) cites at least one other "preferred"
> algorithm in some fashion.  Again, at the moment, I've only seen SHA-256
> as the candidate.
> 
> As Ned's note this morning has reminded us all:  The key to
> interoperability is defining a core of requirements that everyone must
> satisfy.
> 
> requirement is that the IETF is the wrong forum for the work, and they
> need to move to some environment like OSI community had, since it
> enjoyed creating non-interoperable specifications.)
> 
> In the case of DKIM, I believe that specifying what a *validator* MUST
> support is all that is essential to ensure interoperability.
> 
> That is, if we say that a validator MUST support SHA-1 and SHA-256, we
> have solved the interoperability problem.  A signer that chooses any
> other algorithm risks non-interoperability.  They are free to go down
> that path, but they had better have some basis for the choice.
> 
> interoperability and security.  The problem is that the latter one is a
> bit fuzzy at the moment. *Better still is that this working group can't
> resolve it.*
> 
> As I say, defining what the validator MUST support solves our
> requirement to ensure an interoperable base.
> 
> If we say that a signer SHOULD use SHA-256, then I think we have solved
> the security-strength concerns, for the moment.
> 
> If the security community converges on a different preference, prior to
> our WG Last Call for the base, then we can plug in something other than
> SHA-256.  It's a minor change.
> 
> We can, of course, add discussion about the trade-offs.  This might lead
> to the somewhat unusual alternative for signer language, along the lines
> of:
> 
>    A signer MAY use {SHA-1} for its lower overhead, in spite of
> potentially reduced security strength.  A signer SHOULD use {SHA-256}
> for its higher security strength.
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Feb 2006 10:25:31 -0800

On Feb 22, 2006, at 9:35 AM, Dave Crocker wrote:
>
>> Well, it's not *exactly* it: there's still SHA-1. Two upgrades in  
>> the space of a few years is going to be painful. Maybe inevitable,  
>> but still painful.
>

There are two serious issues this problem raises with respect to the  
current mechanism.  A default and MUST accept SHA-1 in the key would  
be one, where typically the hash is only expressed within the  
message.  The use of the TXT RR also precludes an upgrade to the use  
of 2048 bit keys.  There is a simple and immediate remedy for this  
problem.  Rather than adopting the TXT record and expecting defaults  
are okay, both issues are resolved by adopting the use of RFC2538  
RR.  This would allow both a binary image of the public key which  
saves 90 bytes of DNS payload.  At the same time, this RR record also  
explicitly specifies the algorithms by indexing into an industry  
standardized list rather than attempting to express these textually  
where there is insufficient space for doing so.  In short, the  
currently proposed mechanism for changing algorithms needs to be fix.

For an example of this RR being used to obtain the public keys for  
OpenPGP, here are some related links:
http://josefsson.org/cks-dns/
http://sourceforge.net/projects/cks/

-Doug

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 10:27:46 -0800 (PST)

> security-strength concerns, for the moment.

Agreed.

>     A signer SHOULD use {SHA-256}.

This leaves out what the signer MUST support: I believe you need to have a MUST
support SHA-256 in there. I'm ambivalent about whether or not there should be a
signer SHOULD support SHA-1 in there. I figure that signers that want to use
SHA-1 will do so as long as they can be assured of verifier support.

> reduced security strength.  A signer SHOULD use {SHA-256} for its higher

It may be unusual, but I like it.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Feb 2006 10:38:43 -0800

> This leaves out what the signer MUST support: I believe you need to have a
> MUST support SHA-256 in there. I'm ambivalent about whether or not there 
> should be a signer SHOULD support SHA-1 in there. I figure that signers that
> want to use > SHA-1 will do so as long as they can be assured of verifier support.

Indeed, I was struck by that oddness, when I wrote it, too.

As I thought about it more, I realized that I do not know what it means to 
declare a requirement for signer "support", whereas signer "use" is clear.

Stated differently:

      The language for the validator says what incoming bits it has to be able 
to process.

      Equivalently, the language for the signer says what outgoing bits is 
"should" generate.

In that context, I can't figure out what it means to talk about signer "support".

d/
-- 

Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 10:40:18 -0800 (PST)

> declare a requirement for signer "support", whereas signer "use" is clear.

It means that the software implementation supports it as a selectable option.
If you don't say this what's to prevent someone from writing an implementation
that only supports Camilla-MAC hashing and calling it compliant?

> In that context, I can't figure out what it means to talk about signer "support".

Implementation requirements make sense for both ends here.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Feb 2006 10:47:55 -0800

>  If you don't say this what's to prevent someone from writing an 
> implementation that only supports Camilla-MAC hashing and calling it
> compliant?

ok.  understand.

i had completely forgotten the concerns about both marketing and product 
acquisition that the spec needs to cover.

Yes, declaring requirements for core "capabilities" pertains to the 
customer/user activity BEFORE sending any bits.

thanks.

d/

-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 14:25:20 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "Ned Freed" <[email-masked]>; <[email-masked]>

> We can, of course, add discussion about the trade-offs.  This might
> lead to the somewhat unusual alternative for signer language,
> along the lines of:
>
> potentially reduced security strength.  A signer SHOULD use
> {SHA-256} for its higher security strength.
>

Nothing in my view. Since it is a rehash of what I posted this morning:

http://mipassoc.org/pipermail/ietf-dkim/2006q1/002305.html

I agree with this.  I don't understand why it would be unusual. It follows
Postel's Law:

     "Be conservative in what you send, liberal in what you receive."

and IMO, its not really a question of algorithm by the level of strength one
wishes to use.

If one alternative change the above is done, I would probably say:

    A signer HAS the option of using {SHA1, SHA-256} depending
    on the strength it chooses to sign mail with.  The signer
    SHOULD use the highest strength when all possible.

Someone should make a note that a Migration clarification and insight
related this topic will be required.

Also, a possible solution:

- Signer/Validator Capability "Handshake" Logic

A validator can define a SSP-like DNS policy that defines the capabilities
of the validator.

Signers can then have the ability (based on advanced implementation) to
pre-examine a target to see what strength it supports.  This will only work
for a direct transaction (1 to 1, not 1 to many). But it allows for a
client/server "capability handshake" so to speak.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Mark Delany <[email-masked]>
Date: Wed, 22 Feb 2006 19:56:29 +0000

> client/server "capability handshake" so to speak.

And as long as the target doesn't forward or relay through a
non-interactive link.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 22 Feb 2006 14:17:03 -0600

>> implementation that only supports Camilla-MAC hashing and calling it

I understand this concern but as a practical matter who would create a 
signer knowing in advance that it would have trouble inter-operating? 
That would be silly and such a signer wouldn't be in use for very long 
would it?  So, I agree with Tony and don't see a particular problem with 
adopting Dave's language even though it doesn't have a MUST for signers. 
  Isn't the MUST implicit by virtue of the requirements on the verifier 
coupled with the assumption that the author of the signing software 
desires to create something that's useful?  Am I missing the point here?

-- 
Arvel

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 15:20:39 -0500

----- Original Message -----
From: "Mark Delany" <[email-masked]>
To: "IETF-DKIM" <[email-masked]>
Sent: Wednesday, February 22, 2006 2:56 PM
Subject: Re: [ietf-dkim] Suggested alternate algorithm specification
language,for now

> And as long as the target doesn't forward or relay through a

All the more reason why a passthru system should yield to traditional
practice and not tamper with mail. :-)

The client is targeting a MDA validator.  It has no clue what happens
in-between but if this capability logic is put into place, don't you think
the forwarding/relay network would be up to par?

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Feb 2006 15:54:41 -0500

----- Original Message -----
From: "Arvel Hathcock" <[email-masked]>
To: <[email-masked]>

> would it?  So, I agree with Tony and don't see a particular problem
> with adopting Dave's language even though it doesn't have a MUST
> for signers.
>

Yes, I think the MUST is implicit:

   Signer SHOULD use SHA-256.  If not, signer MUST use SHA1.

Since there seems to lack of confidence that no SHA based algorithm would be
secured enough for certain domains (in the future), that is why I suggest
the specs should indicate instead:

   Signer SHOULD use the highest security possible.

Howewver, unless we use a "receiver" capability logic to allow for growth,
the specs will need to define which current algorithms are considered
possible choices to select from.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 22 Feb 2006 16:10:51 -0500

I was reminded that Dave actually had suggested wording changes for two
places in the spec. I was referring to both.

	Tony Hansen
	[email-masked]

---

From: Jon Callas <[email-masked]>
Date: Wed, 22 Feb 2006 13:58:06 -0800

> I vote for Dave's language to be added to ietf-dkim-base.

I concur, this is a great way to deal with the issue.

	Jon

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Feb 2006 15:52:09 -0800 (PST)

> signer knowing in advance that it would have trouble inter-operating?

Simple: Someone who wants to promote their private stuff and lock people in to
their solution. This happens all the time, especially in the crypto space.
Snake oil sells, sad to say. Rarely does a month go by that Bruce Schneier has
a "worthy" product to write up in his doghouse section, and often there are
several in there.

> would it?

You'd be amazed at how long this sort of stuff can stick around once
someone commits it and releases it. Our customers often demand that
we support stuff that's in egregious violation of the relevant standards.
Leaving doors open so crap can claim to comply makes matters even worse.

> So, I agree with Tony and don't see a particular problem with

You don't have a problem with having an extremely rough time getting
through the process then, assuming you make it at all.

> desires to create something that's useful?  Am I missing the point here?

The real question is why you're so opposed to making it a MUST. If in fact
you're right and every implementor will as a practical matter not create such
things, the MUST will cause no harm whatsoever. If, OTOH, I'm right we'll be
very glad there's a MUST in there.

				Ned

---

From: Mark Delany <[email-masked]>
Date: Thu, 23 Feb 2006 00:52:57 +0000

> The real question is why you're so opposed to making it a MUST. If in fact

Here's my guess. I don't think Arvel is opposed. As an implementor he
just wants to know what code to write.

As a pragmatist, I think Arvel is right, as an observer of wannabe RFC
police, I think Ned is right.

Personally, I'm a bit amazed at the minutia. Surely everyone accepts
that an interop core is essential and in IETF parlance that implies an
appropriate set of MUSTs or their logical equivalence.

My suspicion is that we have violent agreement.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 23 Feb 2006 10:42:13 -0600

> just wants to know what code to write.

That's right.  I'm not opposed.  I have the occasional questions for my 
own learning (sorry) and Ned has answered them well in this case.  I 
agree that implementation requirements make sense on both ends as Ned 
said previously.

-- 
Arvel