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

Re: [mail-vet-discuss] Discussion of auth-header draft (fwd)

2008-10-08 19:20:45

Forcing use of the same key for two different purposes is
usually a bad idea. Good crypto design tends strongly towards
using, or at least allowing, different keys for different
purposes. So FWIW I have an innate dislike for option 3.

S.

Tony Hansen wrote:
Option 3 would be to introduce a token signed using the same private key
as is used by that MTA when doing DKIM signing. That token can then be
verified using the DKIM public key.

The presumes that:
      a) the SMTP verifier is part of an MTA that is *doing* DKIM
         signing to begin with
      b) that the SMTP verifier has access to the private key
      c) the MUA has access to the DNS _domainkey TXT records
      d) this allows A-R records created by other entities to be
         verified (in addition to the MDA)

It has the side effect of tying A-R more closely to DKIM, which can be
considered a good or bad thing.

Option 4 would be to use the ADSP records in some fashion to hold the
public key or specify where to find the public key.

Option 5 would be to introduce YAPK (yet another public key) that could
be published parallel to the _domainkey records. You're faced with
redesigning the entire facility that DKIM provides, although much can be
boot strapped from the DKIM docs.

Option 6 would be to use some other form of PKI.

Option 7: Since it's adding A-R records is a receiving operation, not
sending operation, it would make sense to extend IMAP and POP. For
example, IMAP and POP could show a CAPABILITY/CAPA to indicate that the
messages being served provide A-R records and what auth-serv-id is being
used.

Hopefully one of these options resonates with enough people.

      Tony Hansen
      tony(_at_)att(_dot_)com

Murray S. Kucherawy wrote:
More formal IETF review of draft-kucherawy-sender-auth-header has begun.

So far the only issue brought back to me is the following:

I'd like to have some consensus discussion around ways to verify that an 
MTA supports this draft.  You mentioned alternatives including digital 
signatures and interrogating the MTA, but dismissed those alternatives. 
It's a really important question and one the IESG will latch onto! 
It's a question of detecting forged signatures, yes, but it's also a 
question of supporting auto-configuration -- the current draft makes 
email configuration harder, and it's hard enough already.
The proposals the current draft suggests, which are listed briefly in 
Security Considerations, include:

a) interrogating the previous MTA to determine if it's participating in 
this specification such that dangerous Authentication-Results: headers are 
being removed; and

b) digital signing of the Authentication-Results: header, e.g. with DKIM

The spec doesn't actually mandate either of these.  It sounds like the 
IESG would likely want one or the other.

My argument against requiring (a) is that this would touch a great deal 
more software, actually requiring MTAs to have some mechanism by which 
they can be interrogated to see if the MTA itself or a plugin it's using 
implement this specification.  We could create an ESMTP extension which 
announces that the MTA has implemented the spec, but for an MUA to check 
it would require an ESMTP session consisting of (connect)/EHLO/QUIT which, 
at least for our MTA, would cause a ton of additional logging to take 
place.  (I realize that, by itself, isn't a reason not to do it, but it 
might impact others as well.)

My argument against requiring (b) is that this entire proposal is an 
attempt to ensure that MUAs don't have to do all of the authentication 
work since the border MTAs have done that for them.  Moreover, MUAs are 
very likely not in a position to be able to evaluate any of the IP-based 
authentication schemes.  However, I wouldn't be too opposed to adding text 
which says the message SHOULD be DKIM-signed after Authentication-Results: 
is added as this limits imposition on MUAs such that they only have to 
learn one message authentication method, and there are already 
well-defined free solutions to that out there.

A coworker also suggested the following: If you trust that your MTAs from 
the border inbound are compliant, then you can pretty much guarantee that 
Authentication-Results: will appear immediately above (or perhaps 
immediately below) a matching Received: header, and thus you could decide 
to trust only those which (a) have such an adjacency, and (b) are from a 
host you trust.

Since auto-configuration was brought up, I'm left wondering which of these 
requires the least amount of thought and adjustment by sysadmins.  It 
seems to me all of them require that an MUA know or be able to determine 
which MTAs it trusts, so that can't be eliminated.  Or can it?  Apart from 
that though, the complexity of all of those solutions in terms of 
configuration seem to be the same to me.

Opinions welcome.  Solicited, in fact, since this is all about consensus. 
:)

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

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

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