Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate

This is a bit of a shameless plug, but I think it is important to cite papers that show that the use of weak hash functions for TLS signatures is actually exploitable.

As far as I know, the last round of deprecating MD5 in TLS signatures was triggered by the SLOTH attack:

https://www.mitls.org/pages/attacks/SLOTH

The associated paper explains how weak hash functions can allow an attacker to break protocols like TLS, SSH, etc.

https://www.mitls.org/downloads/transcript-collisions.pdf

This probably deserves to be added to the references of this draft.

@inproceedings{BhargavanL16,
  author    = {Karthikeyan Bhargavan and Gaetan Leurent},
  title     = {Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH},
  booktitle = {Proceedings of the {ISOC} Network and Distributed System Security Symposium ({NDSS} '16)},
  month     = {Feb},
  year      = {2016},
  url       = {
http://www.mitls.org/downloads/transcript-collisions.pdf
}
}

Best regards,
Karthik

> On 23 Nov 2019, at 14:40, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote:
>> On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
>>> On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rsalz@akamai.com> wrote:
>>> 
>>>>> ...
>>>> SHA-1 signature hashes in TLS 1.2" draft available
>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.
>>>> Please review the document and send your comments to the list by 2359 UTC
>>>> on 13 December 2019.
>>>> 
>>>> I just re-read this.  Looks good. Perhaps a sentence of rationale in ...
>>> 
>>> To that end, the combination of client advice in sections 2 and 4 is a bit
>>> odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says
>>> the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would
>>> the client include it in that case? It seems the two should either both be
>>> MUST NOT or both be SHOULD NOT.
>> 
>> because it also influences certificate selection, and getting a certificate
>> signed with SHA-1 isn't an automatically disqualifying property?
>> (it may be an intermediate CA that's not used, it may be an explicitly
>> trusted
>> certificate, etc.)
> 
> If you don't want SHA-1 exchange signatures, you darn sure do not want
> actual SHA-1 certificates that are not trust anchors anyway. And because
> TLS 1.2 does not have separate lists for exchange signatures and
> certificate signatures, the client needs to withdraw advertisment for
> both in order to not send a misleading offer.
> 
> And I expect that in practice, not sending SHA-1 in
> signature_algorithms would cause very little breakage on top of what
> is already broken due to using SHA-1 exchange signatures.
> 
> 
> So I think both should be MUST NOT.
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls