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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 9, 2019 at 5:28 AM Rob Sayre <[e-mail]> wrote:

> On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla <[e-mail]> 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