On Tue, Oct 08, 2019 at 08:25:51PM +0700, Rob Sayre wrote: > On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk <ka...@mit.edu> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
