ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - Sender Authentication - DNS + PKI

2003-11-24 11:49:09
Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
The quoted description sounds like an end-to-end implementation of a
designated outgoing MTA protocol. This actually sounds better, on first
impressions, than the current LMAP ideas, for three big reasons.

  It's substantially similar in concept to LMAP if it does header
verification, or PGP signing, if it does body verification.  Without a
more complete description, I can't tell for sure.

  If it authenticates the message body, then it has the problem that
PGP and S/MIME has: broken MTA's mucking with the message content.
It's not critical, but it is a consideration.  Another consideration
is that the recipient then has to receive the entire message before
the signature can be validated.  Solutions which work on headers alone
may have more efficient use of network resources.

  If it authenticates the headers, then the "encrypted code" in the
header can be re-used in other, unrelated messages, to send spam.
Time limits can be put on the tokens, but that's basically a hack
around an inadequate design.

  e.g. Some choices for the token, and pros/cons:

  token = signature(nonce) + nonce
    pro: simple
    con: easily stealable

  token = signature(nonce + source IP) + nonce
    pro: better
    con: forwarders don't have the same source IP, and can thus
         claim to be "forwarding" mail, to spam people

  token = signature(nonce + source IP + timeout) + nonce + timeout)
    pro: better
    con: still onl limits impact of attack, but doesn't prevent
         the attack.

  I'd like to see a signature scheme for headers only which can't be
trivially attacked or abused.  I'm not sure one exists.

First, this would be easier for senders to implement, because it
doesn't require listing every MTA in DNS and it keeps configuration
of a new MTA confined to that machine (all that has to be done is
loading the private key).

  Which will REQUIRE communication with the owner of that public key.
This isn't substantially different than the work required to set up
LMAP:  "please give me key", versus "please list X in DNS".

Second, it would require much less change to DNS, because only a
single new record would be needed for each domain, rather than one
for each server sending for that domain.

  That is true.  The ongoing maintenance costs of this solution will
be lower than that for any LMAP solution.

Third, it would eliminate the issues of forwarding (.forward,
aliases), because it checks the message originator in all
circumstances.

  Once you have forwarding, it can be abused to send spam.  See the
discussion above.

Now, my concerns: why have they not published a technical proposal for this
yet?

  Politics.

 From a different part of the article:
"The ASRG is considering three major proposals, Reverse MX, Sender Permitted
 From and Designated Sender Protocol, John R. Levine, co-chair of the
organization said.
"They're bascially all variations on the same theme, which is the attempt to
identify mail that's not coming from where it should," Levine said."

Perhaps Alan DeKok would be more qualified to comment on this, but this
statement is not really accurate in light of the work on a combined
LMAP draft.

 There is no combined LMAP draft.  There is an LMAP evaluation
document, which discusses the costs and benefits of LMAP-style
proposals.

  The article goes on to say:

   "The technologies would allow a mail server receiving a message to
   query the domain that a message purports to be from, asking if the
   server that sent the mail is authorized to send from that domain."

  I prefer the *positive* statemente of the design goal of LMAP over a
negative one.

  Alan DeKok.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg