ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] All done on potential SSP requirements?

2006-08-04 08:58:13

From: Stephen Farrell 
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] 

I could quibble, but I don't think I need to. To be clear, my 
understanding is that we really, really, strongly want to 
maintain compatibility with the existing key records (and 
we've not broken that so far). If some new field were defined 
s.t. it didn't force, or practically require, changes to 
existing records, that'd be ok on the face of it (if there's 
WG consensus etc.) I'm not sure if SSP related stuff would 
cause a problem there or not.

Adding attributes does not break backwards compatibility.

The point here is that the key record is in effect a policy statement. It 
describes a possible set of signing options. If a signature verifies against a 
key record that describes a trusted signature mechanism it is assumed authentic.

So the key records have to contain 90% of the constraints you would want in the 
policy language. I think that they are all there already and I suspect that 
should any be missing we woul consider it to be a defect in base.


What I am saying here is that we may be able to dramatically simplify the 
policy language, effectively reducing it to a series of AND conditions of the 
form

"I always sign with a key selector of the form X"  AND
"I always sign with a key selector of the form Y"


This has two major advantages over the approach "I always sign with RSA-SHA256 
with relaxed C18N....)

1) All the algorithm descriptions are concentrated in the key records, the is 
no need for the policy language to repeat any of that discussion. 
Administration is simplified because all the algorithm information is 
concentrated in one place.

2) The risk of the policy record getting too long and exceeding the 500 byte 
DNS limit is avoided. The complexity of the policy record is proportional to 
the number of signatures that you always add to a message. It is independent of 
the size and complexity of your email configuration. I very much doubt that it 
would be necessary to ever add more than two signatures and 90% of the time it 
would be sufficient to add one.


The policy part of the policy record is thus:

POLICY ::=   NEVER-SEND |
             ALWAYS-SIGN |
             ALWAYS-SIGN-WITH (x) [AND ALWAYS-SIGN-WITH (x)]* |
             UNSPECIFIED

Where UNSPECIFIED is the same as not putting a policy record there at all and 
covers the set of policies it is not useful to differentiate between, i.e. 
signing some messages but not all of them.

The other half of the policy record is *suggesting* what to do in the case of 
an error.

EXCEPTION ::=  (SUGGEST-REJECT | SUGGEST-ACCEPT | IGNORE ) EXCEPTION-ENTRY*
EXCEPTION-ENTRY ::=
             REPORT (mechanism) 


If there's consensus that its worthwhile adding to the key 
record for SSP-related reasons then I guess we do that. 
(However, I'd expect there to be some opposition to modifying 
key records at all unless there's a compelling case. I've no 
strong opinion myself, but I guess we'll see.)

As I said I don't think it should be necessary at all and if it does turn out 
to be necessary that is only because we goofed somehow.

The only exception to that is that it may be desirable to allow a 'key' record 
that has no key value but does have use constraints. This would allow a bulk 
mailer to send mail that included a DKIM record consisting only of a selector 
declaration where the selector restricts this use to a single mail address. 

This might help ease the deployment process somewhat as it is much easier to 
add a static header to a bulk mailer system than add in infrastructure to do 
signing. It means that policy can be phased in gradually rather than being an 
all or nothing thing.



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

<Prev in Thread] Current Thread [Next in Thread>