On 10/25/2017 06:29 PM, Eric Rescorla wrote:
dh-group = ALPHA *(ALPHA / DIGIT / "_")
I might want to include hyphen here because "P-256"
done.
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.
OK. Chris?
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.).
No, they're not.
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.
I think that success validation needs to be a MUST.
Ah, now I understand. Changed to MUST validate + SHOULD TLS >= 1.1.
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.
The issue here is that it exposes it not to the server (though it
does) but to anyone on the
wire. This is actually better with TLS 1.3.
ok, clarified the paragraph that I wrote.
Keith
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
