Roni, thanks for your review. Keith, thanks for your responses. I have entered a Yes ballot.
Alissa > On Oct 22, 2017, at 8:43 AM, Roni Even <[email protected]> wrote: > > Keith, > Thanks for your clarifications > I am OK with your response > Roni > > From: Gen-art [mailto:[email protected]] On Behalf Of Keith Moore > Sent: יום ג 17 אוקטובר 2017 03:50 > To: Roni Even; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [Gen-art] Genart last call review of draft-ietf-uta-email-deep-09 > > Thanks for the review. Comments below: > > On 10/16/2017 01:18 AM, Roni Even wrote: > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-uta-email-deep-?? > Reviewer: Roni Even > Review Date: 2017-10-15 > IETF LC End Date: 2017-10-13 > IESG Telechat date: 2017-10-26 > > Summary: The document is almost ready to be published as a standard track RFC > > Major issues: > > Minor issues: > 1. In the document I noticed that key words like recommended are sometime > written in upper case letters and sometime in lower case. is there a reason?. > I > suggest that in section 2 reference RFC 8174 and verify that normative text is > in upper case letters. > Yes, the intent is that only the upper case spellings of these words are to > be interpreted according to RFC 2119. I have no problem with referencing > RFC 8174 to reinforce the point. > > > 2. In section 3.3 I think the text suggests transition > period of couple of years. I think that it would be better to just say that > both mechanisms SHOULD be supported and delete the sentence about transition > period. I also wonder why is it a SHOULD and not a MUST, in which case both > mechanisms will not be supported. > For reference, the -09 text says (referring to Implicit TLS vs. STARTTLS for > SMTP Submission): > > > However, to maximize use of encryption for submission it > is desirable to support both mechanisms for Message Submission over > TLS for a transition period of several years. As a result, clients > and servers SHOULD implement both STARTTLS on port 587 and Implicit > TLS on port 465 for this transition period. > > First, my opinion is that operational decisions should generally be allowed > more leeway than protocol implementation decisions, because there is more > variability among operational scenarios than among protocol implementations. > Also MUST is sometimes necessary when specifying requirements on protocol > implementations simply to ensure that implementations interoperate, or that > important pitfalls (like security holes) are avoided. So I will lean toward > SHOULD whenever writing text that makes operational recommendations. > > And yet, it seems like some encouragement to narrow practice (between > Implicit TLS and STARTTLS) in the long term would have broad benefits for the > Internet - not only in providers only needing to support one of those > mechanisms, but also in reduced support costs (less likelihood of > misconfiguring a user agent), less potential for exposure of cleartext > passwords, and reduced burden for user agent implementors/maintainers. So > some sort of encouragement along these lines seems appropriate. Whether this > should be "SHOULD" or "should" could be debated, and I could live with > either. But "SHOULD" seems about right to me. > > > Nits/editorial comments: > > 1. In section 3.4 what is "gracefully close" is there a reference? > > Chris wrote this text but I think it essentially means close() rather than > shutdown() after sending the TCP close alert message. i.e. issue a TCP > CLOSE (send FIN, wait for FIN-ACK, send FIN-ACK) rather than immediately > abandon the connection and send RSTs in response to any traffic received for > it. > > I'd be fine with changing the wording to clarify this. > > > 2. In section 4 fourth bullet what is near term? I assume that as long as > there is no other document that says otherwise MSPs SHOULD also provide it. > > "Near term" is deliberately vague, and it's up to each operator to decide for > itself how long to continue to support STARTTLS, presumably based on the > needs of the operator's enterprise or user community. Some operators will > find it much easier to phase out old clients than others. > > > 3. > In section 4.1 " password sent as cleartext SHOULD be required to change" I > think it means "MUST change" > > > Also, users previously authenticating with passwords sent as > cleartext SHOULD be required to change those passwords when migrating > to TLS, since the old passwords were likely to have been compromised. > > > "SHOULD" is intended. Again, this is in keeping with the philosophy that > operational scenarios vary more than implementation scenarios, so it's > important to give operators an appropriate amount of leeway. If, for > instance, an operator reliably knows that old passwords were not likely to > have been compromised (maybe all access was via VPN anyway), or if forcing > changes to existing passwords would be tremendously disruptive, or if > multi-factor authentication were employed, an operator might have a good > reason to not force password changes. It's hard to enumerate all of the > situations in which an operator might have good reason to not force password > changes. But that's exactly what SHOULD is for. > > Keith > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
