On Thu, Sep 26, 2019 at 8:03 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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. > I think the reason John cc saag was that the request was more generic, that is not only focused to TLS, but the current discussion is only TLS focused. > > 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 > > I agree that how it should be. That said, if everyone were adopting the newest version, we would probably do not even need to deprecate oldest versions which would be phased out by themselves. Forum or standard bodies are good to define a direction for adopting new version and deprecating old versions. However, outside these groups, updating a new version is seen as deployment/development cost and as such, old version tends to remain until it is explicitly deprecated. > 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 believe that for a significant number of deployed software the reason to stick to TLS 1.2 is that it works with TLS 1.2, TLS 1.2 is not deprecated and still supported (=not deprecated). However I would be happy to be wrong. > 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." > > The opposite would be surprising, but I do understand your point. We could remain focus on the deprecation, not the adoption of the newest version. My motivation for explicitly push for TLS 1.3 was to remind your point 1) and 2). I think that would be useful to have these point in one way or another, but that is only my opinion. > _______________________________________________ > 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
