Rolf, thanks very much for your review, including the nitpicking. Responses to a few items below.
On 07/22/2017 02:57 PM, Rolf E. Sonneveld wrote: > > 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. No harm in including that, but I think it's already required by RFC 5321 (see below). > > 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. 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? > > 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. 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? > > 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? 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. > > 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? 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. > > 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. 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. > > 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. 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
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
