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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Oct 2006 10:52:07 -0700

The deployment scenarios do not capture the downgrade attack problem correctly.

As has been repeatedly pointed out on the list and never rebutted the only way you can have a successful transition from a state where the whole world uses algorithm A to one where the whole world uses algorithm B without having a period where one group or the other is unable to achieve their security goals is to:

* Sign messages with both algorithms
* Have a policy statement that specifies that messages are signed with both algorithms.

Also 5.7 talks about hash algorithms which makes it look as if this is the only concern. A much bigger concern for me is the fast that we are using RSA and we cannot go beyond 2048 bit keys. So I am more concerned about the need for agility in the signing algorithm.

Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

In the case where the signer supports multiple cryptographic algorithms, including algorithm(s) that are regarded as compromised the threat of downgrade attack MUST be considered.  In this attack the attacker makes use of the compromised algorithm even though the signer always signs using a high security algorithm.

In the case where a DKIM signature may be created using a cryptographic algorithm that is not supported by the verifier the threat of an upgrade attack MUST be considered. In this case the attacker creates a signature that is consistent with a signature algorithm that the recipient is not expected to be able to verify.

In each case it is necessary that the signer specify a signature policy that allows the existence of multiple signatures and multiple signature algorithms to be specified.

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Oct 2006 11:20:06 -0700

On Oct 23, 2006, at 10:52 AM, Hallam-Baker, Phillip wrote:

> As has been repeatedly pointed out on the list and never rebutted  
> the only way you can have a successful transition from a state  
> where the whole world uses algorithm A to one where the whole world  
> uses algorithm B without having a period where one group or the  
> other is unable to achieve their security goals is to:
>

When more than one algorithm is offered, where the signer is also  
responding to an attack vector, the following is also desired -

   * Indicate which of algorithms are deprecated.

However, this strategy is not to be handled in the initial  
specifications.

An optimal location for this information to minimize overhead is  
within the key records.  There is also a desire to eliminate policy  
references in various scenarios not compatible with preventing this  
downgrade concern.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Oct 2006 22:07:20 +0100

Hi Phill,

Before we get into the wording of the latest ssp-reqs, can we try
to figure out whether this is really different from the set of
similar *closed* issues on base?

I am not at all clear why such flags are useful in SSP, given that
we have rough consensus that they are not needed for base.

As I see it:

1. The current WG consensus for base is that its up to each recipient
to decide for itself which algorithms it considers acceptable.

2. The current WG consensus (I think) is that SSP need not be used
when a signature that the recipient considers "good" is present. (I.e.
I see no consensus for a position that SSP MUST be used even if
what the verifier thinks is a good signature is present.)

Given 1 & 2 above, I just don't see the point of algorithm
transition information in SSP since no-one will read it who
might act on it.

Please also expliticly explain why this is not simply revisiting
some *closed* issues on base.

Thanks,
Stephen.