Subject: [Uta] adopt draft-fenton-smtp-require-tls-03 as WG document

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 12:56:23 +0200

There was clear consensus in Praha to adopt
draft-fenton-smtp-require-tls-03 as a WG document
(draft-ietf-uta-smtp-require-tls-00).

If anyone objects to that, now is the time to speak up.

	Cheers Leif

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 22 Jul 2017 23:57:51 +0200

Hi, Jim,

> If anyone objects to that, now is the time to speak up.

no objection! Just wanted to send my review of -03 here:

Page 3:

Attacks are more described in more detail in the Security
    Considerations section of this document.

s/are more described/are described/

Page 3:

it also requires that the SMTP server advertise that it
    also supports REQUIRETLS

For some reason, I think that the second 'also' is not correct: the 
advertisement is done before the SMTP server 'knows' that the client is 
using REQUIRETLS.

Page 3 (sorry for the nitpicking):

in effect promising that it will honor the
    requirement to require TLS transmission and REQUIRETLS support for
    onward transmission of messages specifying that requirement.

Suggestion:
s/requirement to require/requirement to enforce/

And, referring to the first part of this sentence, you may want to:

s/transmission of messages specifying that requirement/transmission of 
those messages

Page 4:

this option MUST only be specified in the context
    of an SMTP session meeting the security requirements that have been
    specified:

Just for reasons of clarity, you might add a third bullet, which 
describes what already was mentioned earlier:

- the SMTP server advertises that it supports REQUIRETLS.

Page 5:

    3.  Establish a TLS-protected SMTP session with its peer SMTP server
        and authenticate the server's certificate with the specified
        authentication method.

you may want to add a reference to RFC6125 here.

Page 5:

    1.  Look up the SMTP server to which the message is to be sent.

A reference here to RFC5321 par. 5.1 would be nice, as in the remainder 
of this section it may not be clear for a developer that the absence of 
an MX record in the presence of an A record should be treated as an MX 
record with pref. 0 pointing to that host. You have this reference on 
page 6 in the REQUIRETLS=NO section so it would be consistent to add it 
here.

Page 6:

    Following such a failure, the SMTP client MUST send a non-delivery
    notification to the reverse-path of the failed messag

Reading this paragraph it seems there is no room for a client to 
postpone the decision to send a NDN, for example in case of a DNS tempfail.

Page 6:

    o  If the server does not advertise the REQUIRETLS capability, send
       the message in the usual manner (without the REQUIRETLS option,
       because the server will not understand the option).

There are circumstances where a middlebox may remove the REQUIRETLS 
advertisement and for these cases (in combination with REQUIRETLS=NO) it 
might still be useful to send the MAIL FROM with the REQUIRETLS option 
in order to convey the wish of the sender to send using a TLS encrypted 
channel. Comments?

Page 7:

    Mail delivery agents supporting REQUIRETLS SHOULD require that
    retrieval of messages requiring transport encryption take place over
    authenticated, encrypted channels.

AFAIK there is no mechanism where an MDA could require this from the 
Mail Access Server. Unless you mean the MDA should set some sort of 
flag, which then can be honored by the mail access server?

Page 8:

REQUIRETLS users SHOULD use caution
    when sending to mailing lists and MUST NOT assume that REQUIRETLS
    applies to messages from the list operator to list members.

Usually, users clicking on a 'Require encryption' button will not read 
this RFC and often do not even know whether a To: or Cc: mail address 
they use is a mailing list with specific characteristics. So I wonder if 
this line in the draft should better address the owner of the domain, 
recommending to educate their users not too expect (end2end) encryption 
in all cases.

Par. 7:

I wonder if a fourth attack vector should be mentioned: a DOS type of 
attack where an attacker uses REQUIRETLS, using the RFC5321.MailFrom 
address of a victim (using an MTA supporting REQUIRETLS) and sending 
messages to as many MTA's-not-supporting-REQUIRETLS it can find, 
resulting in a bombardment of the victim with NDN's. However, this type 
of DOS attack can be achieved already in other ways, so I think it need 
not be mentioned.

/rolf

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Jul 2017 12:14:17 -0700

Rolf, thanks very much for your review, including the nitpicking.
Responses to a few items below.

> - the SMTP server advertises that it supports REQUIRETLS.

No harm in including that, but I think it's already required by RFC 5321
(see below).
> you may want to add a reference to RFC6125 here.

Good idea, but I notice that RFC6125 doesn't seem to cover DANE
verification. Should it also reference a DANE counterpart? Is RFC6698
the right one to use?

> postpone the decision to send a NDN, for example in case of a DNS

This is outside the loop (steps 1-4 earlier in Section3.2.1) of trying
all of the individual MX hosts and trying to negotiate an acceptable
connection with each. I expect any handling of tempfails would happen
inside that loop. Is there another tempfail possibility at this level?

> advertisement and for these cases (in combination with REQUIRETLS=NO)
> it might still be useful to send the MAIL FROM with the REQUIRETLS
> option in order to convey the wish of the sender to send using a TLS
> encrypted channel. Comments?

RFC5321 Section 4.1.1.2 (MAIL command) says:
"If service extensions were negotiated, the MAIL command may also carry
parameters associated with a particular service extension."

which I read to say that one shouldn't (mustn't?) include parameters for
service extensions that weren't negotiated. It isn't as strong as
4.1.1.3 (RCPT command) which additionally says:
"The client MUST NOT transmit parameters other than those associated
with a service extension offered by the server in its EHLO response."

but I would still be concerned about adding a parameter to the MAIL
command that might interfere with interoperability.

> flag, which then can be honored by the mail access server?

An easy way to satisfy this requirement is just to use authenticated,
encrypted channels all the time (ala DEEP). There's no reason I can
think of not to do this.

> they use is a mailing list with specific characteristics. So I wonder
> if this line in the draft should better address the owner of the
> domain, recommending to educate their users not too expect (end2end)
> encryption in all cases.

It's not end2end anyway, and users need to be aware of that too.

But which domain do you mean the owner of? The domain of the mailing
list, or that of the sending user? One could also argue that the vendor
of an MUA with a "require encryption" button should provide information
on its limitations. I'll reword that the user should be made aware so it
doesn't seem like the user has the only responsibility here.

> resulting in a bombardment of the victim with NDN's. However, this
> type of DOS attack can be achieved already in other ways, so I think
> it need not be mentioned.

Yes, there are so many easier ways to do this I don't think this adds a
significant additional threat.

Again, thanks for your review.

-Jim