ned+ietf@xxxxxxxxxxxxxxxxx wrote: > > > On 12.08.2011 21:02, Martin Rex wrote: > > > > > > I'm wondering wheter there should be an informative reference to rfc6186. > > > This question was one of two points raised during WGLC by Derek Diget > > http://www.ietf.org/mail-archive/web/yam/current/msg00615.html > > > It was decided that the current deployment of SRV doesn't quite justify > > supporting it in a Full Standard document. > > I really wish it were otherwise, but I find myself having to agree with this > assessment. It would be a different thing if this was just now coming up for > approval at proposed, but we're way past that. Security-wise, the SRV record suggested by rfc6196 seems to create additional security problems, so I would also not like to see it being "adopted" as is. :-/ > > > > 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). > > > This question was raised by Chris Newman on Fri, 30 Apr 2010. > > http://www.ietf.org/mail-archive/web/yam/current/msg00420.html > > > There was a somewhat deeper discussion, but the conclusion was the same as > > yours, namely that it's not the responsibility of 4409bis, and that > > > it would be a serious mistake to clutter 4409bis up with some of the > > details that have been suggested. Even at full standard, authentication > > details are best incorporated by reference to other documents than can be > > updated when or as necessary. > > http://www.ietf.org/mail-archive/web/yam/current/msg00434.html > > +1 While I fully agree that it is sensible to relegate (and fix) the authentication to a different document, I currently see this: http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-02#section-7 | AUTH | Authentication | MUST | [SMTP-AUTH] | And it somehow feels wrong to exhibit an ostrich-like behaviour about the current mess around SMTP-AUTH in the security considerations section. The traditional mail delivery service by SMTP is very similar to IP itself, a good-faith best-effort approach of multiple cooperating entities. Adding robust security to MTA<->MTA links will be extremely difficult. As long as an active attacker can force inter-MTA SMTP delivery to be performed without TLS the (scalable) security remains at good-faith best-effort level, even if there was DNSSEC available, all relevant records signed, even something like a "HASTLS" DNS RR defined and used for SMTP, it is still up to the SMTP MTA clients all over world to actually use those records and refuse to talk to active MITMs. The SMTPS MUA->MTA connection differs in that it often uses an explicit, server-specific configuration for TLS, without automatic fallback to non-TLS. The real situation in practise may sometimes be a little different, though. During last year, I newly set up EMail accounts for two relatives with a freemail provider (both were using 3 year old Notebooks running Windows XP) and when configuring Mail delivery for Outlook Express via SMTPS, I received a warning popup with a complaint about a mismatch of the server cert, but *NO* possibility to look at the TLS server cert and no details as to which particular attributes were compared or what exactly did not match. I believe it would be sensible to describe the desired authentication model for MUA->MTA in more detail, beyond the mere reference of [SMTP-AUTH] in section 4.3 of the current document: http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-02#section-4.3 -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf