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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
