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

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 08, 2019 at 08:25:51PM +0700, Rob Sayre wrote:
> On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> > it's largely up to the sponsoring AD.
> >
> 
> Is that true? I'm not sure which procedure you're describing.

Per https://www.rfc-editor.org/current_queue.php ,
draft-ietf-rctweb-security-arch is in the RFC Editor queue, state "EDIT*R"
(copyediting, with some extra task for the RFC Editor staff, presumably
v2-->v3 XML conversion).  As far as the IETF is concerned, the document is
done and approved, and the only changes expected are editorial ones made by
the RFC Editor and editorial ones made during AUTH48.  Any substantive or
technical changes during AUTH48 require at a minimum approval by the
sponsoring AD, and if substantial enough, approval from the WG and possibly
re-running IETF LC and IESG review.  While it's true that we can do the
latter procedures at any time until the RFC is officially published, it's a
pretty heavyweight process and we generally only do it when there are
actual technical errors, and not just for things that we might do
differently if we were starting from scratch now.  The decision about
whether to make changes to the technical content thus lies with the
sponsoring AD for that document.

> At any rate, I think one issue is with the abstract
> of draft-ietf-tls-oldversions-deprecate:
> 
> "This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC6347]
> (but not DTLS version 1.2, and there is no DTLS version 1.1).
> This document updates many RFCs that normatively refer to TLSv1.0 or
> TLSv1.1 as described herein.  This document also updates RFC 7525 and hence
> is part of BCP195."
> 
> What it doesn't do is state that it updates RFCs that normatively refer to
> DTLS 1.0 and/or DTLS 1.2. It seems like it should, since RFC 6347 states:
> "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate
> with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS
> 1.2 implementations can interoperate with previous versions of TLS...".

I disagree that draft-ietf-tls-oldversions-deprecate needs to update all
consumers of DTLS 1.0/1.2, at least for the reason you give.  Those
documents properly refer to RFC 6347 (or 4347), and it is that RFC that we
are updating now.  We do not directly change those consuming documents'
needs, but rather do so indirectly.

> Although I favor deprecating DTLS 1.0 conclusively and thoroughly, there is
> an argument for eliding DTLS entirely
> in draft-ietf-tls-oldversions-deprecate, NIST SP800-52r2 explicitly states
> that it doesn't cover DTLS, but that document is the only citation in the
> "Support for Deprecation" section of draft-ietf-tls-oldversions-deprecate.

That's a fair question to ask, and I trust the chairs to shepherd any
additional discussion needed.  That said, since DTLS is basically a small
delta on top of TLS, if we are deprecating a TLS version for cause, it
seems likely to me that it is also appropriate to deprecate the closely
related DTLS version.

> Updating in-flight documents to avoid citing soon-to-be-deprecated TLS RFCs
> is something I expect Area Directors to be doing. It's a predictable
> problem.

Sure -- drafts coming in for IESG review are going to get flagged for any
(D)TLS 1.0 usage.  However, I disagree with characterizing
draft-ietf-rtcweb-security-arch as "in flight" -- from the IETF perspective
it's approved and done, and the barrier to making any further substantive
changes is extremely high.

-Ben