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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Oct 2006 12:44:59 -0700

> From: Jim Fenton [mailto:[email-masked]] 
> > 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.

Your phrasing is equivalent but leads to ambiguity. The purpose of the exercise here is to eliminate ambiguity.

A signature is VALID with respect to the Key Record. Every recipient that receives the same sequence of bits should have the same exact value for VALID.

A signature is ACCEPTABLE if it is VALID AND the signing algorithm and parameters are acceptable. This is a subjective issue and opinions may differ.

I do not see that conflating an objective quantity with a subjective quality helps here, on the contrary it introduces shades of grey where they are not required.

This problem is in part due to the use of the language 'treat an invalid signature as if it was unsigned'. This only holds for base. At the policy level there are important distinctions that need to be made between messages that are consistent with policy that bear an unverifiable signature and those that are consistent with policy and bear unverifiable signatures.

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

That is not a good choice since an invalid signature is by definition not in compliance with a certificate policy that says 'every message has a valid signature'.

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

Your approach is broken.

We are both proposing that the algorithm constraints be applied through key records. According to your proposal there is no way for a policy to specify which key records must be satisfied.

This means that under yous scheme any signer that publishes a key record for DSA-2048 before this algorithm is widely supported will be subject to an upgrade attack. The attacker can attach a signature that references the key record for DSA 2048 and the majority of recipients will be unable to determine that the signature is invalid. This is not a problem for BASE because the message is treated as unsigned. It is a problem for POLICY as it is not possible to correctly resolve the question of COMPLIANCE. In particular it is not possible to resolve the following cases correctly

Case 1: Message has a fraudulent signature for the unsupported algorithm, the signer always signs using a supported algorithm -> NOT-COMPLIANT

Case 2: Message has a valid signature for the unsupported algorithm, the signer only signs with the unsupported algorithm -> COMPLIANT but UNVERIFIED

The SSP proposal only allows one of the cases to be correctly decided. You can solve either one of them correctly by choosing the appropriate default. You cannot get both cases right without being able to determine more detail that nt current proposal allows.

The correct determination for policy compliance being either COMPLIANT with policy or NOT COMPLIANT.

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

NO, the argument was made to punt this to the SSP discussion.

I don't think that either of us wants to reopen this question as an issue for base. I raised the issue then and was told I had to wait.

So we have the discussion now.

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