On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Fri, Dec 15, 2017 at 10:07:16AM -0800, 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). > > TLS handshake assumes the hash function is strongly collision- > resistant. So if SHA-256/SHA-384 breaks, the handshake hash function > needs to be replaced. > Yes. In 1.3, you would define new cipher suites with the new hash. But of course you then have to worry about downgrade if clients jointly support the weakest hash and it's weak enough. -Ekr This is separate from certificate signatures. Transitioning this would > be much more nasty than TLS handshake hash, because there is no > backward-compatible way of changing the hash. This is one major reason > why SHA-1 transition took over 10 years (oh, then there is the "fun" > post-quantum transition possibly coming up). > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls