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

From: Martin Rex <[email-masked]>
Date: Fri, 12 Aug 2011 21:02:36 +0200 (MEST)

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
> [email-masked] mailing lists by 2011-08-25. Exceptionally, comments may be
> sent to [email-masked] 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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Aug 2011 17:42:27 +0200

> 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.

> (for which this document is not responsible, but which it also

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

hth

---

From: [email-masked]
Date: Sat, 13 Aug 2011 11:45:01 -0700 (PDT)

> 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.

>               http://www.ietf.org/mail-archive/web/yam/current/msg00434.html

+1

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Aug 2011 13:12:32 -0700

Hi Martin,
>I'm wondering wheter there should be an informative reference to rfc6186.

That suggestion came up during the working group discussion but it 
was not retained as there wasn't any implementation report for RFC 
6186.  The editors of draft-ietf-yam-rfc4409bis-02 commented [1][2] 
about having an informative reference to RFC 6186.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/yam/current/msg00684.html
2. http://www.ietf.org/mail-archive/web/yam/current/msg00696.html

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Aug 2011 23:01:31 +0200 (MEST)

> 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.  :-/

> >               http://www.ietf.org/mail-archive/web/yam/current/msg00434.html

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Aug 2011 16:49:00 +0200 (MEST)

S Moonesamy wrote:
> Martin Rex wrote:
> The intent is to publish the document as a Full Standard.  As much as 
> it may be sensible to describe the desired authentication model, it 
> had to be shown that changes would contribute in a substantial and
> substantive way to the quality and comprehensibility of the
> specification as that was the guideline given to working group
> participants.  If you would like to recommend additional text,
> I suggest sending a message to the YAM mailing list.

It seems that I've been confused by the seperation of authentications
client->server and server->client into distinct protocol extensions,
i.e. SMTP-AUTH (rfc4954) for client->server, and the optional SMTP
service extension SMTP-TLS (STARTTLS, rfc3207) for server->client. 

The "mess" I was refering to is about the (factual lack of) server
endpoint identification in SMTP-TLS for the server->client authentication.

I'm sorry.

-Martin

---

From: S Moonesamy <[email-masked]>
Date: Thu, 18 Aug 2011 02:27:38 -0700

Hi Martin,
>additional security problems, so I would also not like to see it being

The YAM working group participants did not point to any security 
problem in RFC 6186.  A reading of the YAM mailing list archive would 
make it clear that nobody disliked RFC 6186.  There was a 
pre-evaluation of RFC 4409 (see 
draft-ietf-yam-4409bis-submit-pre-evaluation-00).  As there seem to 
be some confusion when the term "downref" is mentioned, I'll put the 
question as follows:

   Could the reference for RFC 6186 be mentioned in
   draft-ietf-yam-4409bis-submit-pre-evaluation-00?

If the above question is too stringent, let's try a simpler one:

   Is there any documentation about implementations of RFC 6186?

Given that nobody came forward to point to any documentation, there 
wasn't any reason to spend more time on the question.

>the current mess around SMTP-AUTH in the security considerations section.

RFC 4954 is authoritative for SMTP AUTH.  If there is a mess around 
SMTP AUTH and it has to be fixed, the best place to do so is in a 
revision of RFC 4954.  This draft is more about the separation of 
submission and relay of messages.

The intent is to publish the document as a Full Standard.  As much as 
it may be sensible to describe the desired authentication model, it 
had to be shown that changes would
contribute in a substantial and substantive way to the quality and 
comprehensibility of the specification as that was the guideline 
given to working group participants.  If you would like to recommend 
additional text, I suggest sending a message to the YAM mailing list.

If there are any questions that have not addressed to your 
satisfaction, please let me know so that I can bring it to the 
attention of the working group.

Regards,
S. Moonesamy