----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
The document reads like a BCP to me. Was it discussed in the group to go for
BCP? If yes, why was it decided to go not for BCP? If no, I would strong
recommend for BCP.
BCP was discussed in the WG, and there was a vocal minority who
advocated it. My personal feeling was that this is a document that
both specifies protocol (this appropriate for standards track,
especially given the need for demonstrated interoperability to advance
to full Standard) and policy (thus BCP), but the former consideration
tipped the balance in favor of standards track. And it didn't seem to
make sense to split the document into two pieces. I also (somewhat
reluctantly) attempted to rewrite version -08 to be a BCP, after
versions -00 through -07 were intended as standards track. But in
Prague (in response to -08) there was strong support that the document
be standards track, so -09 was intended as standards track again. There
were no objections to that in WGLC.
Nits:
1) sec 4.1: "The specific means employed for deprecation of cleartext Mail
Access
Services and Mail Submission Services MAY vary from one MSP to the
next..."
I guess this should rather be lower case "may" but the RFC editor might have
caught that as well.
The difference between "may" and "MAY" is quite subtle since neither one
specifies a requirement. In my opinion, "MAY" emphasizes that the text
is normative rather than informative. That said, I don't think it would
make much difference in practice.
2) Also sec 4.1:
"It is RECOMMENDED that new users be required to use TLS version 1.1
or greater from the start. "
Should this be TLS1.2 or maybe a MUST? Just double-checking.
One could certainly argue for TLS 1.2. But this is effectively a
requirement on _users_ rather than _operators_. My feeling is that
operators might be reluctant to impose this requirement on new users who
might happen to be running old, but still reasonably secure, mail user
agents. Then again, the early versions of this document are around
three years old by now, and it might be more reasonable for operators to
require TLS 1.2 now than it was then.
A similar argument influences the choice of RECOMMENDED instead of
MUST: operators of large mail systems must often deal with a large and
widely varying population of users, and requiring that new users use
MUAs supporting TLS 1.2 might result in a large number of support
calls. That burden doesn't seem appropriate unless there are serious
known flaws in TLS 1.1. And in general, I prefer leaving it to
operators to determine the best means of encouraging their users to
upgrade, because this can vary from one user community to another.
3) This document should probably have a reference to DNSSEC, I guess that's
rfc4033...
agree.
4) sec 5.2:
"The default minimum expected level of confidentiality for all new
accounts SHOULD be at least use of TLS version 1.1 or greater, and
successful validation of the server's certificate."
Given this sentence defines the default minimum, I would have expected a MUST
here? Or should this maybe be "MUST use TLS1.1 or greater" and "SHOULD do
certificate validation"? However, what's the case were you wouldn't do it as
the default minimum?
Failure to meet the minimum level of confidentiality associated with the
account means the MUA refuses to connect to the server. So it's
important to not set the bar so high that users turn the feature off.
My personal belief is that TLS 1.1 + certificate validation is the
minimum level of confidentiality that a user should accept, because I
expect that MiTM attacks will only become more commonplace. So if I
were only considering my own beliefs/preferences, I would make both TLS
1.1 and certificate validation a MUST. I would also personally
consider a pinned certificate to be adequate if I had previously
authorized its use, but most users might not understand what it means to
say "sure, this certificate is okay".
I guess the bottom line is that this is a compromise between the
authors' and other contributors' preferences, and this probably
indicates some uncertainty about what minimum confidentiality levels
will yield the most improvement in practice. The SHOULD reflects that
uncertainty.
5) s/were not met by the connecting/were not met by the connection/
ok
6) In section 5.4, should there maybe be a recommendation that a MUA should
also offer a way for a user to remove the pinning, e.g. if it was detected
later on that a wrong cert had been pinned?
that certainly makes sense to me.
7) sec 6: is there a useful reference to the milter protocol that can be
provided?
I'm not aware of such a reference. As I understand it, Milter was/is a
sendmail-specific interface that wasn't actually intended to be stable,
and has changed over time depending on the specific sendmail or other
MTA implementation. There's a wikipedia page, an expired web page,
etc., but maybe nothing worth citing.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
