Adam Langley <a...@imperialviolet.org> wrote: > On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith <br...@briansmith.org> wrote: > > > I think it is a good idea to implement the session hash extension, in > > general. However, I think it is a bad idea to prescribe it as the > solution > > for this particular problem because: > > > > 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already > > require the check for a non-zero result, and that check is sufficient. > > As discussed on the CFRG list, the plan is that the final curves RFC > will say that the zero check is a MAY. (See > https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html) >
When you say "the plan," whose plan are you referring to? If you read that whole thread, there was a lot of well-founded opposition to that plan. And, that plan was never carried out. That is plain to see, as there was never a draft submitted with such a change. So, I assumed that "the plan" was dropped. This isn't a minor editorial change, so it wouldn't be appropriate (IMO) to have the final spec changed in this respect without having had that change reflected in any draft that people have actually been reviewing. > I don't mind if the integration of curve25519 in TLS requires a > zero-check or not, but what property are people hoping to gain? If one > wants to avoid triple-handshake like issues then session-hash is the > answer. Session Hash is *an* answer, but, for the reasons I already gave in this thread, it isn't the best answer for this. A client can use an RSA key exchange to control the PMS > completely, of course, and, with finite-field DH, a value of zero or > p-1 will usually allow the same. Not if the implementation doesn't implement RSA or finite-field DH. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
