On 24 Oct 2017, at 17:31, Keith Moore wrote:
(inline)
Line 186
TLS, and to encourage a greater consistency for how TLS is used,
this
specification now recommends use of Implicit TLS for POP, IMAP,
SMTP
Submission, and all other protocols used between a Mail User
Agent
Do you want to say RECOMMENDED?
Lower case "recommends" (non-2119 meaning) was intentional, though my
reasoning may be unclear: One of the first things I learned while
studying engineering was to not specify the same thing in two
different ways, because subtle differences between the two could
create ambiguity. (I remember this point clearly because about a
year before, someone had constructed a beautiful piece of cabinetry to
my specifications, which completely did not fit into the intended
space because I had made this very error.)
So when writing technical specifications, I believe there should be a
clear distinction between summary text (which glosses over details),
and the text that actually defines the requirements of the
specification. Admittedly this could be called out more
explicitly, though it doesn't seem conventional for IETF RFCs to do
so.
Line 199
greeting, the server and client MUST enter AUTHORIZATION state,
even
if client credentials were supplied during the TLS handshake.
You mean TLS client certificates here, right? Maybe say so
agreed; fixed in -10.
Line 214
remainder of the TCP connection. If client credentials were
provided
during the TLS handshake that the server finds acceptable, the
server
MAY issue a PREAUTH greeting in which case both the server and
client
Same comment above about client credentials == certs.
also fixed in -10.
Line 304
preference to services supporting STARTTLS (if offered). (See
also Section 4.5.)
I note that 6186 is kind of unclear on what should go in SNI. It
obviously
needs to be what you are checking against (which 6186 gets right) but
maybe
it's worth clarifying in this document somewhere.
Hmm. I might need to come back to that one. Lots of layers to
sift through. Feel free to suggest text.
I believe RFC 7817 handles this issue sufficiently.
Line 328
the TLS ciphersuite of the session in which the mail was
received,
in the Received field of the outgoing message. (See Section
4.3.)
Do you want to also suggest that it include the name of the DH group,
if any?
I've attempted to add that attribute but please check the text:
The ESMTPS transmission type <xref target="RFC3848"/>
provides trace
information that can indicate TLS was used when
transferring mail.
However, TLS usage by itself is not a guarantee of
confidentiality or
security. The TLS cipher suite provides additional
information about the
level of security made available for a connection. This
defines a new
SMTP "tls" Received header additional-registered-clause
that is used to
record the TLS cipher suite that was negotiated for the
connection. The
value included in this additional clause SHOULD be the
registered cipher
suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
included in the TLS
cipher suite registry. In the event the implementation does
not know the
name of the cipher suite (a situation that should be
remedied promptly),
a four-digit hexadecimal cipher suite identifier MAY be
used.
In addition, the Diffie-Hellman group name associated with
the
ciphersuite MAY be included (when applicable and known)
following the
ciphersuite name. The ABNF for the field follows:
<figure>
<artwork type="abnf">
tls-cipher-clause = CFWS "tls" FWS tls-cipher [ "group" dh-group ]
tls-cipher = tls-cipher-name / tls-cipher-hex
tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_")
; as registered in IANA cipher suite registry
tls-cipher-hex = "0x" 4HEXDIG
dh-group = ALPHA *(ALPHA / DIGIT / "_")
; as registered in IANA TLS Supported Groups Registry
</artwork>
</figure>
Line 363
refuse a ClientHello message from any client sending a protocol
version number corresponding to any version of SSL or TLS 1.0.
Another way is for the server to accept ClientHello messages from
It's worth being very clear that you mean ClientHello.version, not
the record
version, as this has created a lot of interop problems.
ok
Line 405
implementation does not know the name of the cipher suite (a
situation that should be remedied promptly), a four-digit
hexadecimal
cipher suite identifier MAY be used. The ABNF for the field
follows:
Hard to see how you could realistically get into this state...
Chris wrote this so this is just a guess on my part: I'm assuming
there are TLS APIs out there that let the caller query which
ciphersuite is being used, but the implementation returns an integer
rather than the name, and provides no convenience routine to look up
the name text.
That was deliberate. I've seen too many libraries that botch number to
name lookup, so I wanted to err on the side of including precise and
correct information over information in the preferred form.
Line 518
[RFC7525], TLS 1.1 (or earlier) SHOULD NOT be used unless no
higher version is available during TLS protocol negotiation.
This text doesn't quite seem right, as the client has no idea what
the server
supports, it just knows what it negotiated. Can you explain how this
would be
implemented?
No, I can't explain it either. The client can specify that it can
handle TLS version 1.2 or greater, and the server is supposed to
return the highest TLS version that it supports that is <= the TLS
version specified by the client. But the client has no way to force
the server to negotiate the highest TLS version that it supports.
The only options the client has are things like abort the connection,
and perhaps to try again under different circumstances. Or maybe the
client could abort the connection if it knows (by some unspecified
mechanism) that the server really does support a higher version.
So I think that the corresponding text from RFC 7525 doesn't really
apply to a client.
Since I don't know what else to suggest here, I'll comment out that
sentence.
Yeah, there's no way for the client to determine a higher version of TLS
should be used after the WG leadership insisted we remove the STS-like
functionality from this document; so this text has to go.
Line 594
accounts SHOULD be at least use of TLS version 1.1 or greater,
and
successful validation of the server's certificate. (Future
revisions
to this specification may raise these requirements or impose
This second requirement is more important.
Agree, or at least I think I do (are MiTM attacks taking advantage of
no or weak cert validation really more of a threat than attacks on TLS
< 1.1 protocol or ciphersuites? yeah, I could see that.). But I
certainly want implementors to pay more attention to cert validation.
I'm not sure what change to the text you had in mind, but I reversed
the order to put cert validation first.
Line 672
the such confidentiality is provided. Additional advice on
certificate pinning is present in [RFC6125].
Wow, we have a terrible name clash here, because we also have HPKP
which
everyone calls "pinning". I see 6125 calls it that, so maybe on first
use (S
5.3) can you please differentiate from HPKP
added a note about this.
Line 679
TLS handshake unless the server requests one and the client has
determined the certificate can be safely used with that specific
server, OR the client has been explicitly configured by the user
to
Can you note that this is just a restatement of the rules in TLS?
I attempted to fix this as well as the next item, though it's possible
I'm still missing something:
MUAs MAY implement client certificate authentication on the
Implicit TLS port. An MUA MUST NOT provide a client
certificate
during the TLS handshake unless the server requests one AND at
least one of the following is true: the client has determined
the
certificate can be safely used with that specific server, OR
the
client has been explicitly configured by the user to use that
particular certificate with that server. How to make this
determination is presently implementation specific. (The
requirement that the server request a certificate is just a
restatement of the TLS protocol rules, e.g.
<xref target="RFC5246"/> section 7.4.6. The requirement that
the client
not send a certificate not known to be acceptable to the server
is
pragmatic in multiple ways: the current TLS protocol provides
no way for
the client to know which of potentially multiple certificates
it
should use; also, when the client sends a certificate it is
potentially disclosing its identity (or its user's identity) to
the server - perhaps unnecessarily and for no useful purpose.
Line 681
server, OR the client has been explicitly configured by the user
to
use that particular certificate with that server. How to make
this
determination is presently implementation specific.
The structure of this text is confusing. The rule is:
if (server asked &&
(client determined safe || certificate configured)) {
can use
} else {
can't use
}
reworded text in -10 to try to make this clearer.
Line 781
or interception; this is not intended to mitigate active
attackers
who have compromised service provider systems.
IMPORTANT: Client auth with TLS 1.2 reveals the user's identity. This
is a
privacy issue, and so we need to note it. The options here are not
great with <
1.3 because renegotiation is also bad, so I'm not suggesting a
normative
change, but I think the doc needs to be clear.
Added a paragraph:
Implementors should be aware that use of client certificates with TLS
1.2 likely reveals the user's identity to the server and therefore may
compromise the user's privacy. There seems to be no easy fix other
than to avoid presenting client certificates except when specifically
configured to do so.
I don't view statements of fact as normative changes to a protocol :-).
However, given the adjusted wording I suggested for the client
certificate text based on another IESG comment, I'd tweak this proposed
text to say "avoiding presenting client certificates unless explicit
authorization to do so is present." I'd also have no objection to an
informative reference to the TLS 1.3 draft as a likely future option to
address the concern.
- Chris
Line 959
in RFC 6186 resolves that critique for email. The second bullet
is
correct as well, but not very important because useful deployment
of
security layers other than TLS in email is small enough to be
The second bullet is less correct than it used to be because we no
longer
support export suites. Ordinarily I wouldn't bother to make this
point, but if
we're revisiting this point by point, I think we should note that.
added a note for this.
Keith
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
