ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Requirements on where/how SSP stuff is published...

2006-07-28 13:43:15
One further thought, we might want to qualify the statement 'sign' with the 
protocol 'DKIM' and work through how we would cope with PGP, SMIME etc if we 
were going to support them within the same policy framework.

Not that we would actually put the result in the final document but we might 
want to go through the thought exercise.

I suspect that the main issue we would come to in both cases is the lack of an 
effective, standardized means for discovering the key distribution mechanism.

Working through the examples might well lead us to a syntax of the form:

SIGN=DKIM,RR=*._domain.example.com & SIGN=SMIME,KD=XKMS & 
SIGN=PGP,KS=pgpkeyserve.ai.mit.edu

Not that anyone would be likely to do all three signatures.


Perhaps Jon could weigh in and explain how this is done in PGP Universal.

-----Original Message-----
From: Hallam-Baker, Phillip 
Sent: Friday, July 28, 2006 4:22 PM
To: 'John Levine'; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Requirements on where/how SSP stuff 
is published...


[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine

I'm hoping that we can constrain the SSP info to a modest number of 
bits, so DNS is is.  If SSP bloats up to the point where it doesn't 
fit in 512, then it's http.

I think that if we follow the approach that the policy record 
specifies the acceptable selector records we can ensure that 
the policy record fits into a single line.

I can't see a need for any party to sign a message more than 
twice (for purposes of algorithm transition) and I can't see 
much utility in more than an end entity signer and a gateway 
signer for a given domain. So the worst case policy record 
would be something like:

"SIGN (ALWAYS (SELECTOR=*._ee_dsa.example.com) & ALWAYS ( 
SELECTOR=*._ee_rsa.example.com) & ALWAYS 
(SELECTOR=*._gs_dsa.example.com) & ALWAYS ( 
SELECTOR=*._gs_rsa.example.com))"

This can be compressed pretty effectively:

SIGN=ALWAYS (*._ee_dsa.example.com & *._ee_rsa.example.com & 
*._gs_dsa.example.com & *._gs_rsa.example.com)


Since the gateway signer can always enforce the policy 
requirement for the end entity signature it is more likely 
that you would have an OR rather than an AND:

SIGN=ALWAYS ((*._ee_dsa.example.com & *._ee_rsa.example.com) 
| (*._gs_dsa.example.com & *._gs_rsa.example.com))

This would allow the 'Keith Moore' criteria of allowing an 
end entity signature in place of a gateway signature. In 
practice however OR alternatives can always be addressed 
through hierarchy if need be so I won't argue a strong case 
for needing the OR construct.

I think that 95% of cases would only require the gateway 
selectors so the normal record would be:
"SIGN=ALWAYS"

The record used during an algorithm transition would be:
"SIGN=ALWAYS (*._ee_dsa.example.com & *._ee_rsa.example.com)"


The policy cases I see as being of interest are:

SEND=NEVER
SEND=ALLOWED

SIGN=NEVER
SIGN=ALLOWED
SIGN=ALWAYS


The useful combinations are

SEND=NEVER
SEND=ALLOWED,SIGN=NEVER
SEND=ALLOWED,SIGN=ALLOWED
SEND=ALLOWED,SIGN=ALWAYS


There is not much need for SEND=ALLOWED,SIGN=NEVER except to 
the extent you might want to stop a heuristic search for a 
policy record. One could argue that we could equally well 
specify SIGN=ALLOWED and not specify any key records.

I think that the useful keywords are

NEVERSEND
NEVERSIGN
MAYSIGN
ALWAYSSIGN


My preferred syntax would be something like:

**.example.com TXT "ALWAYSSIGN=*._ee_dsa.example.com & 
ALWAYSSIGN=*._ee_rsa.example.com"

Note that we do not require the policy record to be within 
the originating domain. We could have 

**.example.com TXT "ALWAYSSIGN=*.outsourcesign.com"


We then load the rest of the policy into the key record.

If we want exceptions to the signature scheme we can do that 
with a key record that specifies the NULL algorithm. In this 
scheme the key record specifies:

* The mail accounts that the key may be used to sign for
* The public key algorithm (NULL, RSA, DSA), the public key value
* The allowed hash algorithm (SHA1, SHA256, SHA512)
* The allowed canonicalization methods (Relaxed, Simple, whatever)
* Links to any additional information (e.g. a public key 
certificate) that relates to the key

In addition we might also specify:

* NotBefore and NotAfter times for use of the key


The only other information I would consider loading into the 
base policy record would be some sort of warning flag to 
indicate the probability that a failed signature is likely to 
be a phishing attempt and some sort pf indication for 
reporting failures.

**.bizybank.com TXT "ALWAYSSIGN SPOOFTARGET=99 REPORT=PINCH 
REPORT=YARP"

Always sign, probability a failed signature is a spoof is 99% 
or greater, failures may be reported using either PINCH or YARP.


Note that we do not tell anyone how to react to the spoof 
target data, we merely provide the information. In practice I 
think that most people at Paypal and such would prefer it if 
we maximized the probability that the phishing mails end up 
in the bit bucket rather than the probability that their 
personal email is not false positived when the signature is damaged. 


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