On Wed, Oct 9, 2019 at 5:28 AM Rob Sayre <say...@gmail.com> wrote: > On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla <e...@rtfm.com> wrote: > >> >>> 1) it doesn't seem like a particularly valid claim to say that the >>> document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a >>> missing reference. >>> >> >> Well I suppose you're entitled to your opinion, but no, I don't think >> that's true. We have a very specific meaning for normative dependency and >> in no way would this be one. At most this would be an informative reference. >> >> In any case, this is not the proper place for this discussion. If you >> want this document changed, you'll need to take it to the RTCWEB WG. >> > > Honestly, thank you for the sincere response. > > After I read more of the many relevant documents, it became clear > that draft-ietf-tls-oldversions-deprecate says implementations MUST NOT > negotiate DTLS 1.0, while RFC 6347 and draft-ietf-rtcweb-security-arch > encourage negotiation that results in endpoints agreeing on DTLS 1.0. >
We should take 6347 and draft-ietf-rtcweb-security-arch separately. When we have protocol version X and we introduce X+1, we're almost never saying "you shouldn't negotiate X", because that would totally break the transition story. Rather, we're saying "X and X+1 can coexist". Then, once X+1 becomes sufficiently popular that you no longer need to support X, we can say "you shouldn't even support X" (whether we should say that depends on the details of X). So, 6347 was totally reasonable at the time and I expect the guidance in this document to override 6347 which all seems quite normal. draft-ietf-rtcweb-security arch doesn't precisely encourage you to implement DTLS 1.0; there's no normative language at all (even in the non-2119 sense). It makes s factual statement about the history of the document and about the impact of implementing only DTLS 1.2 and leaves it up to the implementor what to do with that statement. I agree that the fact that it bothers to mention it might be read as implying that people should do DTLS 1.0, but that's not actually in the text. Indeed, I could imagine this document including both this text *and* a MUST NOT implement DTLS 1.0 (that's actually how one has to interpret the union of draft-ietf-rtcweb-security-arch and draft-ietf-tls-oldversions-deprecate), with the understanding that the point of the "might encounter interoperability issues" is to document the impact of the MUST NOT requirement. With that said, as I mentioned in my earlier response, it was understood when we adopted this draft that this was kind of a 6119 "MUST (but we know you won't)" situation. See, for instance. the comments from DKG in the minutes here: "DKG: we can afford to publish this without driving numbers down to zero. Multiple audiences for documents like this, can make sure this is useful for many audiences. Clear advice for implementers: can't remove entirely, but here are things you can do. We publish this now to drive adoption, not wait for adoption to drive" https://datatracker.ietf.org/meeting/102/materials/minutes-102-tls-11 -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
