> On 2 Sep 2016, at 8:27 PM, Hubert Kario <hka...@redhat.com> wrote:
> 
> On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote:
>> On 09/02/2016 12:04 PM, Eric Rescorla wrote:
>>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett <davemgarr...@gmail.com
>>> 
>>> <mailto:davemgarr...@gmail.com>> wrote:
>>>    On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote:
>>>> On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara
>>> 
>>>    <ilariliusva...@welho.com <mailto:ilariliusva...@welho.com>> wrote:
>>>>> I also don't see why this should be in TLS 1.3 spec, instead of
>>>>> being
>>>>> its own spec (I looked up how much process BS it would be to
>>> 
>>>    get the
>>> 
>>>>> needed registrations: informative RFC would do).
>>>> 
>>>> I also am not following why we need to do this now. The reason
>>> 
>>>    we defined SHA-2 in
>>> 
>>>> a new RFC was because (a) SHA-1 was looking weak and (b) we had
>>> 
>>>    to make significant
>>> 
>>>> changes to TLS to allow the use of SHA-2. This does not seem to
>>> 
>>>    be that case.
>>> 
>>>    I don't think we strictly _need_ to do this now, however I think
>>>    it's a good idea given that we'll need to do it eventually
>>> 
>>> I'm not sure that that's true.
>> 
>> Predicting future needs is not always reliable, yes.
>> 
>>> From a release-engineering (standards-engineering?) perspective, I still
>> 
>> don't see any reasons to add it now, and do see reasons to not add it now.
> 
> what would be the reasons not to add it now?

Several reasons:
 - This is a core spec. Those don’t traditionally specify new algorithms unless 
they’re MTI (like SHA-256 is TLS 1.2 and RSAPSS here)
 - For now, SHA-3 is yet another national algorithm. Why add this and not 
Streebog? [1]
 - Who’s to tell whether SHA-2 breaks earlier than SHA-3?

So absent a desire to change MTI algorithms, I think publishing a “SHA-3 and 
its use in TLS/IPsec/SSH/other” document is a fine idea, but not as part of any 
core protocol.

Yoav

[1] I’m sure there are excellent reasons why SHA-3 is better. We don’t just add 
any national standard unless we think we need it.



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to