There is (going to be a re-spin). There already is a PR there. If you can make a PR to solve your issue, that would be great.
> On 15 Mar 2017, at 19:20, David Benjamin <david...@chromium.org> wrote: > > If there's to be a respin anyway, I have another small editorial comment: > https://github.com/tlswg/rfc4492bis/issues/36 > <https://github.com/tlswg/rfc4492bis/issues/36> > > On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <e...@rtfm.com > <mailto:e...@rtfm.com>> wrote: > FWIW, there's a lot here, but I think it's all essentially editorial, so it > shouldn't > be that hard to clean up. > > -Ekr > > > On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie > <mailto:stephen.farr...@cs.tcd.ie>> wrote: > > Thanks Eric, > > Let's see what folks say in response to this and I can post > anything not immediately resolved as a DISCUSS ballot. We > can then process that in the coming week or two, and you > can take over the DISCUSS for whatever's not resolved by > the swap-over in Chicago. Or if someone else wants to > make some or all of Eric's comments a DISCUSS that'd work > too, but I'm fine with taking it. > > Cheers, > S. > > On 15/03/17 14:44, Eric Rescorla 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? > > > > > > 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 <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
