Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
> On Jul 28, 2021, at 12:41, Sean Turner wrote:
>
> Daniel,
>
> Thanks for following up on this (I meant to and dropped the ball). Triminng
> to the remaining issue.
>
> spt
>
>>
>>> 6. Updates to RFC5246
>>>
>>> [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
>>> suggests that implementations can assume support for MD5 and SHA-1 by
>>> their peer. This update changes the suggestion to assume support for
>>> SHA-256 instead, due to MD5 and SHA-1 being deprecated.
>>>
>>> In Section 7.4.1.4.1: the text should be revised from:
>>>
>>> OLD:
>>>
>>> "Note: this is a change from TLS 1.1 where there are no explicit
>>> rules, but as a practical matter one can assume that the peer
>>> supports MD5 and SHA- 1."
>>>
>>> NEW:
>>>
>>> "Note: This is a change from TLS 1.1 where there are no explicit
>>> rules, but as a practical matter one can assume that the peer
>>> supports SHA-256."
>>>
>>>
>>>
>>> I am reading the Note as an explanation on
>>> why sha was taken as the default hash
>>> function with the following rules.
>>>
>>> """
>>> If the client does not send the signature_algorithms extension, the
>>> server MUST do the following:
>>>
>>> - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
>>> DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
>>> sent the value {sha1,rsa}.
>>>
>>> - If the negotiated key exchange algorithm is one of (DHE_DSS,
>>> DH_DSS), behave as if the client had sent the value {sha1,dsa}.
>>>
>>> - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
>>> ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
>>> """
>>>
>>> The current document does not update the
>>> default hash function from sha to sha256 to
>>> avoid interoperability issue where one peer
>>> takes sha while the other one takes sha-256.
>>
>> You are right that this section, which is updating TLS1.2 [RFC5246], is
>> not changing the default to SHA-256, but the recommendations for
>> configuring TLS 1.2, which are provided in RFC 7525/BCP 195, is being
>> updated to recommend SHA-256 in the very next section.
>>
>
> Updating the update works. It believe that saying a section should be
> remove is not too hard, and it seems to me that mentioning the default
> behaviour is important. I would say that could get implementers confused
> to implement part of the specifications that do not hold any more. I
> would prefer to have this being addressed.
>
> I am reading RFC7525 as recommending a non default parameter while this
> document removed the support of default parameters. So to me the updating
> the status of the default parameters seems more updating the 5246 then
> 7525.
>
>
>>> As a results, these rules and the "Note" may
>>> eventually all together be replaced by your
>>> text of section 2.
>>>
>>> The following text may also be removed:
>>>
>>> """
>>> If the client supports only the default hash and signature algorithms
>>> (listed in this section), it MAY omit the signature_algorithms
>>> extension.
>>> """
>>
>> So we might do it, but the question is whether implementers are going to
>> be confused if we don’t do it. I think because s1 already says that
>> client MUST send a signature_algorithms extension that we don’t have to
>> indicate that that particular sentence be dropped/removed from the
>> draft. I will admit this document mixes the two ways to do a bis
>> document, i.e., old/new and describing blanket changes, but I think the
>> intent is pretty clear based on the brevity of the draft.
>>
>
>
> I agree we may be able to find all the dots. I think this provides more
> insight to clarify the reading of 5246. I agree the intend is clearly
> stated in the title and section 2 addresses most of it and I believe that
> some flexibility is permitted, but that is unclear to me where to put the
> bar. I still believe that could be easily be addressed.
>
>
>>
>> I think I have lost a bit where we are, but I tend to agree that
>> clarification of 5246 would be clearer here. That is mentioning the text
>> that needs to be removed / changed.
>>
>>
>> I do not see 07 mentioning the text to be removed - that is now dead text. I
>> think that would be clarifying.
>>
>
> To recap:
>
> You are suggesting that we add the following in s6 before the existing
> OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.":
>
> In Section 7.1.4.1: the following text is removed:
>
> If the client supports only the default hash and signature algorithms
> (listed in
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Daniel,
Thanks for following up on this (I meant to and dropped the ball). Triminng to
the remaining issue.
spt
>
> >> >> > 6. Updates to RFC5246
> >> >> >
> >> >> > [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
> >> >> > suggests that implementations can assume support for MD5 and SHA-1
> >> >> > by
> >> >> > their peer. This update changes the suggestion to assume support
> >> >> > for
> >> >> > SHA-256 instead, due to MD5 and SHA-1 being deprecated.
> >> >> >
> >> >> > In Section 7.4.1.4.1: the text should be revised from:
> >> >> >
> >> >> > OLD:
> >> >> >
> >> >> > "Note: this is a change from TLS 1.1 where there are no explicit
> >> >> > rules, but as a practical matter one can assume that the peer
> >> >> > supports MD5 and SHA- 1."
> >> >> >
> >> >> > NEW:
> >> >> >
> >> >> > "Note: This is a change from TLS 1.1 where there are no explicit
> >> >> > rules, but as a practical matter one can assume that the peer
> >> >> > supports SHA-256."
> >> >> >
> >> >> >
> >> >> >
> >> >> > I am reading the Note as an explanation on
> >> >> > why sha was taken as the default hash
> >> >> > function with the following rules.
> >> >> >
> >> >> > """
> >> >> > If the client does not send the signature_algorithms extension, the
> >> >> > server MUST do the following:
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
> >> >> > DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
> >> >> > sent the value {sha1,rsa}.
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (DHE_DSS,
> >> >> > DH_DSS), behave as if the client had sent the value {sha1,dsa}.
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
> >> >> > ECDHE_ECDSA), behave as if the client had sent value
> >> >> > {sha1,ecdsa}.
> >> >> > """
> >> >> >
> >> >> > The current document does not update the
> >> >> > default hash function from sha to sha256 to
> >> >> > avoid interoperability issue where one peer
> >> >> > takes sha while the other one takes sha-256.
> >> >>
> >> >> You are right that this section, which is updating TLS1.2 [RFC5246], is
> >> >> not changing the default to SHA-256, but the recommendations for
> >> >> configuring TLS 1.2, which are provided in RFC 7525/BCP 195, is being
> >> >> updated to recommend SHA-256 in the very next section.
> >> >>
> >> >
> >> > Updating the update works. It believe that saying a section should be
> >> > remove is not too hard, and it seems to me that mentioning the default
> >> > behaviour is important. I would say that could get implementers confused
> >> > to implement part of the specifications that do not hold any more. I
> >> > would prefer to have this being addressed.
> >> >
> >> > I am reading RFC7525 as recommending a non default parameter while this
> >> > document removed the support of default parameters. So to me the
> >> > updating the status of the default parameters seems more updating the
> >> > 5246 then 7525.
> >> >
> >> >
> >> >> > As a results, these rules and the "Note" may
> >> >> > eventually all together be replaced by your
> >> >> > text of section 2.
> >> >> >
> >> >> > The following text may also be removed:
> >> >> >
> >> >> > """
> >> >> > If the client supports only the default hash and signature algorithms
> >> >> > (listed in this section), it MAY omit the signature_algorithms
> >> >> > extension.
> >> >> > """
> >> >>
> >> >> So we might do it, but the question is whether implementers are going
> >> >> to be confused if we don’t do it. I think because s1 already says that
> >> >> client MUST send a signature_algorithms extension that we don’t have to
> >> >> indicate that that particular sentence be dropped/removed from the
> >> >> draft. I will admit this document mixes the two ways to do a bis
> >> >> document, i.e., old/new and describing blanket changes, but I think the
> >> >> intent is pretty clear based on the brevity of the draft.
> >> >>
> >> >
> >> >
> >> > I agree we may be able to find all the dots. I think this provides more
> >> > insight to clarify the reading of 5246. I agree the intend is clearly
> >> > stated in the title and section 2 addresses most of it and I believe
> >> > that some flexibility is permitted, but that is unclear to me where to
> >> > put the bar. I still believe that could be easily be addressed.
> >> >
> >> >
>
> I think I have lost a bit where we are, but I tend to agree that
> clarification of 5246 would be clearer here. That is mentioning the text that
> needs to be removed / changed.
>
>
> I do not see 07 mentioning the text to be removed - that is now dead text. I
> think that would be clarifying.
>
To recap:
You are suggesting that we add the following in s6 before the existing OLD/NEW,
i.e., right after "due to MD5 and SHA-1 being deprecated.":
In Section 7.1.4.1: the following text is removed:
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Hi, Thanks Logan for posting the new version. I am trying to summarize where we are with version 07. I think there is one remaining concern that has not been addressed, though it is not clear to me how we agreed to address it. Yours, Daniel On Tue, May 4, 2021 at 11:17 PM Daniel Migault wrote: > Hi, > > Thanks for the update and the followup. To me the only remaining point I > am not sure has been fully addressed is the clarification of 5246, but > otherwise we agree on the content to be written. Please find my comments > inline. > > Yours, > Daniel > > On Tue, May 4, 2021 at 1:23 PM Sean Turner wrote: > >> Daniel, >> >> Thanks for your (and the WG’s) patience on this. Responses in line. >> >> spt >> >> > On Apr 9, 2021, at 14:54, Sean Turner wrote: >> >> On Jan 22, 2021, at 08:23, Daniel Migault wrote: >> >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron < >> logana...@gmail.com> wrote: >> >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault >> wrote: >> >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: >> >> >> >> >> >> >> >> >> Please note the comment about Section 3 suggests changing server >> behavior from SHOULD NOT to a MUST NOT. >> >> >> >> >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker < >> nore...@ietf.org> wrote: >> >> >> > >> >> >> > Reviewer: Daniel Migault >> >> >> > Review result: Ready with Nits >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > >> >> >> > I reviewed this document as part of the IoT Directorate's ongoing >> effort to >> >> >> > review all IETF documents being processed by the IESG. These >> comments were >> >> >> > written primarily for the benefit of the Security Area >> Directors. Document >> >> >> > authors, document editors, and WG chairs should treat these >> comments just like >> >> >> > any other IETF Last Call comments. >> >> >> > >> >> >> > Review Results: Ready with Nits >> >> >> > >> >> >> > Please find my comments below. >> >> >> > >> >> >> > Yours, >> >> >> > Daniel >> >> >> > >> >> >> > >> >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 >> >> >> > draft-ietf-tls-md5-sha1-deprecate-04 >> >> >> > [...] >> >> >> > >> >> >> > 1. Introduction >> >> >> > >> >> >> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >> >> >> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be >> >> >> > insecure, subject to collision attacks [Wang]. In 2011, >> [RFC6151] >> >> >> > detailed the security considerations, including collision >> attacks for >> >> >> > MD5. NIST formally deprecated use of SHA-1 in 2011 >> >> >> > [NISTSP800-131A-R2] and disallowed its use for digital >> signatures at >> >> >> > the end of 2013, based on both the Wang, et. al, attack and the >> >> >> > potential for brute-force attack. In 2016, researchers from >> INRIA >> >> >> > identified a new class of transcript collision attacks on TLS >> (and >> >> >> > other protocols) that rely on efficient collision-finding >> algorithms >> >> >> > on the underlying hash constructions [Transcript-Collision]. >> >> >> > Further, in 2017, researchers from Google and CWI Amsterdam >> >> >> > [SHA-1-Collision] proved SHA-1 collision attacks were practical. >> >> >> > This document updates [RFC5246] and [RFC7525] in such a way >> that MD5 >> >> >> > and SHA-1 MUST NOT be used for digital signatures. However, >> this >> >> >> > document does not deprecate SHA-1 in HMAC for record protection. >> >> >> > >> >> >> > >> >> >> > RFC6194 may be mentioned as a reference for >> >> >> > not deprecating HMAC-SHA-1 as well as an >> >> >> > additional reference to [NISTSP800-131A-R2]. >> >> >> >> >> >> Are asking for something like this: >> >> >> >> >> >> OLD: >> >> >> >> >> >> In 2011, [RFC6151] detailed the security considerations, >> >> >> including collision attacks for MD5. >> >> >> >> >> >> NEW: >> >> >> >> >> >> In 2011, [RFC6151] [RFC6194] detailed the security considerations, >> >> >> including collision attacks for MD5 and SHA-1, respectively. >> >> >> >> >> >> > Reading the text the situation of HMAC with >> >> >> > MD5 is unclear. Since we specify that SHA-1 >> >> >> > is not deprecated for HMAC we may specify >> >> >> > the status for HMAC with MD5. Given RFC6151 I >> >> >> > hope the reason is that MD5 and HMAC-MD5 has >> >> >> > already been deprecated but I have not found >> >> >> > this. Maybe that would worth mentioning it >> >> >> > is deprecated already. >> >> >> > >> >> >> > >> >> >> >> >> >> Are you asking for something like this: >> >> >> >> >> >> OLD: >> >> >> >> >> >> However, this document does not deprecate SHA-1 in HMAC >> >> >> for record protection. >> >> >> >> >> >> However, this document does not deprecate MD-5 or SHA-1 HMAC >> >> >> for record protection. >> >> > >> >> > >> >> > maybe we could add these are still considered as secured at the time >> of writing. It is also tempting to add that given we deprecate sha1 and >> md5 in the
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Hi, Thanks for the update and the followup. To me the only remaining point I am not sure has been fully addressed is the clarification of 5246, but otherwise we agree on the content to be written. Please find my comments inline. Yours, Daniel On Tue, May 4, 2021 at 1:23 PM Sean Turner wrote: > Daniel, > > Thanks for your (and the WG’s) patience on this. Responses in line. > > spt > > > On Apr 9, 2021, at 14:54, Sean Turner wrote: > >> On Jan 22, 2021, at 08:23, Daniel Migault wrote: > >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron < > logana...@gmail.com> wrote: > >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault > wrote: > >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: > >> >> > >> >> > >> >> Please note the comment about Section 3 suggests changing server > behavior from SHOULD NOT to a MUST NOT. > >> >> > >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker < > nore...@ietf.org> wrote: > >> >> > > >> >> > Reviewer: Daniel Migault > >> >> > Review result: Ready with Nits > >> >> > > >> >> > Hi, > >> >> > > >> >> > > >> >> > I reviewed this document as part of the IoT Directorate's ongoing > effort to > >> >> > review all IETF documents being processed by the IESG. These > comments were > >> >> > written primarily for the benefit of the Security Area Directors. > Document > >> >> > authors, document editors, and WG chairs should treat these > comments just like > >> >> > any other IETF Last Call comments. > >> >> > > >> >> > Review Results: Ready with Nits > >> >> > > >> >> > Please find my comments below. > >> >> > > >> >> > Yours, > >> >> > Daniel > >> >> > > >> >> > > >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > >> >> > draft-ietf-tls-md5-sha1-deprecate-04 > >> >> > [...] > >> >> > > >> >> > 1. Introduction > >> >> > > >> >> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > >> >> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be > >> >> > insecure, subject to collision attacks [Wang]. In 2011, > [RFC6151] > >> >> > detailed the security considerations, including collision > attacks for > >> >> > MD5. NIST formally deprecated use of SHA-1 in 2011 > >> >> > [NISTSP800-131A-R2] and disallowed its use for digital > signatures at > >> >> > the end of 2013, based on both the Wang, et. al, attack and the > >> >> > potential for brute-force attack. In 2016, researchers from > INRIA > >> >> > identified a new class of transcript collision attacks on TLS > (and > >> >> > other protocols) that rely on efficient collision-finding > algorithms > >> >> > on the underlying hash constructions [Transcript-Collision]. > >> >> > Further, in 2017, researchers from Google and CWI Amsterdam > >> >> > [SHA-1-Collision] proved SHA-1 collision attacks were practical. > >> >> > This document updates [RFC5246] and [RFC7525] in such a way that > MD5 > >> >> > and SHA-1 MUST NOT be used for digital signatures. However, this > >> >> > document does not deprecate SHA-1 in HMAC for record protection. > >> >> > > >> >> > > >> >> > RFC6194 may be mentioned as a reference for > >> >> > not deprecating HMAC-SHA-1 as well as an > >> >> > additional reference to [NISTSP800-131A-R2]. > >> >> > >> >> Are asking for something like this: > >> >> > >> >> OLD: > >> >> > >> >> In 2011, [RFC6151] detailed the security considerations, > >> >> including collision attacks for MD5. > >> >> > >> >> NEW: > >> >> > >> >> In 2011, [RFC6151] [RFC6194] detailed the security considerations, > >> >> including collision attacks for MD5 and SHA-1, respectively. > >> >> > >> >> > Reading the text the situation of HMAC with > >> >> > MD5 is unclear. Since we specify that SHA-1 > >> >> > is not deprecated for HMAC we may specify > >> >> > the status for HMAC with MD5. Given RFC6151 I > >> >> > hope the reason is that MD5 and HMAC-MD5 has > >> >> > already been deprecated but I have not found > >> >> > this. Maybe that would worth mentioning it > >> >> > is deprecated already. > >> >> > > >> >> > > >> >> > >> >> Are you asking for something like this: > >> >> > >> >> OLD: > >> >> > >> >> However, this document does not deprecate SHA-1 in HMAC > >> >> for record protection. > >> >> > >> >> However, this document does not deprecate MD-5 or SHA-1 HMAC > >> >> for record protection. > >> > > >> > > >> > maybe we could add these are still considered as secured at the time > of writing. It is also tempting to add that given we deprecate sha1 and > md5 in the signature, it is tempting to suggest to use unless necessary > hmac-sha256. I have commented the PR12 > >> > > > > > I think we address or will address this one in this to-be updated PR: > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12/files > > In fact, I plan to submit updates to the PR for all of the changes so we > can look at them in one place. > > > > >> >> < > >> >> > [...] > >> >> > > >> >> > 2. Signature
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Daniel, Thanks for your (and the WG’s) patience on this. Responses in line. spt > On Apr 9, 2021, at 14:54, Sean Turner wrote: >> On Jan 22, 2021, at 08:23, Daniel Migault wrote: >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron >> wrote: >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault wrote: >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: >> >> >> >> >> >> Please note the comment about Section 3 suggests changing server behavior >> >> from SHOULD NOT to a MUST NOT. >> >> >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker >> >> > wrote: >> >> > >> >> > Reviewer: Daniel Migault >> >> > Review result: Ready with Nits >> >> > >> >> > Hi, >> >> > >> >> > >> >> > I reviewed this document as part of the IoT Directorate's ongoing >> >> > effort to >> >> > review all IETF documents being processed by the IESG. These comments >> >> > were >> >> > written primarily for the benefit of the Security Area Directors. >> >> > Document >> >> > authors, document editors, and WG chairs should treat these comments >> >> > just like >> >> > any other IETF Last Call comments. >> >> > >> >> > Review Results: Ready with Nits >> >> > >> >> > Please find my comments below. >> >> > >> >> > Yours, >> >> > Daniel >> >> > >> >> > >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 >> >> > draft-ietf-tls-md5-sha1-deprecate-04 >> >> > [...] >> >> > >> >> > 1. Introduction >> >> > >> >> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >> >> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be >> >> > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] >> >> > detailed the security considerations, including collision attacks for >> >> > MD5. NIST formally deprecated use of SHA-1 in 2011 >> >> > [NISTSP800-131A-R2] and disallowed its use for digital signatures at >> >> > the end of 2013, based on both the Wang, et. al, attack and the >> >> > potential for brute-force attack. In 2016, researchers from INRIA >> >> > identified a new class of transcript collision attacks on TLS (and >> >> > other protocols) that rely on efficient collision-finding algorithms >> >> > on the underlying hash constructions [Transcript-Collision]. >> >> > Further, in 2017, researchers from Google and CWI Amsterdam >> >> > [SHA-1-Collision] proved SHA-1 collision attacks were practical. >> >> > This document updates [RFC5246] and [RFC7525] in such a way that MD5 >> >> > and SHA-1 MUST NOT be used for digital signatures. However, this >> >> > document does not deprecate SHA-1 in HMAC for record protection. >> >> > >> >> > >> >> > RFC6194 may be mentioned as a reference for >> >> > not deprecating HMAC-SHA-1 as well as an >> >> > additional reference to [NISTSP800-131A-R2]. >> >> >> >> Are asking for something like this: >> >> >> >> OLD: >> >> >> >> In 2011, [RFC6151] detailed the security considerations, >> >> including collision attacks for MD5. >> >> >> >> NEW: >> >> >> >> In 2011, [RFC6151] [RFC6194] detailed the security considerations, >> >> including collision attacks for MD5 and SHA-1, respectively. >> >> >> >> > Reading the text the situation of HMAC with >> >> > MD5 is unclear. Since we specify that SHA-1 >> >> > is not deprecated for HMAC we may specify >> >> > the status for HMAC with MD5. Given RFC6151 I >> >> > hope the reason is that MD5 and HMAC-MD5 has >> >> > already been deprecated but I have not found >> >> > this. Maybe that would worth mentioning it >> >> > is deprecated already. >> >> > >> >> > >> >> >> >> Are you asking for something like this: >> >> >> >> OLD: >> >> >> >> However, this document does not deprecate SHA-1 in HMAC >> >> for record protection. >> >> >> >> However, this document does not deprecate MD-5 or SHA-1 HMAC >> >> for record protection. >> > >> > >> > maybe we could add these are still considered as secured at the time of >> > writing. It is also tempting to add that given we deprecate sha1 and md5 >> > in the signature, it is tempting to suggest to use unless necessary >> > hmac-sha256. I have commented the PR12 >> > I think we address or will address this one in this to-be updated PR: https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12/files In fact, I plan to submit updates to the PR for all of the changes so we can look at them in one place. >> >> < >> >> > [...] >> >> > >> >> > 2. Signature Algorithms >> >> > >> >> > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms >> >> > extension. If a client does not send a signature_algorithms >> >> > extension, then the server MUST abort the handshake and send a >> >> > handshake_failure alert, except when digital signatures are not used >> >> > (for example, when using PSK ciphers). >> >> > >> >> > >> >> > It seems to me that the server behavior might >> >> > be defined as well. In our case this could be >> >> > something around the lines
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
> On Jan 21, 2021, at 16:50, Daniel Migault wrote: > > Hi, > > First I deeply apologize for taking so long to respond, I just realized now > these responses. No worries it does happen that I miss email from time to time too ;) > I do not believe a review of IoT protocol is needed, I am more thinking that > TLS document should serve as a base guidance for TLS. Specific needs for IoT > are addressed based on the generic guidances. In some cases specific > extensions, cipher suites - not referenced by IANA as recommended - will be > needed to address specific corner cases. I agree with you since the TLS RFC provides the general use case. Other RFCs can specify other use cases. The way we handled this for CCM_8 suites was to include the following note: Note CCM_8 cipher suites are not marked as "Recommended". These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. spt > Yours, > Daniel > > On Tue, Oct 27, 2020 at 11:32 PM Sean Turner wrote: > > > > On Oct 27, 2020, at 10:32, Daniel Migault wrote: > > > > To address the comment below, keeping weak security is likely to weaken > > current and future IoT communications, so I do not think there is room for > > compromise with performance. Of course this is in a context of TLS. I > > expect protocol to leverage from TLS security, so the impact should be > > rather negligible. > > > > """ > > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a > > review of impacted IoT protocols if those algorithms are deprecated. > > """ > > In terms of process, are you suggesting "a review of impacted IoT protocols > if those algorithms are deprecated” MUST be completed prior to advancing this > document to the IESG? > > spt > > > Yours, > > Daniel > > > > > > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker > > wrote: > > Reviewer: Daniel Migault > > Review result: Ready with Nits > > > > Hi, > > > > > > I reviewed this document as part of the IoT Directorate's ongoing effort to > > review all IETF documents being processed by the IESG. These comments were > > written primarily for the benefit of the Security Area Directors. Document > > authors, document editors, and WG chairs should treat these comments just > > like > > any other IETF Last Call comments. > > > > Review Results: Ready with Nits > > > > Please find my comments below. > > > > Yours, > > Daniel > > > > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > > draft-ietf-tls-md5-sha1-deprecate-04 > > [...] > > > > 1. Introduction > > > >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > >specified in [RFC5246]. MD5 and SHA-1 have been proven to be > >insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] > >detailed the security considerations, including collision attacks for > >MD5. NIST formally deprecated use of SHA-1 in 2011 > >[NISTSP800-131A-R2] and disallowed its use for digital signatures at > >the end of 2013, based on both the Wang, et. al, attack and the > >potential for brute-force attack. In 2016, researchers from INRIA > >identified a new class of transcript collision attacks on TLS (and > >other protocols) that rely on efficient collision-finding algorithms > >on the underlying hash constructions [Transcript-Collision]. > >Further, in 2017, researchers from Google and CWI Amsterdam > >[SHA-1-Collision] proved SHA-1 collision attacks were practical. > >This document updates [RFC5246] and [RFC7525] in such a way that MD5 > >and SHA-1 MUST NOT be used for digital signatures. However, this > >document does not deprecate SHA-1 in HMAC for record protection. > > > > > > RFC6194 may be mentioned as a reference for > > not deprecating HMAC-SHA-1 as well as an > > additional reference to [NISTSP800-131A-R2]. > > > > Reading the text the situation of HMAC with > > MD5 is unclear. Since we specify that SHA-1 > > is not deprecated for HMAC we may specify > > the status for HMAC with MD5. Given RFC6151 I > > hope the reason is that MD5 and HMAC-MD5 has > > already been deprecated but I have not found > > this. Maybe that would worth mentioning it > > is deprecated already. > > > > > > > > [...] > > > > 2. Signature Algorithms > > > >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > >extension. If a client does not send a signature_algorithms > >extension, then the server MUST abort the handshake and send a > >handshake_failure alert, except when digital signatures are not used > >(for example, when using PSK ciphers). > > > > > > It seems to me that the server behavior might > > be defined as well. In our case this could be > > something around the lines the server MUST > > ignore MD5 and SHA1 values in the signature > > algorithm
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron wrote: > On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault > wrote: > > > > Hi, > > > > I apology for responding so late - I missed the thread. I want this > document to be moved forward but so far I do not have the impression my > concerns have been addressed. I suppose that results from my lake of > responsiveness and I apology. Please find my response inline and let me > know what can be achieved reasonably. > > > > Yours, > > Daniel > > > > > > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: > >> > >> > >> Please note the comment about Section 3 suggests changing server > behavior from SHOULD NOT to a MUST NOT. > >> > >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker < > nore...@ietf.org> wrote: > >> > > >> > Reviewer: Daniel Migault > >> > Review result: Ready with Nits > >> > > >> > Hi, > >> > > >> > > >> > I reviewed this document as part of the IoT Directorate's ongoing > effort to > >> > review all IETF documents being processed by the IESG. These > comments were > >> > written primarily for the benefit of the Security Area Directors. > Document > >> > authors, document editors, and WG chairs should treat these comments > just like > >> > any other IETF Last Call comments. > >> > > >> > Review Results: Ready with Nits > >> > > >> > Please find my comments below. > >> > > >> > Yours, > >> > Daniel > >> > > >> > > >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > >> > draft-ietf-tls-md5-sha1-deprecate-04 > >> > [...] > >> > > >> > 1. Introduction > >> > > >> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > >> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be > >> > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] > >> > detailed the security considerations, including collision attacks > for > >> > MD5. NIST formally deprecated use of SHA-1 in 2011 > >> > [NISTSP800-131A-R2] and disallowed its use for digital signatures at > >> > the end of 2013, based on both the Wang, et. al, attack and the > >> > potential for brute-force attack. In 2016, researchers from INRIA > >> > identified a new class of transcript collision attacks on TLS (and > >> > other protocols) that rely on efficient collision-finding algorithms > >> > on the underlying hash constructions [Transcript-Collision]. > >> > Further, in 2017, researchers from Google and CWI Amsterdam > >> > [SHA-1-Collision] proved SHA-1 collision attacks were practical. > >> > This document updates [RFC5246] and [RFC7525] in such a way that MD5 > >> > and SHA-1 MUST NOT be used for digital signatures. However, this > >> > document does not deprecate SHA-1 in HMAC for record protection. > >> > > >> > > >> > RFC6194 may be mentioned as a reference for > >> > not deprecating HMAC-SHA-1 as well as an > >> > additional reference to [NISTSP800-131A-R2]. > >> > >> Are asking for something like this: > >> > >> OLD: > >> > >> In 2011, [RFC6151] detailed the security considerations, > >> including collision attacks for MD5. > >> > >> NEW: > >> > >> In 2011, [RFC6151] [RFC6194] detailed the security considerations, > >> including collision attacks for MD5 and SHA-1, respectively. > >> > >> > Reading the text the situation of HMAC with > >> > MD5 is unclear. Since we specify that SHA-1 > >> > is not deprecated for HMAC we may specify > >> > the status for HMAC with MD5. Given RFC6151 I > >> > hope the reason is that MD5 and HMAC-MD5 has > >> > already been deprecated but I have not found > >> > this. Maybe that would worth mentioning it > >> > is deprecated already. > >> > > >> > > >> > >> Are you asking for something like this: > >> > >> OLD: > >> > >> However, this document does not deprecate SHA-1 in HMAC > >> for record protection. > >> > >> However, this document does not deprecate MD-5 or SHA-1 HMAC > >> for record protection. > > > > > > maybe we could add these are still considered as secured at the time of > writing. It is also tempting to add that given we deprecate sha1 and md5 > in the signature, it is tempting to suggest to use unless necessary > hmac-sha256. I have commented the PR12 > > > >> > >> < > >> > [...] > >> > > >> > 2. Signature Algorithms > >> > > >> > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > >> > extension. If a client does not send a signature_algorithms > >> > extension, then the server MUST abort the handshake and send a > >> > handshake_failure alert, except when digital signatures are not used > >> > (for example, when using PSK ciphers). > >> > > >> > > >> > It seems to me that the server behavior might > >> > be defined as well. In our case this could be > >> > something around the lines the server MUST > >> > ignore MD5 and SHA1 values in the signature > >> > algorithm extension. > >> > > >> > > >> > >> I guess that would be the way to absolutely stamp them out, but don’t > we
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault wrote: > > Hi, > > I apology for responding so late - I missed the thread. I want this document > to be moved forward but so far I do not have the impression my concerns have > been addressed. I suppose that results from my lake of responsiveness and I > apology. Please find my response inline and let me know what can be achieved > reasonably. > > Yours, > Daniel > > > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: >> >> >> Please note the comment about Section 3 suggests changing server behavior >> from SHOULD NOT to a MUST NOT. >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker >> > wrote: >> > >> > Reviewer: Daniel Migault >> > Review result: Ready with Nits >> > >> > Hi, >> > >> > >> > I reviewed this document as part of the IoT Directorate's ongoing effort to >> > review all IETF documents being processed by the IESG. These comments were >> > written primarily for the benefit of the Security Area Directors. Document >> > authors, document editors, and WG chairs should treat these comments just >> > like >> > any other IETF Last Call comments. >> > >> > Review Results: Ready with Nits >> > >> > Please find my comments below. >> > >> > Yours, >> > Daniel >> > >> > >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 >> > draft-ietf-tls-md5-sha1-deprecate-04 >> > [...] >> > >> > 1. Introduction >> > >> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be >> > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] >> > detailed the security considerations, including collision attacks for >> > MD5. NIST formally deprecated use of SHA-1 in 2011 >> > [NISTSP800-131A-R2] and disallowed its use for digital signatures at >> > the end of 2013, based on both the Wang, et. al, attack and the >> > potential for brute-force attack. In 2016, researchers from INRIA >> > identified a new class of transcript collision attacks on TLS (and >> > other protocols) that rely on efficient collision-finding algorithms >> > on the underlying hash constructions [Transcript-Collision]. >> > Further, in 2017, researchers from Google and CWI Amsterdam >> > [SHA-1-Collision] proved SHA-1 collision attacks were practical. >> > This document updates [RFC5246] and [RFC7525] in such a way that MD5 >> > and SHA-1 MUST NOT be used for digital signatures. However, this >> > document does not deprecate SHA-1 in HMAC for record protection. >> > >> > >> > RFC6194 may be mentioned as a reference for >> > not deprecating HMAC-SHA-1 as well as an >> > additional reference to [NISTSP800-131A-R2]. >> >> Are asking for something like this: >> >> OLD: >> >> In 2011, [RFC6151] detailed the security considerations, >> including collision attacks for MD5. >> >> NEW: >> >> In 2011, [RFC6151] [RFC6194] detailed the security considerations, >> including collision attacks for MD5 and SHA-1, respectively. >> >> > Reading the text the situation of HMAC with >> > MD5 is unclear. Since we specify that SHA-1 >> > is not deprecated for HMAC we may specify >> > the status for HMAC with MD5. Given RFC6151 I >> > hope the reason is that MD5 and HMAC-MD5 has >> > already been deprecated but I have not found >> > this. Maybe that would worth mentioning it >> > is deprecated already. >> > >> > >> >> Are you asking for something like this: >> >> OLD: >> >> However, this document does not deprecate SHA-1 in HMAC >> for record protection. >> >> However, this document does not deprecate MD-5 or SHA-1 HMAC >> for record protection. > > > maybe we could add these are still considered as secured at the time of > writing. It is also tempting to add that given we deprecate sha1 and md5 in > the signature, it is tempting to suggest to use unless necessary hmac-sha256. > I have commented the PR12 > >> >> < >> > [...] >> > >> > 2. Signature Algorithms >> > >> > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms >> > extension. If a client does not send a signature_algorithms >> > extension, then the server MUST abort the handshake and send a >> > handshake_failure alert, except when digital signatures are not used >> > (for example, when using PSK ciphers). >> > >> > >> > It seems to me that the server behavior might >> > be defined as well. In our case this could be >> > something around the lines the server MUST >> > ignore MD5 and SHA1 values in the signature >> > algorithm extension. >> > >> > >> >> I guess that would be the way to absolutely stamp them out, but don’t we get >> the same result because the client is not sending the values in the >> signaure_algorithms extension? >> > > The reason I would maybe have preferred to have indications for the client > and the server is that it is always easier for a server to say that it is > following the specs than to indicate that the
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Hi, I apology for responding so late - I missed the thread. I want this document to be moved forward but so far I do not have the impression my concerns have been addressed. I suppose that results from my lake of responsiveness and I apology. Please find my response inline and let me know what can be achieved reasonably. Yours, Daniel On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: > > Please note the comment about Section 3 suggests changing server behavior > from SHOULD NOT to a MUST NOT. > > > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker < > nore...@ietf.org> wrote: > > > > Reviewer: Daniel Migault > > Review result: Ready with Nits > > > > Hi, > > > > > > I reviewed this document as part of the IoT Directorate's ongoing effort > to > > review all IETF documents being processed by the IESG. These comments > were > > written primarily for the benefit of the Security Area Directors. > Document > > authors, document editors, and WG chairs should treat these comments > just like > > any other IETF Last Call comments. > > > > Review Results: Ready with Nits > > > > Please find my comments below. > > > > Yours, > > Daniel > > > > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > > draft-ietf-tls-md5-sha1-deprecate-04 > > [...] > > > > 1. Introduction > > > > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > > specified in [RFC5246]. MD5 and SHA-1 have been proven to be > > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] > > detailed the security considerations, including collision attacks for > > MD5. NIST formally deprecated use of SHA-1 in 2011 > > [NISTSP800-131A-R2] and disallowed its use for digital signatures at > > the end of 2013, based on both the Wang, et. al, attack and the > > potential for brute-force attack. In 2016, researchers from INRIA > > identified a new class of transcript collision attacks on TLS (and > > other protocols) that rely on efficient collision-finding algorithms > > on the underlying hash constructions [Transcript-Collision]. > > Further, in 2017, researchers from Google and CWI Amsterdam > > [SHA-1-Collision] proved SHA-1 collision attacks were practical. > > This document updates [RFC5246] and [RFC7525] in such a way that MD5 > > and SHA-1 MUST NOT be used for digital signatures. However, this > > document does not deprecate SHA-1 in HMAC for record protection. > > > > > > RFC6194 may be mentioned as a reference for > > not deprecating HMAC-SHA-1 as well as an > > additional reference to [NISTSP800-131A-R2]. > > Are asking for something like this: > > OLD: > > In 2011, [RFC6151] detailed the security considerations, > including collision attacks for MD5. > > NEW: > > In 2011, [RFC6151] [RFC6194] detailed the security considerations, > including collision attacks for MD5 and SHA-1, respectively. > > > Reading the text the situation of HMAC with > > MD5 is unclear. Since we specify that SHA-1 > > is not deprecated for HMAC we may specify > > the status for HMAC with MD5. Given RFC6151 I > > hope the reason is that MD5 and HMAC-MD5 has > > already been deprecated but I have not found > > this. Maybe that would worth mentioning it > > is deprecated already. > > > > > > Are you asking for something like this: > > OLD: > > However, this document does not deprecate SHA-1 in HMAC > for record protection. > > However, this document does not deprecate MD-5 or SHA-1 HMAC > for record protection. maybe we could add these are still considered as secured at the time of writing. It is also tempting to add that given we deprecate sha1 and md5 in the signature, it is tempting to suggest to use unless necessary hmac-sha256. I have commented the PR12 > < > > [...] > > > > 2. Signature Algorithms > > > > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > > extension. If a client does not send a signature_algorithms > > extension, then the server MUST abort the handshake and send a > > handshake_failure alert, except when digital signatures are not used > > (for example, when using PSK ciphers). > > > > > > It seems to me that the server behavior might > > be defined as well. In our case this could be > > something around the lines the server MUST > > ignore MD5 and SHA1 values in the signature > > algorithm extension. > > > > > > I guess that would be the way to absolutely stamp them out, but don’t we > get the same result because the client is not sending the values in the > signaure_algorithms extension? > > The reason I would maybe have preferred to have indications for the client and the server is that it is always easier for a server to say that it is following the specs than to indicate that the client is not. This is correct the result is similar, but client usually complement servers and we usually specify both. I believe that would be better to be updated. > > 3. Certificate Request > > > >
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Hi, First I deeply apologize for taking so long to respond, I just realized now these responses. I do not believe a review of IoT protocol is needed, I am more thinking that TLS document should serve as a base guidance for TLS. Specific needs for IoT are addressed based on the generic guidances. In some cases specific extensions, cipher suites - not referenced by IANA as recommended - will be needed to address specific corner cases. Yours, Daniel On Tue, Oct 27, 2020 at 11:32 PM Sean Turner wrote: > > > > On Oct 27, 2020, at 10:32, Daniel Migault wrote: > > > > To address the comment below, keeping weak security is likely to weaken > current and future IoT communications, so I do not think there is room for > compromise with performance. Of course this is in a context of TLS. I > expect protocol to leverage from TLS security, so the impact should be > rather negligible. > > > > """ > > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a > review of impacted IoT protocols if those algorithms are deprecated. > > """ > > In terms of process, are you suggesting "a review of impacted IoT > protocols if those algorithms are deprecated” MUST be completed prior to > advancing this document to the IESG? > > spt > > > Yours, > > Daniel > > > > > > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker < > nore...@ietf.org> wrote: > > Reviewer: Daniel Migault > > Review result: Ready with Nits > > > > Hi, > > > > > > I reviewed this document as part of the IoT Directorate's ongoing effort > to > > review all IETF documents being processed by the IESG. These comments > were > > written primarily for the benefit of the Security Area Directors. > Document > > authors, document editors, and WG chairs should treat these comments > just like > > any other IETF Last Call comments. > > > > Review Results: Ready with Nits > > > > Please find my comments below. > > > > Yours, > > Daniel > > > > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > > draft-ietf-tls-md5-sha1-deprecate-04 > > [...] > > > > 1. Introduction > > > >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > >specified in [RFC5246]. MD5 and SHA-1 have been proven to be > >insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] > >detailed the security considerations, including collision attacks for > >MD5. NIST formally deprecated use of SHA-1 in 2011 > >[NISTSP800-131A-R2] and disallowed its use for digital signatures at > >the end of 2013, based on both the Wang, et. al, attack and the > >potential for brute-force attack. In 2016, researchers from INRIA > >identified a new class of transcript collision attacks on TLS (and > >other protocols) that rely on efficient collision-finding algorithms > >on the underlying hash constructions [Transcript-Collision]. > >Further, in 2017, researchers from Google and CWI Amsterdam > >[SHA-1-Collision] proved SHA-1 collision attacks were practical. > >This document updates [RFC5246] and [RFC7525] in such a way that MD5 > >and SHA-1 MUST NOT be used for digital signatures. However, this > >document does not deprecate SHA-1 in HMAC for record protection. > > > > > > RFC6194 may be mentioned as a reference for > > not deprecating HMAC-SHA-1 as well as an > > additional reference to [NISTSP800-131A-R2]. > > > > Reading the text the situation of HMAC with > > MD5 is unclear. Since we specify that SHA-1 > > is not deprecated for HMAC we may specify > > the status for HMAC with MD5. Given RFC6151 I > > hope the reason is that MD5 and HMAC-MD5 has > > already been deprecated but I have not found > > this. Maybe that would worth mentioning it > > is deprecated already. > > > > > > > > [...] > > > > 2. Signature Algorithms > > > >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > >extension. If a client does not send a signature_algorithms > >extension, then the server MUST abort the handshake and send a > >handshake_failure alert, except when digital signatures are not used > >(for example, when using PSK ciphers). > > > > > > It seems to me that the server behavior might > > be defined as well. In our case this could be > > something around the lines the server MUST > > ignore MD5 and SHA1 values in the signature > > algorithm extension. > > > > > > > > 3. Certificate Request > > > >Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > >messages. > > > > > > It seems to me that the same level of > > authentication should be provided for both > > peers and that server MUST NOT include MD5 > > or SHA-1. > > > > A SHOULD NOT status might be welcome for a > > smooth transition. At that time, collision > > for MD5 and SHA1 are known for years. It is likely > > that software that still need MD5 or SHA1 are > > likely to never upgrade, so I doubt a smooth > > path worth being taken. > > > > > > 4. Server
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Daniel, Alessandro created a PR to resolve your comments as suggested by me: https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12 I was unable to propose text for all of your comments. Please review this email as well as the PR as well so we can move this I-D along. Cheers, spt > On Oct 27, 2020, at 23:32, Sean Turner wrote: > > > Please note the comment about Section 3 suggests changing server behavior > from SHOULD NOT to a MUST NOT. > >> On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker >> wrote: >> >> Reviewer: Daniel Migault >> Review result: Ready with Nits >> >> Hi, >> >> >> I reviewed this document as part of the IoT Directorate's ongoing effort to >> review all IETF documents being processed by the IESG. These comments were >> written primarily for the benefit of the Security Area Directors. Document >> authors, document editors, and WG chairs should treat these comments just >> like >> any other IETF Last Call comments. >> >> Review Results: Ready with Nits >> >> Please find my comments below. >> >> Yours, >> Daniel >> >> >>Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 >> draft-ietf-tls-md5-sha1-deprecate-04 >> [...] >> >> 1. Introduction >> >> The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >> specified in [RFC5246]. MD5 and SHA-1 have been proven to be >> insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] >> detailed the security considerations, including collision attacks for >> MD5. NIST formally deprecated use of SHA-1 in 2011 >> [NISTSP800-131A-R2] and disallowed its use for digital signatures at >> the end of 2013, based on both the Wang, et. al, attack and the >> potential for brute-force attack. In 2016, researchers from INRIA >> identified a new class of transcript collision attacks on TLS (and >> other protocols) that rely on efficient collision-finding algorithms >> on the underlying hash constructions [Transcript-Collision]. >> Further, in 2017, researchers from Google and CWI Amsterdam >> [SHA-1-Collision] proved SHA-1 collision attacks were practical. >> This document updates [RFC5246] and [RFC7525] in such a way that MD5 >> and SHA-1 MUST NOT be used for digital signatures. However, this >> document does not deprecate SHA-1 in HMAC for record protection. >> >> >> RFC6194 may be mentioned as a reference for >> not deprecating HMAC-SHA-1 as well as an >> additional reference to [NISTSP800-131A-R2]. > > Are asking for something like this: > > OLD: > > In 2011, [RFC6151] detailed the security considerations, > including collision attacks for MD5. > > NEW: > > In 2011, [RFC6151] [RFC6194] detailed the security considerations, > including collision attacks for MD5 and SHA-1, respectively. > >> Reading the text the situation of HMAC with >> MD5 is unclear. Since we specify that SHA-1 >> is not deprecated for HMAC we may specify >> the status for HMAC with MD5. Given RFC6151 I >> hope the reason is that MD5 and HMAC-MD5 has >> already been deprecated but I have not found >> this. Maybe that would worth mentioning it >> is deprecated already. >> >> > > Are you asking for something like this: > > OLD: > > However, this document does not deprecate SHA-1 in HMAC > for record protection. > > However, this document does not deprecate MD-5 or SHA-1 HMAC > for record protection. > >> [...] >> >> 2. Signature Algorithms >> >> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms >> extension. If a client does not send a signature_algorithms >> extension, then the server MUST abort the handshake and send a >> handshake_failure alert, except when digital signatures are not used >> (for example, when using PSK ciphers). >> >> >> It seems to me that the server behavior might >> be defined as well. In our case this could be >> something around the lines the server MUST >> ignore MD5 and SHA1 values in the signature >> algorithm extension. >> >> > > I guess that would be the way to absolutely stamp them out, but don’t we get > the same result because the client is not sending the values in the > signaure_algorithms extension? > >> 3. Certificate Request >> >> Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest >> messages. >> >> >> It seems to me that the same level of >> authentication should be provided for both >> peers and that server MUST NOT include MD5 >> or SHA-1. >> >> A SHOULD NOT status might be welcome for a >> smooth transition. At that time, collision >> for MD5 and SHA1 are known for years. It is likely >> that software that still need MD5 or SHA1 are >> likely to never upgrade, so I doubt a smooth >> path worth being taken. >> > > This has been a SHOULD NOT since it was a first published as an individual > draft and through the WGLC. I would not feel comfortable changing it now > without further discussion. > > I tend to think it is okay to leave as SHOULD NOT because the
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
> On Oct 27, 2020, at 10:32, Daniel Migault wrote: > > To address the comment below, keeping weak security is likely to weaken > current and future IoT communications, so I do not think there is room for > compromise with performance. Of course this is in a context of TLS. I expect > protocol to leverage from TLS security, so the impact should be rather > negligible. > > """ > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a > review of impacted IoT protocols if those algorithms are deprecated. > """ In terms of process, are you suggesting "a review of impacted IoT protocols if those algorithms are deprecated” MUST be completed prior to advancing this document to the IESG? spt > Yours, > Daniel > > > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker > wrote: > Reviewer: Daniel Migault > Review result: Ready with Nits > > Hi, > > > I reviewed this document as part of the IoT Directorate's ongoing effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just like > any other IETF Last Call comments. > > Review Results: Ready with Nits > > Please find my comments below. > > Yours, > Daniel > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > draft-ietf-tls-md5-sha1-deprecate-04 > [...] > > 1. Introduction > >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >specified in [RFC5246]. MD5 and SHA-1 have been proven to be >insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] >detailed the security considerations, including collision attacks for >MD5. NIST formally deprecated use of SHA-1 in 2011 >[NISTSP800-131A-R2] and disallowed its use for digital signatures at >the end of 2013, based on both the Wang, et. al, attack and the >potential for brute-force attack. In 2016, researchers from INRIA >identified a new class of transcript collision attacks on TLS (and >other protocols) that rely on efficient collision-finding algorithms >on the underlying hash constructions [Transcript-Collision]. >Further, in 2017, researchers from Google and CWI Amsterdam >[SHA-1-Collision] proved SHA-1 collision attacks were practical. >This document updates [RFC5246] and [RFC7525] in such a way that MD5 >and SHA-1 MUST NOT be used for digital signatures. However, this >document does not deprecate SHA-1 in HMAC for record protection. > > > RFC6194 may be mentioned as a reference for > not deprecating HMAC-SHA-1 as well as an > additional reference to [NISTSP800-131A-R2]. > > Reading the text the situation of HMAC with > MD5 is unclear. Since we specify that SHA-1 > is not deprecated for HMAC we may specify > the status for HMAC with MD5. Given RFC6151 I > hope the reason is that MD5 and HMAC-MD5 has > already been deprecated but I have not found > this. Maybe that would worth mentioning it > is deprecated already. > > > > [...] > > 2. Signature Algorithms > >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms >extension. If a client does not send a signature_algorithms >extension, then the server MUST abort the handshake and send a >handshake_failure alert, except when digital signatures are not used >(for example, when using PSK ciphers). > > > It seems to me that the server behavior might > be defined as well. In our case this could be > something around the lines the server MUST > ignore MD5 and SHA1 values in the signature > algorithm extension. > > > > 3. Certificate Request > >Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest >messages. > > > It seems to me that the same level of > authentication should be provided for both > peers and that server MUST NOT include MD5 > or SHA-1. > > A SHOULD NOT status might be welcome for a > smooth transition. At that time, collision > for MD5 and SHA1 are known for years. It is likely > that software that still need MD5 or SHA1 are > likely to never upgrade, so I doubt a smooth > path worth being taken. > > > 4. Server Key Exchange > >Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. >If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange >message it MUST abort the connection with the illegal_parameter >alert. > > > As per section 2, the client has clearly > indicated it does not support signature with > MD5/SHA1, so Server Key Exchange should not > end up with signature with SHA1/MD5. > > """ > If the client has offered the "signature_algorithms" extension, the >signature algorithm and hash algorithm MUST be a pair listed in that >extension. > """ > > It also seems to me that the constraint of > including a MD5 and SHA-1 signature is > related to the Certificate. I
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Please note the comment about Section 3 suggests changing server behavior from SHOULD NOT to a MUST NOT. > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker > wrote: > > Reviewer: Daniel Migault > Review result: Ready with Nits > > Hi, > > > I reviewed this document as part of the IoT Directorate's ongoing effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just like > any other IETF Last Call comments. > > Review Results: Ready with Nits > > Please find my comments below. > > Yours, > Daniel > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > draft-ietf-tls-md5-sha1-deprecate-04 > [...] > > 1. Introduction > > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > specified in [RFC5246]. MD5 and SHA-1 have been proven to be > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] > detailed the security considerations, including collision attacks for > MD5. NIST formally deprecated use of SHA-1 in 2011 > [NISTSP800-131A-R2] and disallowed its use for digital signatures at > the end of 2013, based on both the Wang, et. al, attack and the > potential for brute-force attack. In 2016, researchers from INRIA > identified a new class of transcript collision attacks on TLS (and > other protocols) that rely on efficient collision-finding algorithms > on the underlying hash constructions [Transcript-Collision]. > Further, in 2017, researchers from Google and CWI Amsterdam > [SHA-1-Collision] proved SHA-1 collision attacks were practical. > This document updates [RFC5246] and [RFC7525] in such a way that MD5 > and SHA-1 MUST NOT be used for digital signatures. However, this > document does not deprecate SHA-1 in HMAC for record protection. > > > RFC6194 may be mentioned as a reference for > not deprecating HMAC-SHA-1 as well as an > additional reference to [NISTSP800-131A-R2]. Are asking for something like this: OLD: In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. NEW: In 2011, [RFC6151] [RFC6194] detailed the security considerations, including collision attacks for MD5 and SHA-1, respectively. > Reading the text the situation of HMAC with > MD5 is unclear. Since we specify that SHA-1 > is not deprecated for HMAC we may specify > the status for HMAC with MD5. Given RFC6151 I > hope the reason is that MD5 and HMAC-MD5 has > already been deprecated but I have not found > this. Maybe that would worth mentioning it > is deprecated already. > > Are you asking for something like this: OLD: However, this document does not deprecate SHA-1 in HMAC for record protection. However, this document does not deprecate MD-5 or SHA-1 HMAC for record protection. > [...] > > 2. Signature Algorithms > > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > extension. If a client does not send a signature_algorithms > extension, then the server MUST abort the handshake and send a > handshake_failure alert, except when digital signatures are not used > (for example, when using PSK ciphers). > > > It seems to me that the server behavior might > be defined as well. In our case this could be > something around the lines the server MUST > ignore MD5 and SHA1 values in the signature > algorithm extension. > > I guess that would be the way to absolutely stamp them out, but don’t we get the same result because the client is not sending the values in the signaure_algorithms extension? > 3. Certificate Request > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > messages. > > > It seems to me that the same level of > authentication should be provided for both > peers and that server MUST NOT include MD5 > or SHA-1. > > A SHOULD NOT status might be welcome for a > smooth transition. At that time, collision > for MD5 and SHA1 are known for years. It is likely > that software that still need MD5 or SHA1 are > likely to never upgrade, so I doubt a smooth > path worth being taken. > This has been a SHOULD NOT since it was a first published as an individual draft and through the WGLC. I would not feel comfortable changing it now without further discussion. I tend to think it is okay to leave as SHOULD NOT because the server MUST use values from the now ever present signature_algorithms extension and MD5 and SHA1 are not going to be there. If the server is going to go nuts and include MD5 and SHA-1 in the CertifiateRequest even though it’s not been asked, well, you got bigger problems. > 4. Server Key Exchange > > Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. > If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange > message it MUST abort the connection
Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
To address the comment below, keeping weak security is likely to weaken current and future IoT communications, so I do not think there is room for compromise with performance. Of course this is in a context of TLS. I expect protocol to leverage from TLS security, so the impact should be rather negligible. """ As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a review of impacted IoT protocols if those algorithms are deprecated. """ Yours, Daniel On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker < nore...@ietf.org> wrote: > Reviewer: Daniel Migault > Review result: Ready with Nits > > Hi, > > > I reviewed this document as part of the IoT Directorate's ongoing effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. > > Review Results: Ready with Nits > > Please find my comments below. > > Yours, > Daniel > > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > draft-ietf-tls-md5-sha1-deprecate-04 > [...] > > 1. Introduction > >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is >specified in [RFC5246]. MD5 and SHA-1 have been proven to be >insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] >detailed the security considerations, including collision attacks for >MD5. NIST formally deprecated use of SHA-1 in 2011 >[NISTSP800-131A-R2] and disallowed its use for digital signatures at >the end of 2013, based on both the Wang, et. al, attack and the >potential for brute-force attack. In 2016, researchers from INRIA >identified a new class of transcript collision attacks on TLS (and >other protocols) that rely on efficient collision-finding algorithms >on the underlying hash constructions [Transcript-Collision]. >Further, in 2017, researchers from Google and CWI Amsterdam >[SHA-1-Collision] proved SHA-1 collision attacks were practical. >This document updates [RFC5246] and [RFC7525] in such a way that MD5 >and SHA-1 MUST NOT be used for digital signatures. However, this >document does not deprecate SHA-1 in HMAC for record protection. > > > RFC6194 may be mentioned as a reference for > not deprecating HMAC-SHA-1 as well as an > additional reference to [NISTSP800-131A-R2]. > > Reading the text the situation of HMAC with > MD5 is unclear. Since we specify that SHA-1 > is not deprecated for HMAC we may specify > the status for HMAC with MD5. Given RFC6151 I > hope the reason is that MD5 and HMAC-MD5 has > already been deprecated but I have not found > this. Maybe that would worth mentioning it > is deprecated already. > > > > [...] > > 2. Signature Algorithms > >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms >extension. If a client does not send a signature_algorithms >extension, then the server MUST abort the handshake and send a >handshake_failure alert, except when digital signatures are not used >(for example, when using PSK ciphers). > > > It seems to me that the server behavior might > be defined as well. In our case this could be > something around the lines the server MUST > ignore MD5 and SHA1 values in the signature > algorithm extension. > > > > 3. Certificate Request > >Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest >messages. > > > It seems to me that the same level of > authentication should be provided for both > peers and that server MUST NOT include MD5 > or SHA-1. > > A SHOULD NOT status might be welcome for a > smooth transition. At that time, collision > for MD5 and SHA1 are known for years. It is likely > that software that still need MD5 or SHA1 are > likely to never upgrade, so I doubt a smooth > path worth being taken. > > > 4. Server Key Exchange > >Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. >If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange >message it MUST abort the connection with the illegal_parameter >alert. > > > As per section 2, the client has clearly > indicated it does not support signature with > MD5/SHA1, so Server Key Exchange should not > end up with signature with SHA1/MD5. > > """ > If the client has offered the "signature_algorithms" extension, the >signature algorithm and hash algorithm MUST be a pair listed in that >extension. > """ > > It also seems to me that the constraint of > including a MD5 and SHA-1 signature is > related to the Certificate. I suspect that > some clarification are needed here. > > Since the case where the extension becomes > mandatory, the quoted text above of RFC 5246 > might be updated as well, though this does > not appear that necessary. > > > > 5. Certificate Verify > >Clients MUST NOT include MD5 and SHA-1
[TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
Reviewer: Daniel Migault Review result: Ready with Nits Hi, I reviewed this document as part of the IoT Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Review Results: Ready with Nits Please find my comments below. Yours, Daniel Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 draft-ietf-tls-md5-sha1-deprecate-04 [...] 1. Introduction The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in [RFC5246]. MD5 and SHA-1 have been proven to be insecure, subject to collision attacks [Wang]. In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. NIST formally deprecated use of SHA-1 in 2011 [NISTSP800-131A-R2] and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack. In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions [Transcript-Collision]. Further, in 2017, researchers from Google and CWI Amsterdam [SHA-1-Collision] proved SHA-1 collision attacks were practical. This document updates [RFC5246] and [RFC7525] in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures. However, this document does not deprecate SHA-1 in HMAC for record protection. RFC6194 may be mentioned as a reference for not deprecating HMAC-SHA-1 as well as an additional reference to [NISTSP800-131A-R2]. Reading the text the situation of HMAC with MD5 is unclear. Since we specify that SHA-1 is not deprecated for HMAC we may specify the status for HMAC with MD5. Given RFC6151 I hope the reason is that MD5 and HMAC-MD5 has already been deprecated but I have not found this. Maybe that would worth mentioning it is deprecated already. [...] 2. Signature Algorithms Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms extension. If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used (for example, when using PSK ciphers). It seems to me that the server behavior might be defined as well. In our case this could be something around the lines the server MUST ignore MD5 and SHA1 values in the signature algorithm extension. 3. Certificate Request Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest messages. It seems to me that the same level of authentication should be provided for both peers and that server MUST NOT include MD5 or SHA-1. A SHOULD NOT status might be welcome for a smooth transition. At that time, collision for MD5 and SHA1 are known for years. It is likely that software that still need MD5 or SHA1 are likely to never upgrade, so I doubt a smooth path worth being taken. 4. Server Key Exchange Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. As per section 2, the client has clearly indicated it does not support signature with MD5/SHA1, so Server Key Exchange should not end up with signature with SHA1/MD5. """ If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. """ It also seems to me that the constraint of including a MD5 and SHA-1 signature is related to the Certificate. I suspect that some clarification are needed here. Since the case where the extension becomes mandatory, the quoted text above of RFC 5246 might be updated as well, though this does not appear that necessary. 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 it MUST abort the connection with handshake_failure or insufficient_security alert. 6. Certificate Unless I am missing something, it seems to me that signature may also be found in the Certificate messages for the chain as well in the restriction of the signature algorithm. The end certificate is associated to the peer while other certificate are related to a CA. It seems that client and server behavior may be specified. The quoted text below may be helpful to clarify. """ If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.
