ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Getting resolution on the "double header" issue

2010-11-11 06:24:57
On Mon, 08 Nov 2010 09:20:19 -0000, Barry Leiba 
<barryleiba(_at_)computer(_dot_)org>  
wrote:

I have a chair statement to start with, and then the rest of this
message will be as a participant.

As chair:
We have gone off in the weeds on the "double header" issue, and are
fighting with ourselves.  The chairs need everyone to aim at getting
some rough consensus on this, so we're asking this: let's focus, as we
once did, on working together to achieve a result that most of us, at
least, can live with.  That means that many people will not get it
just the way they want it, and you might not see a result that you
consider ideal.  I think we're close enough, really, on this that we
can still get a result that we consider acceptable.

OK. Here is a suggestion. I think it is broadly in line with your  
"proposal", but it includes various almost-orthogonal parameters that can  
be tweaked independently of each other to provide a final version.  
Word-smithing can come later, and it will also need NOTEs and Security  
Considerations to explain the problem(s) and how they are covered. But be  
clear that this is an unashamedly Normative proposal.

1. Framework:

o Signers MUST/SHOULD do "something" (see below) in the event that the
   message contains multiple "once-only" headers.
       PLUS
   Verifiers MUST/SHOULD check that "something" had been correctly applied
   (else PERMFAIL). Note that this will catch both headers maliciously added
   in transit/replay and malicious signers.

o As above, but covering other RFC 5322 violations as well as "once-only"
   headers.

2. Normativeness:

o MUST

o SHOULD

3. Definintion of "something"

o Refuse to sign (i.e. reject) if multiple "once-only" found [or other 5322
   violations]. I had a wording for this.

o Permit signing of multiple "once-only" (even though violating 5322), but
   require ALL those headers to be signed (i.e. included in 'h=' tag).
   Hector has a wording for this.

4. Scope of "something"

o Apply the above to ALL multiple "once-only" headers found.

o Apply the above only to those headers actually mentioned in the 'h=' tag.
   (e.g. allow multiple Subject:s if Subject entirely absent from 'h='.)

5. Definition of "once-only"

o Just the From: header

o All headers defined as once-only in RFC 5322.

o As above, but include RFC 2045

o As above, but include at least some List-* headers

o Other, please specify

I count the permutations of those as leading to 80 different proposals,  
though I suspect some of them are not meaningful. But they cover most of  
the normative-style proposals that have been made during the dicussion.

And note that there are no layering violations (since the one protocol  
simply introduces a requirement to be applied at one stage and checked at  
another).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html