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. 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...". 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. 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. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
