Sorry for the late review of this document. I just got to it this
week. I'm sending this as comments rather than issues/PR due to
how late it is in the proces.
I have two high-level comments:
- This document seems to still have a bunch of material about
static DH (especially static DH authentication). I thought we
had agreed to remove that.
- You are inconsistent about using capital 2119 language
and I expect you want to be consistent.
DETAILED
S 2.
All of these key exchange algorithms provide forward secrecy.
This is actually only true if each side generates fresh ephemerals
which does not seem to be required by the spec.
Do we really want to promote ECDH_anon to standards track?
Nit: you want a line break between the last line of Figure 1
and the legend explaining the message types.
S 2.3.
This specification does not impose restrictions on signature schemes
used anywhere in the certificate chain. The previous version of this
document required the signatures to match, but this restriction,
originating in previous TLS versions is lifted here as it had been in
RFC 5246.
This section is about ECDH_anon, so maybe this text belongs in S 2.1 or
2.2.?
S 3.
You have a bunch of lower case 2119 key words here.
If these conditions are not met, the client should send a client
Certificate message containing no certificates. In this case, the
ClientKeyExchange should be sent as described in Section 2, and the
CertificateVerify should not be sent. If the server requires client
authentication, it may respond with a fatal handshake failure alert.
Actually, this "should not be sent" is a MUST NOT, because if you send
an empty certificate, you're forbidden to send CertificateVerify.
S 4.
choice of curves and compression techniques specified by the client.
s/compression techniques/point formats/?
S 5.1.1.
Do you want to rename elliptic_curve_list to named_curve_list?
S 5.1.2.
Three point formats were included in the definition of ECPointFormat
above. This specification deprecates all but the uncompressed point
format. Implementations of this document MUST support the
uncompressed format for all of their supported curves, and MUST NOT
support other formats for curves defined in this specification. For
backwards compatibility purposes, the point format list extension
MUST still be included, and contain exactly one value: the
uncompressed point format (0).
This implies that you have to send supported point formats, but in
S 5.1, this is a SHOULD. I believe what you may be trying to say
here is that if you send the extension, it must be non-empty.
Also, maybe I'm missing it, but where do you say that the default
is to assume that the other side supports uncompressed if it doesn't
do so. This is a backwards compat issue.
S 5.3.
You don't define what "authorized for signatures" is, but I suspect
you're talking about KeyUsage, etc.? If so, don't you need to say
this about ECDHE_ECDSA as well.
S 5.4.
The value named_curve indicates that a named curve is used. This
option SHOULD be used when applicable.
When would you not?
S 5.5.
This defines:
rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(66),
But the specification doesn't actually support this. Note that
the fixed_DH authentication mechanism are specified as having
the client's cert be on the same curve as the long-term
ECDH key, but you've deprecated those KE mechanisms, so as far
as I can tell, static DH auth is impossible
Also:
1. Why isn't the ECDSA cert required to be signing capable.
2. You probably should standardize on ECDSA_sign or ecdsa_sign.
S 5.7.
More text about static DH auth. Also "implicit" can probably go away.
The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363. It conveys this information to the client in
the ClientKeyExchange message using the format defined above.
I don't understand what this means.
S 5.8.
This message is sent when the client sends a client certificate
containing a public key usable for digital signatures, e.g., when the
client is authenticated using the ECDSA_sign mechanism.
This is the only way that things can work now.
S 5.1.1.
Failing to
do so allows attackers to gain information about the private key, to
the point that they may recover the entire private key in a few
requests, if that key is not really ephemeral.
To the best of my knowledge, this only applies to DH, not signature
verification.
S 6.
Do we really want to promote NULL and 3DES to ST?
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
