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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx mailing lists by 2011-08-25. Exceptionally, comments may be
> sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]