In summary: +1 to Viktor’s argument. -1 to Dave’s. -- Regards, Uri Blumenthal
On 10/11/15, 22:41, "TLS on behalf of Dave Garrett" <tls-boun...@ietf.org on behalf of davemgarr...@gmail.com> wrote: >On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote: >> There's no reason for pessimism > >Sorry, I have to laugh a bit here. :p > >> we're not trying to deprecated deployed >> functionality, there is no TLS 1.3 deployed base. > >Due to the fact that the vast majority of TLS implementations that will >be used are going to be existing ones, upgraded to support TLS 1.3, yes >we are deprecating deployed functionality for that implementation as well >as their users. > >> > Prohibiting TLS 1.3 implementations from using SHA1 certs does not >>break >> > OE. >> >> It does when the SHA-1 leaf certificate is pinned, and/or the server >> has nothing else to send, and its clients rightly don't care. > >In the second case, a correct course of action for the server would be to >send an incomplete or outright empty certificate_list fallback, in which >case the clients that don't care will be fine with it. Pinning a SHA1 >end-entiy (leaf) cert rather than an intermediate just seems like a bad >idea that you can't expect to work forever. In cases where the server >can't handle lack of SHA1, then my response is to fix that before >upgrading TLS. > >> > My goal is to have fewer systems using SHA1 within a reasonable >>timeframe. >> >> That happens automatically in the minimal version of the PR. > >We're both trying to predict possible futures with different thought >processes. I'm concerned that the simpler course is too slow, _not_ >because we need to rush to get rid of SHA1 certs ASAP, but because going >slower requires keeping SHA-1 around in implementations in the interim. >Even requiring settings and code for an algorithm at all poses an attack >surface by itself (we had attacks on supposedly disabled features over >the past year). Every known vulnerable feature is one which we have to be >wary of getting re-enabled or left on accidentally. I consider this risk >to be high enough to not rely on delegation to another layer; you think >that delegation cannot be changed without excessive interop risk. > >I'll post a follow-up question to the WG (with a changed title, as our >discussion here got long) with the options phrased as a question with 3 >main choices (including the option of doing nothing new). If there's no >support for a full drop in SHA-1 support under the new version, then >there won't be a point in pushing for it further, unless there's yet >another SHA-1 revelation in the near future. > > >Dave > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
