Hi, Jim,
On 21-07-17 12:56, Leif Johansson wrote:
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.
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
