So, this has been discussed extensively at the CA/Browser forum, for obvious reasons.
In my mind, it is not so important to identify and define and implement an alternative hash. What *is* important is that the protocol and associated software is able to support a smooth transition period where people are moving from one algorithm to another. Ideally, you'd want certificates to be able to have two signatures during the transition period, in order to support clients who have transitioned and those who have not. Unfortunately RFC 5280 is deficient in that regard. Hosting multiple certificates and switching based on the client is feasible, but requires some technical wizardry and isn't possible in all situations. A lot of these transitions are painful because with the way things currently work, algorithms have to reach near ubiquity before the transition can begin (the popularity of Windows XP was a huge problem). The transition will happen at different rates for various industries and use cases that have different security requirements, so everyone needs to be able to move at a pace that makes sense for their needs. It needs to be carefully coordinated, and yes, transitions will take years. The current maximum certificate lifetime is a compromise between the speed at which changes can be made, and the pain imposed by replacement, which largely still isn't automated. I know people are working to improve that, but we are where we are. -Tim > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Friday, December 15, 2017 11:50 AM > To: Andrei Popov <andrei.po...@microsoft.com> > Cc: tls@ietf.org > Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS > > On Fri, Dec 15, 2017 at 06:41:06PM +0000, Andrei Popov wrote: > > It's true, the migration will be slow, but IMHO it still makes sense > > to define and implement an alternative hash. > > Agreed. However, on certificates front, we need a method to perform > backward-compatible algorithm transition. Because non-backward- > compatible ones are just too hard. As we have seen _twice_. > > On TLS handshake hashes, the transitions are already backward- compatible. > But that does not mean the transition will be easy. > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
