Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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" <[e-mail]
on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls