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. > "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
