mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Straw consensus call on auth-header draft

2008-10-14 12:01:32
Murray,

Interesting and intriguing perspective.  I like it.

Perhaps I missed it, but I don't recall seeing such a coherent, focused and 
pragmatic requirements statement in this discussion, so far.

But note that what you are describing has nothing specific to mail-vet.

Really.

You are describing a generic requirement for trusted information exchange 
between two nodes that are possibly within a trust domain.  The fact that the 
information is, itself, security-related might affect some choices in the 
design, but not in a way that is specific to mail-vet (or the fact that it is 
security-releated...)  The other that might be a bit different is to protect a 
specified header field.  Again, I doubt that affects design choices all that 
much.

So mail-vet *might* be motivating it, but it is really an independent technical 
requirement.  It warrants an independent technical specification.

Let me repeat this:  To the extent that the current specification is for a data 
format, rather than an end-to-end exchange service, then an effort to satisfy 
this requirement belongs to a separate document.

And, of course, there are *lots* of ways to satisfy it.  That's a further 
reason 
to avoid burdening the current, core data spec with its details.

d/


Murray S. Kucherawy wrote:
Dave CROCKER wrote:
This begs the question:  why bother to do the first validation; why 
not simply wait and let whoever would have validated the first instead 
validate the first?

If the only authentication method being applied at a site is DKIM or 
other things that don't care about the path, that works.  But that's a 
big "if", and moreover means all consumers of authentication results 
data must now learn all local path-agnostic methods being used to 
evaluate messages.

The desire here is to secure arbitrary authentication results data 
between the border MTA and the consuming MUA.  DKIM is one way that 
could be achieved, meaning the consumers need to learn one and only one 
message authentication scheme in order to validate that one piece of 
protected internal data.


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

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