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

From: Roni Even <[email-masked]>
Date: Sun, 15 Oct 2017 22:18:25 -0700

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. 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.

Nits/editorial comments:

1. In section 3.4 what is "gracefully close" is there a reference?
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. 3.
In section 4.1 " password sent as cleartext SHOULD be required to change" I
think it means "MUST change"

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Oct 2017 20:49:50 -0400

Thanks for the review.  Comments below:

On 10/16/2017 01:18 AM, Roni Even wrote:
> 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
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.

> 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.

> 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.

    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

---

From: Roni Even <[email-masked]>
Date: Sun, 22 Oct 2017 12:43:29 +0000

Keith,
Thanks for your clarifications
I am OK with your response
Roni

From: Gen-art [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: יום ג 17 אוקטובר 2017 03:50
To: Roni Even; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] Genart last call review of draft-ietf-uta-email-deep-09

Reviewer: Roni Even

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq><https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Reviewer: Roni Even

Review Date: 2017-10-15

Major issues:

Minor issues:

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.

mechanisms will not be supported.
For reference, the -09 text says (referring to Implicit TLS vs. STARTTLS for SMTP Submission):

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:

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.

"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.

"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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 24 Oct 2017 16:56:15 -0400

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-masked]> wrote:
> 
> Keith,
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>  
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art