Hi Kathleen, On Tue, Oct 1, 2019 at 7:07 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote:
> > > On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson= > 40ericsson....@dmarc.ietf.org> wrote: > >> Martin Thomson <m...@lowentropy.net>; wrote: >> >> >When we release a new version of something, we are sending a message: >> > >> >1. new implementations and deployments MUST include support for newer >> versions >> >2. existing implementations and deployments SHOULD be updated to support >> newer versions >> >> I agree very much with this summary and I would like to have it published >> somewhere. Take for example RFC 8261. It was published almost 6 years after >> RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and >> not DTLS 1.2. I think this is one of the lessons IETF should learn from the >> TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in the >> future? For an external viewer it must look pretty strange that IETF in Nov >> 2017 published an RFC relying on DTLS 1.0 and then 7 months later started >> working on a draft forbidding its use.... >> >> I would like to see something like the following statements published: >> >> "New implementations and deployments MUST include support for TLS 1.3" >> > We have this already, I believe in new drafts. > The current wording does not, in my opinion, make the message clear in the current draft. Maybe that is a perception of non native English speaker, but there are probably three sentences that could in my opinion make the message clearer. > > >> "Existing implementations and deployments SHOULD be updated to support >> TLS 1.3" >> "Existing implementations and deployments SHALL support TLS 1.3 by >> January 1, 2024" >> > > Are you proposing a draft to state this? If agreeable, this could be a > quick draft and support for 1.3 is a reasonable request to align with > requirements in industry. I'm not sure if our statement will drive the > date as much as NIST's, but it couldn't hurt and I would be surprised if > there were any objections to this. > > I don't think anything other than an RFC is the right approach, unless > there is an avenue I am not thinking about as having IETF consensus would > be what you'd want for it. > > >> >> >> """The expectation is that TLSv1.2 will continue to be used for many >> >> years alongside TLSv1.3.""" >> > >> >Some people have that expectation, but I think that John is right to >> challenge it. >There remain reasons that people are sticking with 1.2 for >> now, but those reasons >are mostly to do with allowing time to flush out >> the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies. >> >> I agree with Martin, and irrespectively of whether it is true or not, I >> do not see any need to have this sentence in an IETF draft. >> > > As for this sentence, we'll see where the discussion settles out - > removing or altering it. > > Best regards, > Kathleen > >> >> Cheers, >> John >> >> -----Original Message----- >> From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson < >> m...@lowentropy.net> >> Date: Friday, 27 September 2019 at 02:03 >> To: "TLS@ietf.org" <tls@ietf.org> >> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation >> >> So I agree with Kathleen's conclusion: not to change the goals of the >> current document. But there are changes that I think are necessary (and >> thanks to Daniel and John for highlighting these). >> >> BTW, I've moved this to the TLS working group, because this is an >> active topic there and I don't see anything in my email that SAAG needs to >> concern itself with. >> >> On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote: >> > My understanding of deprecating of TLS1.0 TLS 1.1 is that: >> > a) new software do not use these versions >> > b) existing software stop supporting these versions. >> >> That differs from my perspective. >> >> When we release a new version of something, we are sending a message: >> >> 1. new implementations and deployments MUST include support for newer >> versions >> 2. existing implementations and deployments SHOULD be updated to >> support newer versions >> >> When we deprecate an old version of something, we are sending a >> message: >> >> 3. only use this old version if you absolutely have to >> 4. you are encouraged to take active measures to remove the need to >> use the old version >> 5. you have our support if you decide not to support this old version >> >> Now, "support" from the IETF is about as meaningful as you think it >> is. And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ >> [RFC6919]. >> >> In browser-land, we've decided to form a coalition when it comes to >> removing TLS 1.0/1.1. 3GPP have obviously got their own support group, >> which seems to be functioning effectively, which is great. >> >> > """The expectation is that TLSv1.2 will continue to be used for >> many >> > years alongside TLSv1.3.""" >> >> Some people have that expectation, but I think that John is right to >> challenge it. There remain reasons that people are sticking with 1.2 for >> now, but those reasons are mostly to do with allowing time to flush out the >> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.. >> >> I would advocate for removing this statement and any residue of that >> sentiment from the draft. It's speculation and, even if it were true, it >> conveys the wrong message. The only message I would include is that one >> that is further down the document: "Any newer version of TLS is more secure >> than TLSv1.1." >> >> _______________________________________________ >> 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 >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > 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
