Re: [TLS] I-D Action: draft-ietf-tls-md5-sha1-deprecate-08.txt
> On Sep 4, 2021, at 17:45, David Benjamin wrote: > > On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario wrote: > On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Deprecating MD5 and SHA-1 signature > > hashes in (D)TLS 1.2 > > Authors : Loganaden Velvindron > > Kathleen Moriarty > > Alessandro Ghedini > > Filename: draft-ietf-tls-md5-sha1-deprecate-08.txt > > Pages : 6 > > Date: 2021-09-03 > > > > Abstract: > >The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to > >attack and this document deprecates their use in TLS 1.2 digital > >signatures. However, this document does not deprecate SHA-1 in HMAC > >for record protection. This document updates RFC 5246. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-md5-sha1-deprecate-08 > > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > > messages. > > >Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. > > If a server receives a CertificateVerify message with MD5 or SHA-1 it > > MUST abort the connection with handshake_failure or > > insufficient_security alert. > > As written, this would make already existing implementations not RFC > compliant > when they are configured to not support SHA-1. > > RFC5246 requires the server to abort with illegal_parameter if the > CV included an algorithm that wasn't advertised in CR. > > Ah, good catch. There's also some odd asymmetry here. Section 4 talks about a > server being unable to *send* a ServerKeyExchange (and uses the correct > alerts). It says nothing about the client *receiving* an invalid (by > ClientHello) ServerKeyExchange which is, as in the case you describe, an > illegal_parameter. Meanwhile, Section 5 talks about the server *receiving* an > invalid (by CertificateRequest) CertificateVerify, and with the wrong alerts. > It says nothing about the client being unable to *send* a CertificateVerify. > > I don't feel very strongly about whether we talk about sending, receiving, or > both, for each of these messages. But we should be consistent and use the > right alerts. (Or we could just talk about preferences and let the message > behavior fall out of that.) I think what might solve this is the following (I just included all of the text with 2119-language because there isn’t much of it): 2. Signature Algorithms Clients MUST include the signature_algorithms extension. Clients MUST NOT include MD5 and SHA-1 in this extension. 3. Certificate Request Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest messages. 4. Server Key Exchange Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then it MUST abort the connection with an illegal_parameter alert. 5. Certificate Verify Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1, then it MUST abort the connection with illegal_parameter alert. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] TLS Digest, Vol 206, Issue 12
Nimrod, >From this thread: > Since (if memory serves me) KDF is HMAC-based, rather than merely SHA-based ? it won?t matter from the security point of view whether SHA256 will or will not show collisions. A comparison with PBKDF2-HMAC-SHA1 seems apt as PBKDF2 has an HMAC at its core, though it uses the input as a key rather than as the message, so maybe is not directly comparable. I can't find a strong citation for this, but I believe PBKDF2-HMAC-SHA1 is still considered collision-resistant for inputs less than the block size of the hash function. (for inputs longer than the block size, there are fairly trivial ways to force collisions in PBKDF2, even with SHA256, but that's unrelated to the HMAC; see https://mathiasbynens.be/notes/pbkdf2-hmac). There's also this quote from Thomas Pornin in 2011 (https://stackoverflow.com/questions/4938906/is-sha1-still-secure-for-use-as-hash-function-in-pbkdf2): > None of the currently known weaknesses on SHA-1 has any impact on its > security when used in HMAC, a fortiori when used in PBKDF2. For that matter, > MD5 would be fine too (but not MD4). > However, SHA-1 is not good for public relations: if, in 2011, you use SHA-1, > then you must prepare yourself to have to justify that choice. On the other > hand, SHA-256 is a fine "default function" and nobody will question it. That's not direct proof that "KDF-HMAC-MD5 or KDF-HMAC-SHA1 are still good", but at least I'm not able to find any evidence to the contrary ... --- Mike Ounsworth Software Security Architect, Entrust -Original Message- From: TLS On Behalf Of tls-requ...@ietf.org Sent: September 6, 2021 12:08 PM To: tls@ietf.org Subject: [EXTERNAL] TLS Digest, Vol 206, Issue 12 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. __ Send TLS mailing list submissions to tls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!FJ-Y8qCqXTj2!OJfu0Bw4RAJRNBaTWiveymI3ejCAhENdhuYiYHgrbCMekym94Kjx_qQ9grARj7oxn_y9$ or, via email, send a message with subject or body 'help' to tls-requ...@ietf.org You can reach the person managing the list at tls-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: Combining Secrets in Hybrid Key Exchange in TLS 1.3 (Nimrod Aviram) -- Message: 1 Date: Mon, 6 Sep 2021 20:07:10 +0300 From: Nimrod Aviram To: "Blumenthal, Uri - 0553 - MITLL" Cc: "" Subject: Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3 Message-ID: Content-Type: text/plain; charset="utf-8" I'd like to understand your position better. > Since (if memory serves me) KDF is HMAC-based, rather than merely SHA-based ? it won?t matter from the security point of view whether SHA256 will or will not show collisions. So, if I understand correctly, you argue that the text David Benjamin quoted from Appendix E.1 is wrong? The second paragraph in Appendix E.1.1: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8446*appendix-E.1.1__;Iw!!FJ-Y8qCqXTj2!OJfu0Bw4RAJRNBaTWiveymI3ejCAhENdhuYiYHgrbCMekym94Kjx_qQ9grARjyN8Nzd2$ "This requires the underlying hash function to be collision resistant..." Moreover, if it won?t matter from the security point of view whether SHA256 will or will not show collisions, then this implies that (hypothetically) switching from SHA256 to e.g. MD5 will not degrade security. Is this your position? If so, could you please provide references that support this position, e.g. prove security under a non-CR hash function? > I don?t think so. If I understand correctly, you wrote this in response to me saying "an attacker that can establish multiple PSKs of their choice with another party can cause two sessions with two different PSKs to share the same early_secret... This likely violates the security proof for TLS 1.3, in and of itself." Is this what you're referring to? And I understand that you claim that an attacker achieving this would not violate any proven security property of TLS 1.3? best, Nimrod On Thu, 2 Sept 2021 at 23:32, Blumenthal, Uri - 0553 - MITLL wrote: > The APOP attack demonstrates that concatenating secrets may be > dangerous, as a general cryptographic practice. > > > > I disagree with the word ?general? here. > > > > As to the TLS KDF, if future SHA256 cryptanalysis results in > collisions, > > > > Since (if memory serves me) KDF is HMAC-based, rather than merely > SHA-based ? it won?t matter from the security point of view whether > SHA256 will or will not show collisions. > > > > This likely violates the security proof for TLS 1.3, in and of itself. > > > > I don
Re: [TLS] I-D Action: draft-ietf-tls-md5-sha1-deprecate-08.txt
On Thu, Sep 9, 2021 at 2:12 PM Sean Turner wrote: > > > On Sep 4, 2021, at 17:45, David Benjamin wrote: > > > > On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario wrote: > > On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org > wrote: > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Transport Layer Security WG of the > IETF. > > > > > > Title : Deprecating MD5 and SHA-1 signature > > > hashes in (D)TLS 1.2 > > > Authors : Loganaden Velvindron > > > Kathleen Moriarty > > > Alessandro Ghedini > > > Filename: draft-ietf-tls-md5-sha1-deprecate-08.txt > > > Pages : 6 > > > Date: 2021-09-03 > > > > > > Abstract: > > >The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to > > >attack and this document deprecates their use in TLS 1.2 digital > > >signatures. However, this document does not deprecate SHA-1 in HMAC > > >for record protection. This document updates RFC 5246. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ > > > > > > There is also an htmlized version available at: > > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-md5-sha1-deprecate-08 > > > > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > > > messages. > > > > >Clients MUST NOT include MD5 and SHA-1 in CertificateVerify > messages. > > > If a server receives a CertificateVerify message with MD5 or SHA-1 it > > > MUST abort the connection with handshake_failure or > > > insufficient_security alert. > > > > As written, this would make already existing implementations not RFC > > compliant > > when they are configured to not support SHA-1. > > > > RFC5246 requires the server to abort with illegal_parameter if the > > CV included an algorithm that wasn't advertised in CR. > > > > Ah, good catch. There's also some odd asymmetry here. Section 4 talks > about a server being unable to *send* a ServerKeyExchange (and uses the > correct alerts). It says nothing about the client *receiving* an invalid > (by ClientHello) ServerKeyExchange which is, as in the case you describe, > an illegal_parameter. Meanwhile, Section 5 talks about the server > *receiving* an invalid (by CertificateRequest) CertificateVerify, and with > the wrong alerts. It says nothing about the client being unable to *send* a > CertificateVerify. > > > > I don't feel very strongly about whether we talk about sending, > receiving, or both, for each of these messages. But we should be consistent > and use the right alerts. (Or we could just talk about preferences and let > the message behavior fall out of that.) > > I think what might solve this is the following (I just included all of the > text with 2119-language because there isn’t much of it): > > 2. Signature Algorithms > >Clients MUST include the signature_algorithms extension. Clients >MUST NOT include MD5 and SHA-1 in this extension. > > 3. Certificate Request > >Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest >messages. > > 4. Server Key Exchange > >Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. >If the client receives a ServerKeyExchange message indicating MD5 or >SHA-1, then it MUST abort the connection with an illegal_parameter >alert. > > 5. Certificate Verify > >Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. >If a server receives a CertificateVerify message with MD5 or SHA-1, then >it MUST abort the connection with illegal_parameter alert. LGTM with one comment. (Sorry, for all the last-minute comments! I didn't notice this in my last email. :-( ) It is a little odd that servers advertising MD5/SHA1 in CertificateRequest is merely a SHOULD NOT, but rejecting them in CertificateVerify is a MUST NOT. Though that's also present in the existing text. I forget how we ended up here. Was it to allow for SHA-1 in the Certificate message? ...I wonder if that's why we ended up with the funny alerts. Because if the server declines to do the SHOULD NOT, the client isn't doing anything wrong, protocol-wise, by taking the server up on its offer of SHA-1. If we want to keep it very simple, we could upgrade section 3 to MUST NOT and avoid this problem, but I don't know if there was some reason for the asymmetric expectations here. We could also condition the server rule in section 5 on having taken the SHOULD NOT in section 3. (Prior to TLS 1.3, there is no way to say "SHA-1 is okay in Certificate, but not okay in CertificateVerify/ServerKeyExchange".) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-md5-sha1-deprecate-08.txt
> On Sep 9, 2021, at 15:40, David Benjamin wrote: > > On Thu, Sep 9, 2021 at 2:12 PM Sean Turner wrote: > > > On Sep 4, 2021, at 17:45, David Benjamin wrote: > > > > On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario wrote: > > On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > > > Title : Deprecating MD5 and SHA-1 signature > > > hashes in (D)TLS 1.2 > > > Authors : Loganaden Velvindron > > > Kathleen Moriarty > > > Alessandro Ghedini > > > Filename: draft-ietf-tls-md5-sha1-deprecate-08.txt > > > Pages : 6 > > > Date: 2021-09-03 > > > > > > Abstract: > > >The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to > > >attack and this document deprecates their use in TLS 1.2 digital > > >signatures. However, this document does not deprecate SHA-1 in HMAC > > >for record protection. This document updates RFC 5246. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/ > > > > > > There is also an htmlized version available at: > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-md5-sha1-deprecate-08 > > > > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > > > messages. > > > > >Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. > > > If a server receives a CertificateVerify message with MD5 or SHA-1 it > > > MUST abort the connection with handshake_failure or > > > insufficient_security alert. > > > > As written, this would make already existing implementations not RFC > > compliant > > when they are configured to not support SHA-1. > > > > RFC5246 requires the server to abort with illegal_parameter if the > > CV included an algorithm that wasn't advertised in CR. > > > > Ah, good catch. There's also some odd asymmetry here. Section 4 talks about > > a server being unable to *send* a ServerKeyExchange (and uses the correct > > alerts). It says nothing about the client *receiving* an invalid (by > > ClientHello) ServerKeyExchange which is, as in the case you describe, an > > illegal_parameter. Meanwhile, Section 5 talks about the server *receiving* > > an invalid (by CertificateRequest) CertificateVerify, and with the wrong > > alerts. It says nothing about the client being unable to *send* a > > CertificateVerify. > > > > I don't feel very strongly about whether we talk about sending, receiving, > > or both, for each of these messages. But we should be consistent and use > > the right alerts. (Or we could just talk about preferences and let the > > message behavior fall out of that.) > > I think what might solve this is the following (I just included all of the > text with 2119-language because there isn’t much of it): > > 2. Signature Algorithms > >Clients MUST include the signature_algorithms extension. Clients >MUST NOT include MD5 and SHA-1 in this extension. > > 3. Certificate Request > >Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest >messages. > > 4. Server Key Exchange > >Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. >If the client receives a ServerKeyExchange message indicating MD5 or >SHA-1, then it MUST abort the connection with an illegal_parameter >alert. > > 5. Certificate Verify > >Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. >If a server receives a CertificateVerify message with MD5 or SHA-1, then >it MUST abort the connection with illegal_parameter alert. > > LGTM with one comment. (Sorry, for all the last-minute comments! I didn't > notice this in my last email. :-( ) It is a little odd that servers > advertising MD5/SHA1 in CertificateRequest is merely a SHOULD NOT, but > rejecting them in CertificateVerify is a MUST NOT. Though that's also present > in the existing text. I forget how we ended up here. Was it to allow for > SHA-1 in the Certificate message? > > ...I wonder if that's why we ended up with the funny alerts. Because if the > server declines to do the SHOULD NOT, the client isn't doing anything wrong, > protocol-wise, by taking the server up on its offer of SHA-1. > > If we want to keep it very simple, we could upgrade section 3 to MUST NOT and > avoid this problem, but I don't know if there was some reason for the > asymmetric expectations here. We could also condition the server rule in > section 5 on having taken the SHOULD NOT in section 3. (Prior to TLS 1.3, > there is no way to say "SHA-1 is okay in Certificate, but not okay in > CertificateVerify/ServerKeyExchange".) > > David A lot of this was born out of th
