Hi This pull request addresses most of these comments. https://github.com/tlswg/rfc4492bis/pull/39 <https://github.com/tlswg/rfc4492bis/pull/39> There is some discussion on that PR
Some that are not addressed, I’ve answered below. Let me know if you want me to merge and submit. Yoav On 15 Mar 2017, at 16:44, Eric Rescorla <e...@rtfm.com> wrote > 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? It’s the EC version of DH_anon, which is on the standards-track. I don’t expect to convert the web to use DH_anon, but its security is very much like what you get with a self-issued certificate, with many less bytes on the wire. Anyway, I don’t think this effort is the place to deprecate what is a pretty good mechanism for opportunistic security if nothing else. > > 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/? Since we’re deprecating all point formats other than uncompressed, I just removed the “and” and left it as choice of curves. > S 5.1.1. > Do you want to rename elliptic_curve_list to named_curve_list? Yes > 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. Yeah, neither do I. I reworded it. > 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? The place to remove 3DES is TLS 1.3. The alternative is to either deprecate it for TLS 1.2 or to not obsolete 4492. NULL is a little more nuanced, but I think the same argument applies. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
