Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

[Benjamin Kaduk <[e-mail]>]

On Wed, Oct 02, 2019 at 02:45:08PM +0000, John Mattsson wrote:
> Hi,
> 
> Sean Turner wrote:
> > "You can change the text, but I do not believe it will change the implementations."
> 
> I would much rather have a future proof RFC that forbids negotiation of DTLS 1.0 with the knowledge that some implementations will temporary violate that, than having an RFC that long time in the future allows negotiation and use of DTLS 1.0.
> 
> 
> Eric Rescorla wrote:
> > "result of some pretty extensive discussion and compromising in rtcweb"
> 
> That does not surprise me, but I think that is part of the problem. These
> things should mainly be decided by the TLS working group.

How?  Just by publishing BCPs, or is the TLS WG also supposed to (e.g.)
watch IETF LCs and complain about use of old protocol versions?

> Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That is
> half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was
> submitted and almost 7 years after DTLS 1.0 was made obsolete.

Mandating (D)TLS 1.0 is not going to get past the IESG in 2018.  We can
(and are) try to better communicate our expectations for this sort of thing
to the WGs, but it seems unrealistic to expect a 100% success rate from
them, since it's usually not the WG's core competency.  (See also
https://mailarchive.ietf.org/arch/msg/wgchairs/dfe_5obSQm7YK7JzVbmc-MbXNmU .)

> 
> No matter what is done in this particular case, I think the important thing to discuss is how we avoid drafts that only support obsolete versions of TLS/DTLS in the future. According to my understanding of the comments in the thread "Lessons learned from TLS 1.0 and TLS 1.1 deprecation", both me, Kathleen Moriarty, and Martin Thomson understands obsoleted as:
> 
> "New implementations and deployments MUST include support of the new version".
> 
> If this is not clearly defined somewhere, I think it needs to be specified. If it is specified somewhere, IETF needs to make sure to follow apply it.

Even supposing everyone agrees on this, there seem to be some fencepost
issues surrounding "new".  Is a protocol "new" when it gets published as an
RFC, or at WGLC, or even earlier?  I have been pretty laid-back until now
about requiring things coming in front of the IESG to pick up TLS 1.3,
since for the most part they were in progress (including implementations)
before TLS 1.3 implementations were readily available in production-grade
form.  It's about time to tighten up on that, since it's been over a year
since RFC 8446, but I'm not sure I fully understand where you want us to
fall across these boundary conditions.

-Ben