Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, On 09/03/2019 20:04, John Mattsson wrote: > Yes, you can find the 3GPP TLS profile in Clause 6.2 of 3GPP TS 33.210 > https://www.3gpp.org/DynaReport/33210.htm Thanks for that, will add a mention. And in a nice bit of irony, the www.3gpp.org server uses TLS1.0 :-) S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Stephen, >> 3GPP has deprecated TLS 1.0 and DTLS 1.0 some years ago (but could at >> that time not deprecate TLS 1.1 due to interop with older releases). >> I would estimate that 3GPP will deprecate TLS 1.1 this year, at least >> that is what I am going to suggest. I think that 3GPP will deprecate >> non-AEAD and non-PFS cipher suites at the same time as TLS 1.1. > >Good to know. Might be no harm to put in some reference to that if you >have one? Yes, you can find the 3GPP TLS profile in Clause 6.2 of 3GPP TS 33.210 https://www.3gpp.org/DynaReport/33210.htm Rel-15 is stable, Rel-16 is work-in-progress. TLS 1.0 and DTLS 1.0 was forbidden already 2016 in Rel-14. At that time the 3GPP TLS profile was in Annex E of 3GPP TS 33.310 https://www.3gpp.org/DynaReport/33310.htm >> - I think the document should mention DTLS 1.0 much earlier, probably >> even in the title. > >Fair point. Didn't add to title but added stuff in the abstract. > >But that does raise an issue for the WG. I never checked what >else refers to 4347 that's needs to be updated. (Sigh, I should >have done that before I guess;-) Sorry ;-) /John -Original Message- From: Stephen Farrell Date: Saturday, 9 March 2019 at 16:06 To: John Mattsson , "TLS@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt Hi John, On 08/03/2019 22:44, John Mattsson wrote: > Hi, > > Thanks for driving this. Great work. I would like to see deprecation > of done more often in IETF and elsewhere. > > 3GPP has deprecated TLS 1.0 and DTLS 1.0 some years ago (but could at > that time not deprecate TLS 1.1 due to interop with older releases). > I would estimate that 3GPP will deprecate TLS 1.1 this year, at least > that is what I am going to suggest. I think that 3GPP will deprecate > non-AEAD and non-PFS cipher suites at the same time as TLS 1.1. Good to know. Might be no harm to put in some reference to that if you have one? > Moving deprecation of SHA-1 to a different document makes sense to > me. I would want such a document be deprecate a much as section 9.2 > of RFC 7540 with the exception of TLS_PSK_WITH_AES_128_CCM_8 for IoT. > I.e, I think such a document should forbid non-AEAD and < 2048 DHE as > well as changing the MTI cipher suite in TLS 1.2. I'd support progressing such a draft if someone wrote one. Or maybe that'd be good text to include in a revision of BCP195 when we've a bit more experience with TLSv1.3. For now, I think leaving in section 3 is ok though - killing sha-1 multiple times still leaves it as dead as killing it once:-) > - I think the document should mention DTLS 1.0 much earlier, probably > even in the title. Fair point. Didn't add to title but added stuff in the abstract. But that does raise an issue for the WG. I never checked what else refers to 4347 that's needs to be updated. (Sigh, I should have done that before I guess;-) So I re-ran my script to find non-obsoleted RFCs with normative references to 4347 and that turns up these new ones: - RFC 8261, which says: The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC was published. In the absence of a revision to this document, the latter requirement applies to all future versions of DTLS when they are published as RFCs. This document will only be revised if a revision to DTLS or SCTP makes a revision to the encapsulation necessary. I guess we could UPDATE that via this draft but we should probably add some text if doing that, and we defo need to check if WebRTC really needs DTLSv1.0 or if it's ok to deprecate that. (Anyone know?) I've added a note to the draft wondering what to do about that but did't add 8261 to the list of RFCs UPDATEd by this. - RFC 6460 is suite-B which is already historic, so it probably doesn't matter. I added this to the mega-list of stuff updated by this one as that seems harmless. - RFC 6353 is SNMP/TLS so seems like a straightforward case. I added this to the list updated here. - RFC 6084, which is "GIST" whatever that is. I added this to the list updated here. - RFC 6083 is DTLS/SCTP. I added this to the list updated here. - RFC 6012 is DTLS for syslog. I added this to the list updated here. - RFC 5456 is some asterisk-related protocol. I added this to the list updated here. - RFC 5415 is CAPWAP. I added this to the list updated here. > - Nit: The document uses "TLS1.0" "TLSv1.0" while most other drafts > use "TLS 1.0" I did a pass trying to make those consistently be TLSv1.x. The changes above are reflected in the editor's copy, [1] now but since those new UPDATE references are a substantive change, I'll push out a -02 later today or tomorrow. Cheers, S. [1] https://github
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi John, On 08/03/2019 22:44, John Mattsson wrote: > Hi, > > Thanks for driving this. Great work. I would like to see deprecation > of done more often in IETF and elsewhere. > > 3GPP has deprecated TLS 1.0 and DTLS 1.0 some years ago (but could at > that time not deprecate TLS 1.1 due to interop with older releases). > I would estimate that 3GPP will deprecate TLS 1.1 this year, at least > that is what I am going to suggest. I think that 3GPP will deprecate > non-AEAD and non-PFS cipher suites at the same time as TLS 1.1. Good to know. Might be no harm to put in some reference to that if you have one? > Moving deprecation of SHA-1 to a different document makes sense to > me. I would want such a document be deprecate a much as section 9.2 > of RFC 7540 with the exception of TLS_PSK_WITH_AES_128_CCM_8 for IoT. > I.e, I think such a document should forbid non-AEAD and < 2048 DHE as > well as changing the MTI cipher suite in TLS 1.2. I'd support progressing such a draft if someone wrote one. Or maybe that'd be good text to include in a revision of BCP195 when we've a bit more experience with TLSv1.3. For now, I think leaving in section 3 is ok though - killing sha-1 multiple times still leaves it as dead as killing it once:-) > - I think the document should mention DTLS 1.0 much earlier, probably > even in the title. Fair point. Didn't add to title but added stuff in the abstract. But that does raise an issue for the WG. I never checked what else refers to 4347 that's needs to be updated. (Sigh, I should have done that before I guess;-) So I re-ran my script to find non-obsoleted RFCs with normative references to 4347 and that turns up these new ones: - RFC 8261, which says: The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC was published. In the absence of a revision to this document, the latter requirement applies to all future versions of DTLS when they are published as RFCs. This document will only be revised if a revision to DTLS or SCTP makes a revision to the encapsulation necessary. I guess we could UPDATE that via this draft but we should probably add some text if doing that, and we defo need to check if WebRTC really needs DTLSv1.0 or if it's ok to deprecate that. (Anyone know?) I've added a note to the draft wondering what to do about that but did't add 8261 to the list of RFCs UPDATEd by this. - RFC 6460 is suite-B which is already historic, so it probably doesn't matter. I added this to the mega-list of stuff updated by this one as that seems harmless. - RFC 6353 is SNMP/TLS so seems like a straightforward case. I added this to the list updated here. - RFC 6084, which is "GIST" whatever that is. I added this to the list updated here. - RFC 6083 is DTLS/SCTP. I added this to the list updated here. - RFC 6012 is DTLS for syslog. I added this to the list updated here. - RFC 5456 is some asterisk-related protocol. I added this to the list updated here. - RFC 5415 is CAPWAP. I added this to the list updated here. > - Nit: The document uses "TLS1.0" "TLSv1.0" while most other drafts > use "TLS 1.0" I did a pass trying to make those consistently be TLSv1.x. The changes above are reflected in the editor's copy, [1] now but since those new UPDATE references are a substantive change, I'll push out a -02 later today or tomorrow. Cheers, S. [1] https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt > > Cheers, John > > -Original Message- From: TLS on > behalf of Stephen Farrell Date: Thursday, > 8 November 2018 at 06:36 To: "TLS@ietf.org" Subject: > Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt > > > Hiya, > > This version attempts to make the few changes discussed at the > meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs > this might need to update, and may of course have mucked that up, so > if anyone has a chance to check if (some of) those make sense, that'd > be great. > > Ta, S. > > On 08/11/2018 05:28, 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 TLSv1.0 and TLSv1.1 Authors : >> Kathleen Moriarty Stephen Farrell Filename: >> draft-ietf-tls-oldversions-deprecate-01.txt Pages : 21 >> Date: 2018-11-07 >> >> Abstract: This document, if approved, formally deprecates Transport >> Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and >> moves these
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi, Thanks for driving this. Great work. I would like to see deprecation of done more often in IETF and elsewhere. 3GPP has deprecated TLS 1.0 and DTLS 1.0 some years ago (but could at that time not deprecate TLS 1.1 due to interop with older releases). I would estimate that 3GPP will deprecate TLS 1.1 this year, at least that is what I am going to suggest. I think that 3GPP will deprecate non-AEAD and non-PFS cipher suites at the same time as TLS 1.1. Moving deprecation of SHA-1 to a different document makes sense to me. I would want such a document be deprecate a much as section 9.2 of RFC 7540 with the exception of TLS_PSK_WITH_AES_128_CCM_8 for IoT. I.e, I think such a document should forbid non-AEAD and < 2048 DHE as well as changing the MTI cipher suite in TLS 1.2. - I think the document should mention DTLS 1.0 much earlier, probably even in the title. - Nit: The document uses "TLS1.0" "TLSv1.0" while most other drafts use "TLS 1.0" Cheers, John -Original Message- From: TLS on behalf of Stephen Farrell Date: Thursday, 8 November 2018 at 06:36 To: "TLS@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt Hiya, This version attempts to make the few changes discussed at the meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs this might need to update, and may of course have mucked that up, so if anyone has a chance to check if (some of) those make sense, that'd be great. Ta, S. On 08/11/2018 05:28, 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 TLSv1.0 and TLSv1.1 > Authors : Kathleen Moriarty > Stephen Farrell > Filename: draft-ietf-tls-oldversions-deprecate-01.txt > Pages : 21 > Date: 2018-11-07 > > Abstract: >This document, if approved, formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates many RFCs that normatively refer to TLS1.0 or >TLS1.1 as described herein. This document also updates RFC 7525 and >hence is part of BCP195. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Stephen, And RFC 7525 (belonging to BCP 195) states in Section 3.1.1: o Implementations SHOULD NOT negotiate TLS version 1.1 [...] o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. That's why I thought RFC 8143 was already requiring not to use TLS 1.1. SHOULD NOT != MUST NOT though:-) And in any case, an additional unnecessary update would be no harm in this case, so I figure it's best to leave it as-is. Sure. (Unless I'm missing some reason why that UPDATE would do damage, in which case, we should chat more.) No damage at all. You can leave it as-is. So, yes, I've added 7525 to the list of UPDATEd stuff in my copy and made a change of intended status to BCP. (I bet a beer we'll change that again >1 time:-) :) -- Julien ÉLIE « Si l'art n'a pas de patrie, les artistes en ont une. » (Camille Saint-Saëns) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, On 08/03/2019 19:31, Julien ÉLIE wrote: > Hi Stephen, >>> That's why I suggest draft-ietf-tls-oldversions-deprecate does not >>> update RFC 4642. It is no longer useful. >>> Are you OK with this analysis? >> >> Sorta:-) I think these are overlapping but not quite >> identical updates. E.g. IIUC 8143 doesn't say to not >> use TLSv1.1. I added the sentence below to the editor's >> copy [1], but happy to do something else if I'm wrong, >> which is entirely possible;-) > > RFC 8143 (updating RFC 4642) states in Section 3: > > The best current practices documented in [BCP195] apply here. > Therefore, NNTP implementations and deployments compliant with this > document are REQUIRED to comply with [BCP195] as well. > > And RFC 7525 (belonging to BCP 195) states in Section 3.1.1: > > o Implementations SHOULD NOT negotiate TLS version 1.1 > [...] > o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to > negotiate TLS version 1.2 over earlier versions of TLS. > > That's why I thought RFC 8143 was already requiring not to use TLS 1.1. SHOULD NOT != MUST NOT though:-) And in any case, an additional unnecessary update would be no harm in this case, so I figure it's best to leave it as-is. (Unless I'm missing some reason why that UPDATE would do damage, in which case, we should chat more.) > Incidentally, in the Abstract of draft-ietf-tls-oldversions-deprecate, > it is said that this document updates RFC 7525, but RFC 7525 does not > appear in the Updates list. Shouldn't it be added? Yeah, I was wondering about that too;-) A BCP can consist of >1 RFC (e.g. see BCP10 [1]). So this one can become part of BCP195 without UPDATEing RFC7525 I think. However, now that I actually look at BCP 10, it has two RFCs: 7437 and 8318. And in that case 8318 does update 7437. So, yes, I've added 7525 to the list of UPDATEd stuff in my copy [2] and made a change of intended status to BCP. (I bet a beer we'll change that again >1 time:-) Cheers, S. [1] https://tools.ietf.org/html/bcp10 [2] https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Stephen, That's why I suggest draft-ietf-tls-oldversions-deprecate does not update RFC 4642. It is no longer useful. Are you OK with this analysis? Sorta:-) I think these are overlapping but not quite identical updates. E.g. IIUC 8143 doesn't say to not use TLSv1.1. I added the sentence below to the editor's copy [1], but happy to do something else if I'm wrong, which is entirely possible;-) RFC 8143 (updating RFC 4642) states in Section 3: The best current practices documented in [BCP195] apply here. Therefore, NNTP implementations and deployments compliant with this document are REQUIRED to comply with [BCP195] as well. And RFC 7525 (belonging to BCP 195) states in Section 3.1.1: o Implementations SHOULD NOT negotiate TLS version 1.1 [...] o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. That's why I thought RFC 8143 was already requiring not to use TLS 1.1. Incidentally, in the Abstract of draft-ietf-tls-oldversions-deprecate, it is said that this document updates RFC 7525, but RFC 7525 does not appear in the Updates list. Shouldn't it be added? -- Julien ÉLIE « Le rire est une chose sérieuse avec laquelle il ne faut pas plaisanter. » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Julien, Thanks for taking the time to check this! On 07/03/2019 20:42, Julien ÉLIE wrote: > Hi Stephen, >> This version attempts to make the few changes discussed >> at the meeting on Monday. I wrote a script that gave me >> a list of 76(!) RFCs this might need to update, and may >> of course have mucked that up, so if anyone has a chance >> to check if (some of) those make sense, that'd be great. > > I believe updating RFC 4642 (TLS with NNTP) is useless because this RFC > has already been updated by RFC 8143. > > In RFC 8143: > > A.6. Related to Other Obsolete Wording > > The first two sentences of the seventh paragraph in Section 2.2.2 of > [RFC4642] are removed. There is no special requirement for NNTP with > regard to TLS Client Hello messages. Section 7.4.1.2 and Appendix E > of [RFC5246] apply. > > That is to say, the following sentences in RFC 4642 are no longer relevant: > > Servers MUST be able to understand backwards-compatible TLS Client > Hello messages (provided that client_version is TLS 1.0 or later), > and clients MAY use backwards-compatible Client Hello messages. > Neither clients nor servers are required to actually support Client > Hello messages for anything other than TLS 1.0. > > > > That's why I suggest draft-ietf-tls-oldversions-deprecate does not > update RFC 4642. It is no longer useful. > Are you OK with this analysis? Sorta:-) I think these are overlapping but not quite identical updates. E.g. IIUC 8143 doesn't say to not use TLSv1.1. I added the sentence below to the editor's copy [1], but happy to do something else if I'm wrong, which is entirely possible;-) "In the case of [RFC4642], that has already been updated by [RFC8143] which makes an overlapping, but not quite the same, update as this document." Cheers, S. [1] https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Stephen, This version attempts to make the few changes discussed at the meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs this might need to update, and may of course have mucked that up, so if anyone has a chance to check if (some of) those make sense, that'd be great. I believe updating RFC 4642 (TLS with NNTP) is useless because this RFC has already been updated by RFC 8143. In RFC 8143: A.6. Related to Other Obsolete Wording The first two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] are removed. There is no special requirement for NNTP with regard to TLS Client Hello messages. Section 7.4.1.2 and Appendix E of [RFC5246] apply. That is to say, the following sentences in RFC 4642 are no longer relevant: Servers MUST be able to understand backwards-compatible TLS Client Hello messages (provided that client_version is TLS 1.0 or later), and clients MAY use backwards-compatible Client Hello messages. Neither clients nor servers are required to actually support Client Hello messages for anything other than TLS 1.0. That's why I suggest draft-ietf-tls-oldversions-deprecate does not update RFC 4642. It is no longer useful. Are you OK with this analysis? -- Julien ÉLIE « Le rire est une chose sérieuse avec laquelle il ne faut pas plaisanter. » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
On Fri, Nov 9, 2018 at 2:20 AM Stephen Farrell wrote: > On 08/11/2018 17:21, Hubert Kario wrote: > > what was the rationale for dropping the section about deprecating SHA-1 in > > TLS > > 1.2? I see nothing in minutes from IETF103. > > I asked during the presentation if the WG wanted to > keep it or not, as it's clearly not quite the same > as the rest of the document. The limited feedback in > the room was that it'd be better to not include this > here but to do it elsewhere, [...] This is my understanding also, and I would support that plan. The question of versions is enough different that I think that it will progress on a different timescale. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, On 08/11/2018 17:21, Hubert Kario wrote: > what was the rationale for dropping the section about deprecating SHA-1 in > TLS > 1.2? I see nothing in minutes from IETF103. I asked during the presentation if the WG wanted to keep it or not, as it's clearly not quite the same as the rest of the document. The limited feedback in the room was that it'd be better to not include this here but to do it elsewhere, without identifying a specific document or activity that'd cover it. The logic was (IIUC) mostly down to keeping this draft more focused. I don't think it was a desire to keep using SHA-1. The draft minutes Rich sent do say: "Remove SHA-1 deprecation from this document." As we reckoned the above might be the case (as per the comment in the version before adoption), I went ahead and excised that bit for now. If the WG do prefer to keep it in, I'm fine with that, of course. Cheers, S. PS: I guess those are draft minutes and we should make sure this point is clear in 'em - I'll do that 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
On Thursday, 8 November 2018 06:28:31 CET 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 TLSv1.0 and TLSv1.1 > Authors : Kathleen Moriarty > Stephen Farrell > Filename: draft-ietf-tls-oldversions-deprecate-01.txt > Pages : 21 > Date: 2018-11-07 > > Abstract: >This document, if approved, formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates many RFCs that normatively refer to TLS1.0 or >TLS1.1 as described herein. This document also updates RFC 7525 and >hence is part of BCP195. what was the rationale for dropping the section about deprecating SHA-1 in TLS 1.2? I see nothing in minutes from IETF103. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, This version attempts to make the few changes discussed at the meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs this might need to update, and may of course have mucked that up, so if anyone has a chance to check if (some of) those make sense, that'd be great. Ta, S. On 08/11/2018 05:28, 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 TLSv1.0 and TLSv1.1 > Authors : Kathleen Moriarty > Stephen Farrell > Filename: draft-ietf-tls-oldversions-deprecate-01.txt > Pages : 21 > Date: 2018-11-07 > > Abstract: >This document, if approved, formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates many RFCs that normatively refer to TLS1.0 or >TLS1.1 as described herein. This document also updates RFC 7525 and >hence is part of BCP195. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
