On Tue, Mar 21, 2017 at 12:44 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
> Hi > > This pull request addresses most of these comments. > 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. > Well, assuming you don't do TOFU. , 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. > Well, we certainly did that, but why? > The alternative is to either deprecate it for TLS 1.2 > This seems like it might be reasonable at this point. > or to not obsolete 4492. NULL is a little more nuanced, but I think the > same argument applies. > What we probably should actually do is make this depend on the IANA draft and then mark these Not Recommended. -Ekr > > Yoav > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
