RE: [Gen-art] Genart last call review of draft-ietf-uta-email-deep-09

[Roni Even <roni.even@xxxxxxxxxx>]

Keith,

Thanks for your clarifications

I am OK with your response

Roni

 

From: Gen-art [mailto:gen-art-bounces@xxxxxxxx] On Behalf Of Keith Moore
Sent: יום ג 17 אוקטובר 2017 03:50
To: Roni Even; gen-art@xxxxxxxx
Cc: draft-ietf-uta-email-deep.all@xxxxxxxx; uta@xxxxxxxx; ietf@xxxxxxxx
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>.

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