ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-yam-rfc4409bis-02.txt> (Message Submission

2011-08-12 14:03:08
On 8/11/2011 9:37 AM, The IESG wrote:
The IESG has received a request from the Yet Another Mail WG (yam) to
consider the following document:
- 'Message Submission for Mail'
   <draft-ietf-yam-rfc4409bis-02.txt>  as a Full Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-08-25. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

I'm wondering wheter there should be an informative reference to rfc6186.

and I am concerned about the security mess around SMTP-AUTH (rfc4954)
(for which this document is not responsible, but which it also
 does not mention).

Coincidentally, we were just talking about server endpoint identification
(typically performed by TLS clients and described in rfc6125) and
how SMTP-AUTH (rfc4954) does not really distinguish two very different
usage scenarios of SMTP-AUTH (MTA<->MTA) and (MUA->MTA) and how they're
actually (ab)used today on the internet.

 e.g. http://www.ietf.org/mail-archive/web/dane/current/msg03067.html

 additional comment to that Mail, the server certificate presented
 by that Google MX-host is from a private CA (not from one known
 to the TLS X.509 PKI), and @gmail.com is _not_ using DNSSEC.


While the typical TLS server certificate for MUA->MTA transfer might be
in a better shape than the totally devastating situation for MTA<->MTA,
server discovery through MX records for MTA<->MTA and server discovery
through SRV records for Email submission (MUA->MTA) suggested by rfc6186
will preclude authentication of the server.

I believe that the current pityful state of TLS server endpoint
identification and the lack of server endpoint identification
(precluded by the MX & SRV transformations) should at least be
documented in the Security Considerations section.


-Martin

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf