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