On Friday 18 March 2016 08:57:26 Peter Gutmann wrote: > Watson Ladd <watsonbl...@gmail.com> writes: > >Likewise, this draft modifies the way the master secret is computed, > >despite a widely implemented different solution to the problem, > >namely the EMS triple handshake fix. > > Firstly, that solves an entirely different problem, and secondly I > don't recall ever seeing EMS support in any embedded device, it may > be widely implemented in Windows and OpenSSL but I don't know how > much further it goes.
it may solve a different problem, but its solution is a superset of what you propose I haven't seen support for X9.42 DHE parameters or selective mixing in of them to master secret in embedded devices either... you modify behaviour of Master Secret calculation one way or another, let's do this in a way that is interoperable with other implementations, not add a third way to do that also, if it really is supposed to be Long Term Support, why it doesn't say anything about implementation explicitly being able to handle big key sizes? both RSA and DHE? I might have missed, but where is the specification of the acceptable signature algorithms (hash especially) on Server and Client Key Exchange messages? Finally, I'd prefer the tls-lts to mostly say "see those other extensions? I really do mean it" + some pleasantries like the "no rehandshake". -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
