On Friday, 15 December 2017 19:07:16 CET Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is > broken, we're in serious trouble, but that's largely because of the fact > that that's what people's certificates have, so clients really can't refuse > to support SHA-256 certificates. So, how does adding new algorithms help? > (That's why I would argue that the existing SHA-384 support doesn't help). >
we are in the process of standardising Ed25519 for X.509 and TLS which doesn't use SHA-256 or SHA-384, so the fact that TLS will still use SHA-256 PRF with such certificates is a liability. > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara <ilariliusva...@welho.com> > > wrote: > > On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: > > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara > > > > > > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > > > > 1.2 and 1.3 break. There are no alternatives defined. > > > > > > Here's an attempt to define a SHA-2 alternative: > > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > > > > Also would need TLS ciphersuite codepoints with alternative handshake > > hash algorithms. > > > > > > -Ilari > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 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
