Re: Opsdir last call review of draft-ietf-uta-email-deep-09

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks for the quick response! Please see inline.

On Oct 16, 2017, at 9:11 PM, Keith Moore <[e-mail]<mailto:[e-mail]>> wrote:

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.

That addresses my concern.


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.

Perhaps I should have asked if it denoted a “requirement level” or fact. Just for completeness: RFC2119, titled “Key words for use in RFCs to Indicate Requirement Levels”, says “several words are used to signify the requirements in the specification”, and then “...these words is modified by the requirement level…”. Based on that, I understand MAY to denote a requirement level as per the use in this document.

   But the use of MAY emphasizes that the text quoted above is normative rather than informative.


I still do not fully understand what the requirement level is in that sentence. What is the OPTIONAL item?

   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.

The text may have the opposite effect than the intended one. And, to me, a small possibility is enough.

I suspect it would be equally effective if the text were to instead read "if the old passwords were likely to be compromised”.

I agree with this. That would be equally (or more) effective.

Thank you for considering.

   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? )

No, the entire document is not required to be scoped in the Abstract only. I understand the technical justification of using DNSSEC, and I did not phrase my comment clearly. My comment was in the context of an Ops Dir review: DNSSEC deployment may lag, but there’s a requirement.


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

Many thanks for this context. The UI requirements are indeed adequately addressed elsewhere, but I would mention the operational risk. And a mention of local logging without making it a requirement might help as well.

But, I am just bringing up a potential improvement, I leave it totally to you to consider if textual changes can improve.

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


That captures it perfectly. Many thanks,

Keith


—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."