Re: [secdir] SECDIR review of draft-melnikov-smtp-priority-09

[Dave Crocker <[e-mail]>]

(copying Murray, in case he has further thoughts...)


On 3/11/2012 6:05 PM, Chris Lonvick wrote:
> I am concerned that this feature can disrupt the DKIM protection as noted in
> section 11.1. I see the problem here and I can't offer any suggestions to fix
> that. I think that the authors have done well to document this.


Predictably, the DKIM reference caught my attention.

I think the existing draft text in 11.1 is good.  I think it entirely reasonable 
to leave it alone.

That said, since the concern about broken DKIM signatures is raised it's worth 
at least considering adding more text.  However I think there's a challenge in 
what that 'more' should be.

In general, the world is moving in a direction that is likely to impose 
penalties when an origination DKIM signature is broken.  (I'm not happy about 
that; I think it represents some problematic thinking about DKIM, but it is 
nonetheless the direction things are going.)

The draft might suggest /not/ covering the MT-Priority: field with a signature. 
  There is a common view that DKIM "protects" and or "validates" the fields it 
covers.

Although DKIM obviously provides data integrity between the time of signing and 
validating, DKIM semantics do not offer anything like authentication of 
validation of the data that are signed.  It only validates the authorization of 
the associated identifier (sdid, d=), with the message it is attached to.

As such, having MT-Priority: be outside a signature probably isn't that onerous, 
unless there is a serious threat of in-transit header field modification attacks.

Arguably, it's better to have the agent assigning priority be the one to sign. 
In the case of revising the priority, that's not the originator.  This is only 
problematic for cases that demand origination signatures (usually translating 
into requiring the DKIM sdid (d=) value be the same as, for example, the 
rfc5322.From domain.

There is private pursuit of a specification that allows intermediaries that 
break DKIM signatures to report that they were valid before being broken.  For 
this mechanism to be useful, there needs to be transitive trust between the 
intermediary and the validating receiver.  But, as I say, that's work in 
progress.  Although it sounds appealing, I've no idea how useful it will 
actually prove to be.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net