Thanks for the review. Comments inline:
On 10/16/2017 12:55 PM, Carlos Pignataro wrote:
Reviewer: Carlos Pignataro
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
Please find some review comments for your consideration, which I hope you find
useful and clear.
Ready with Nits (or Minor Issues)
In general, this document seems to adequately cover the Operational areas
listed in Appendix A of RFC 5706. Deployment, coexistence, migration, and
defaults covered. One area that perhaps deserves more explicit mention of fault
and error condition reporting and notification. Attributes such as indications
to a user are useful tools in the context of this operational review.
Minor Issues and Nits:
I was fairly confused, which could be just an issue on my end, about the use of
lower and uppercase derivations of the word "recommend". For example, is this
in the Intro non-normative? "In brief, this memo now recommends that:". There
is a total of 17 instances of "recommend" and two of "RECOMMEND".
I have accepted the suggestion to reference RFC 8174 and clarify that
"recommend" is non-normative while "RECOMMEND "is normative. This is a
deliberate distinction.
Idnits complains about:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-uta-email-deep-09.txt
The specific means employed for deprecation of cleartext Mail Access
Services and Mail Submission Services MAY vary from one MSP to the
next in light of their user communities' needs and constraints.
Does this MAY denote a requirement, or a statement of fact?
MAY does not impose a requirement even when interpreted per RFC 2119,
since the entire purpose of MAY is to be permissive. But the use of
MAY emphasizes that the text quoted above is normative rather than
informative.
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.
How does the editor quantify the likelihood or otherwise extrapolates on
passwords being compromised?
This is admittedly a bit presumptuous on my part, because I'm imagining
that the operators are usually serving the general public through
otherwise insecure Internet connections. But really the purpose of
"since the old passwords were likely to have been compromised" is to
state an explicit justification for the SHOULD. I suspect it would be
equally effective if the text were to instead read "if the old passwords
were likely to be compromised".
All DNS records advertised by an MSP as a means of aiding clients in
communicating with the MSP's servers, SHOULD be signed using DNSSEC.
As struggle a bit with finding this recommendation within scope, as set up in
the Abstract of the document.
Signing records with DNSSEC aids deployment and use of TLS in several
ways, in particular by allowing use of DANE TLSA records to validate
server certificates, and also in allowing SRV records to be trusted as a
means of configuration. (Also, is an entire document required to be
strictly within the scope of its abstract? )
o MUAs SHOULD be configurable to require a minimum level of
confidentiality for any particular Mail Account, and refuse to
exchange information via any service associated with that Mail
Account if the session does not provide that minimum level of
confidentiality. (See Section 5.2.)
Can this refusal to exchange information cause a user-experience black-hole? In
other words, are there requirements for UI and logging of error conditions here?
Yes, it can cause a user-experience black hole, particularly if the
primary means of supporting the email user is via email. I think the UI
requirements are adequately spelled out elsewhere in the document
(though I'm open to suggestions).
Logging of error conditions is somewhat problematic because these errors
are mostly detected on the user's end, whereas the server end is where
such logging generally does the most good. An earlier draft of this
document defined STS-like protocol extensions that also enabled such
logging, but that document was judged overly complex and burdensome by
some WG participants. IMO such extensions would still be useful but we
decided to narrow the draft to what we could get WG consensus on in the
near term, and defer those extensions to a separate document (if we can
find the energy to write it - the document currently in last call has
taken ~3 years to get this far).
o MUAs SHOULD provide a prominent visual indication of the level of
confidentiality associated with an account configuration (for
example, indications such as "lock" icons or changed background
colors similar to those used by some browsers), at appropriate
times and locations in order to inform the user of the
confidentiality of the communications associated with that
account.
Why are "visual" indications only required? And why color-based indication
levels are exemplified only? These do not seem friendly to color-blind people,
and not useful for visually impaired users, or interfaces that prioritize other
channels. I'd generalize this, and exemplify with icons or colors or...
That seems fair. Maybe something like:
MUAs SHOULD provide a prominent indication of the level of
confidentiality associated with an account configuration that is
appropriate for the user interface (for example, a "lock" icon and/or
changed background colors for a visual user interface; or some sort of
audible indication for an audio user interface).
Keith