Subject: [ietf-dkim] Secrtion 6.3 Comments on draft-ietf-dkim-ssp-requirements-02.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Oct 2006 11:30:16 -0700

6.3
11. The Protocol MUST NOT be required to be invoked if a valid first party signature is found.

Should be:

The Protocol MUST NOT be required to be invoked if a valid first party signature that satisfies the cryptographic criteria of the recipient is found. 

If I look at the email and find a satisfactory signature I am done. If I don't find any signature at all *or I find only a weak signature* I need to look at the policy.

Otherwise the requirements of 5.7 are unmet.

This requirement only starts to have real effect when we have a serious enough compromise of SHA or RSA1024 to mean that verifiers would reject weak signatures. I don't expect to get there until 2015 but I do expect to get there eventually.

Also I would like to reword 12:

[PROVISIONAL] A domain holder MUST be able to publish a Practice which enumerates the acceptable cryptographic algorithms for signatures purportedly from that domain. 

To be 

12a [PROVISIONAL] A domain holder MUST be able to publish a Practice which specifies the acceptable application of cryptographic algorithms for signatures purportedly from that domain. 

12b [PROVISIONAL] A domain holder MUST be able to publish a Practice which specifies the application of multiple signatures with different cryptographic algorithms for messages purportedly from that domain. 

The difference here is key to the distinction between my proposal and the existing one. A mere enumeration of the acceptable algorithms does not allow the upgrade/downgrade attack to be effectively defeated. Merely saying 'I support SHA-256' does not in fact strengthen the policy.

Also the term 'enumeration' expresses the assumption that the algorithms will be listed in the policy record. I don't think they should go there. The proper place for them is in the key record. This avoids the need to duplicate the information and is in any case necessary to meet requirement 11 which can only be met if the key records effectively enumerate the set of acceptable algorithms.

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

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 24 Oct 2006 05:36:23 -0400

My Technical opinion.

This 6.3 provision #11 makes no sense to me.

>From a design standpoint, the better system is probably going to end up
looking up all domains because that will guaranteed a consistent security
check.

The only reason I see this provision exist, nothing to do with logic, but
something to satisfy backward compatibility with existing alpha code being
used.  I see no logic in trying to dictate on a designer how he/she is going
to implement DKIM and SSP and that is what this provision attempts to do.

Imagine if you remove it? What is lost?

The only legitimate argument can make is that it is an OPTIMIZER, an
optimizer purely based on the presumption that a VALID 1st party signature
is always correct.

Well, as you said the inevitable will happen, when the crypto is hacked, you
now will have millions of vulnerable sites simply because they follow this
illogical provision that serves no place in a requirements document but to
satisfy alpha code implementations that no one should be basing their future
on anyway.

That's my opinion and I'll leave it at that.

Thanks

---
HLS

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>; <[email-masked]>
Sent: Monday, October 23, 2006 2:30 PM
Subject: [ietf-dkim] Secrtion 6.3 Comments
ondraft-ietf-dkim-ssp-requirements-02.txt

6.3
11. The Protocol MUST NOT be required to be invoked if a valid first party
signature is found.

Should be:

The Protocol MUST NOT be required to be invoked if a valid first party
signature that satisfies the cryptographic criteria of the recipient is
found.

If I look at the email and find a satisfactory signature I am done. If I
don't find any signature at all *or I find only a weak signature* I need to
look at the policy.

This requirement only starts to have real effect when we have a serious
enough compromise of SHA or RSA1024 to mean that verifiers would reject weak
signatures. I don't expect to get there until 2015 but I do expect to get
there eventually.

[PROVISIONAL] A domain holder MUST be able to publish a Practice which
enumerates the acceptable cryptographic algorithms for signatures
purportedly from that domain.

To be

12a [PROVISIONAL] A domain holder MUST be able to publish a Practice which
specifies the acceptable application of cryptographic algorithms for
signatures purportedly from that domain.

12b [PROVISIONAL] A domain holder MUST be able to publish a Practice which
specifies the application of multiple signatures with different
cryptographic algorithms for messages purportedly from that domain.

The difference here is key to the distinction between my proposal and the
existing one. A mere enumeration of the acceptable algorithms does not allow
the upgrade/downgrade attack to be effectively defeated. Merely saying 'I
support SHA-256' does not in fact strengthen the policy.

Also the term 'enumeration' expresses the assumption that the algorithms
will be listed in the policy record. I don't think they should go there. The
proper place for them is in the key record. This avoids the need to
duplicate the information and is in any case necessary to meet requirement
11 which can only be met if the key records effectively enumerate the set of
acceptable algorithms.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Oct 2006 11:49:22 -0700

> If I look at the email and find a satisfactory signature I am done. If I don't find any signature at all *or I find only a weak signature* I need to look at the policy.
I don't see why we need to introduce shades of grey (i.e., valid but
weak signatures) here.  The verifier is able to decide what it considers
to be a valid signature.  If a signature uses an algorithm that the
verifier considers to be too weak, it should just consider the signature
to be invalid.  Then the original #11 is sufficient.
> 12b [PROVISIONAL] A domain holder MUST be able to publish a Practice which specifies the application of multiple signatures with different cryptographic algorithms for messages purportedly from tha…
I disagree with #12 entirely.  This addresses a case where there is a
signature that references a key record within the domain.  There is
already a tag/value in the key record to specify the algorithm(s) that
are associated with the key.  If there are algorithms that the domain
has abandoned using because they're too weak, they just don't publish
any key records for that algorithm.  There's no reason we need to get
this information from a Practice record.

I don't remember all the details, but we discussed whether key records
should describe the application of multiple signatures (other signatures
in addition to the one referencing the key record).  We decided not to
do that, and I don't think SSP should be trying to do the same thing again.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Oct 2006 13:40:13 -0700

On Oct 24, 2006, at 11:49 AM, Jim Fenton wrote:

>> The Protocol MUST NOT be required to be invoked if a valid first  
>> party signature that satisfies the cryptographic criteria of the  
>> recipient is found.
>>
>>
>> If I look at the email and find a satisfactory signature I am  
>> done. If I don't find any signature at all *or I find only a weak  
>> signature* I need to look at the policy.
>
> I don't see why we need to introduce shades of grey (i.e., valid  
> but weak signatures) here.  The verifier is able to decide what it  
> considers to be a valid signature.  If a signature uses an  
> algorithm that the verifier considers to be too weak, it should  
> just consider the signature to be invalid.  Then the original #11  
> is sufficient.

Where policy is asserted and whether policy is to be invoked are  
separate issues.  This purported requirement is making assumptions  
about where policy is expressed, and about the value in codifying a  
bid-down vulnerability (over a period likely measured in years) as a  
protocol requirement.  Clearly both assumptions can be wrong.

Rather than making erroneous statements, properly handle this issue  
or indicate it will be addressed later.  Either approach is  
preferable over an erroneous assertion included as a requirement.

-Doug