Subject: RE: [ietf-dkim] Core algorithm support/use, draft text v2

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Feb 2006 08:03:48 -0800

> [mailto:[email-masked]] On Behalf Of Dave Crocker

> So double signing gives compatibility without better 
> strength, but with lots 
> more overhead.  In other words, I do not see the upside of 
> the double signature.

With SHA1/256 I absolutely agree. A second sig adds no value at all.
Particularly since RSA1024 is weaker than SHA1.

When we start introducing the replacement signature algorithm which will
at the very least entail the use of a digest algorithm that is currently
unknown and quite likely an unknown signature algorithm the use of
double signatures is the only way to realistically deploy the system.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Feb 2006 14:55:59 -0800

The difference between 1 and 2 is only marketing but marketing is
critical. I still get people obsessing about the 'overhead' of XML in
the most ridiculous circumstances you can imagine (like a 1kb/sec
control channel to a 1Mb/sec live data channel).

I think we should go with (2).

Given the amount of thrashing we have here I think we need a procedure
for issue closure. I don't think that there is anyone who is in serious
disagreement with option 2:

 2. Require SHA-1 and SHA-256 verification support and recommend
    (require?) signatures with SHA-256.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Rescorla
> Sent: Monday, February 27, 2006 5:24 PM
> To: [email-masked]
> Cc: DKIM IETF WG
> Subject: Re: [ietf-dkim] Core algorithm support/use, draft text v2
> 
> Dave Crocker <[email-masked]> writes:
> > My own opinion is that double signing is overkill -- and maybe 
> > misleading -- for this application. As I understand things, 
> SHA-1 is, 
> > in fact, valid for use today. At the least, if sha-1 gives 
> acceptable 
> > security, then sha-256 isn't needed. If it does NOT give acceptable 
> > security, then it should not be used.
> >
> > So double signing gives compatibility without better strength, but 
> > with lots more overhead.  In other words, I do not see the 
> upside of 
> > the double signature.
> 
> I tend to agree with Dave here. 
> 
> That said, I think it's important to examine the security 
> requirements.  As I understand it, the major objective here 
> is to use the presence or absence of the message signature as 
> an input to a filtering process. Accordingly, unlike with 
> S/MIME, it's not really critical that people stop relying on 
> a weakened hash algorithm as long as the cost to forge a 
> signature with that algorithm is substantial.
> 
> Even if a collision attack is useful for attacking DKIM, the 
> cost to forge a SHA-1 signature would be quite high (2^61 as 
> of now), so the probability that a signed message is valid 
> would remain quite high. Given that the theory seems to be to 
> treat an invalid signature as nonexistent, this seems like an 
> appropriate treatment to give an invalid hash algorithm as 
> well. So, I don't see a problem with letting senders figure 
> out which algorithm to use based on the likely level of 
> recipient deployment.
> 
> It seems to me that the key requirement here is that if/when 
> senders start moving to some new algorithm, that we be able 
> to have a smooth transition. That requires two things:
> 
> 1. That recipients handle multiple signatures correctly. I.e.,
>    that signatures with unacceptable algorithms are skipped
>    rather than creating an error if there is a valid signature.
> 
> 2. That support for verifying that new algorithm be available
>    broadly prior to senders starting to use it exclusively.
> 
> Given that, I think that we should either:
> 
> 1. Require SHA-1 and SHA-256 verification support and recommend
>    signatures with SHA-1.
> 
> 2. Require SHA-1 and SHA-256 verification support and recommend
>    (require?) signatures with SHA-256.
> 
> 3. Require SHA-256 support and forbid SHA-1 in both generation
>    and verification.
> 
> Option (3) seems like overkill. I don't have a strong opinion 
> between (1) and (2), but probably lean towards (2) on the 
> grounds that it's better to use something that we don't know 
> has problems, even probably irrelevant ones.
> 
> -Ekr            
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Feb 2006 18:30:15 -0800

> [mailto:[email-masked]] On Behalf Of Mark Delany
> On Tue, Feb 28, 2006 at 11:06:35AM -0800, Jim Fenton allegedly wrote:

> I'm all for supporting multiple signatures in the first DKIM 
> standard simply to give us some chance of avoiding that 
> disaster. That way I can configure a subset of my outbound to 
> generate two signatures using different hashes, just to catch 
> bugs in the early stages of deployment.

I agree emphatically with Mark.

I believe that the best way to do this would be to introduce a signature
counter so that the order of signing can be recovered even if a message
has its headers reordered.

The rules for signing then become:

If the message to be signed contains a signature header the signer must
include a counter attribute in the signature scope that has an integer
counter value that is greater than all the counter values present in all
othe signature headers present in the message to be signed.

A good way to test this out before we need to use it for rolling
algorithms would be for people to test for the case where there are
multiple signatures from different signers. A verifier needs to be able
to avoid being confused. 

The simplest (but not necessarily the best) non-confusion algorithm
being to look at only the signature with the highest counter value. This
is always going to be the message with the highest probability of
verifying correctly.