Subject: [Uta] Mirja Kühlewind's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 23 Oct 2017 07:50:00 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

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

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.

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.

3) This document should probably have a reference to DNSSEC, I guess that's
rfc4033...

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?

5) s/were not met by the connecting/were not met by the connection/

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?

7) sec 6: is there a useful reference to the milter protocol that can be
provided?

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Oct 2017 22:38:52 -0400

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.

> I guess this should rather be lower case "may" but the RFC editor might have

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.

> 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

agree.

> certificate validation"? However, what's the case were you wouldn't do it as

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

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

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Oct 2017 08:37:17 +0200

> were no objections to that in WGLC.

correct, this has been discussed and standards-track represents the
consensus of the WG

	Cheers Leif

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 25 Oct 2017 07:29:38 -0700

On October 23, 2017 at 10:39:00 PM, Keith Moore ([email-masked])
wrote:

Hi!

I just put the same comment in my Ballot, but to not have the same
discussion on another thread...

Maybe that rewrite is what is making it sound so much like a BCP.  The
document talks in many places about recommendations that it makes (not
behavior that it specifies) — and even the Shepherd’s write up says that it
"closely matches much of current practice for how mail services are
operated.”  All that screams BCP to me.

In any case, no need to beat a dead horse; I just wanted my opinion to be
on the record.

Thanks!

Alvaro.