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

From: John Mattsson <[email-masked]>
Date: Tue, 1 Oct 2019 08:03:59 +0000

Hi,

I think draft-ietf-tls-oldversions-deprecate needs to update draft-ietf-rtcweb-security-arch as well.

draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support of DTLS 1.0.

  "Earlier drafts of this specification required DTLS
  1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
  at the time of this writing some implementations do not support DTLS
  1.2; endpoints which support only DTLS 1.2 might encounter
  interoperability issues."

You should check if there are more drafts in the publication process that needs to be updated.

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Sean Turner via Datatracker <[email-masked]>
Date: Friday, 28 June 2019 at 15:14
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

    Sean Turner has requested publication of draft-ietf-tls-oldversions-deprecate-05 as Best Current Practice on behalf of the TLS working group.
    
    Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
    
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 1 Oct 2019 06:50:55 -0400

On Tue, Oct 1, 2019 at 4:04 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

> Good catch.

> You should check if there are more drafts in the publication process that

This is something the security directorate should be watching for to check
in reviews prior to publication.  The ADs will also be adding this to their
list of things to look for in drafts that are in the publication queue as
that's been the practice for some time.  A proactive search could be
helpful, but having the stop gap in place is likely best as it could come
in in drafts that have not been written yet.

Best regards,
Kathleen

> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>     Sean Turner has requested publication of
> draft-ietf-tls-oldversions-deprecate-05 as Best Current Practice on behalf
> of the TLS working group.
>
>     Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Oct 2019 13:33:49 +0100

Hiya,

>>   interoperability issues."

I'm not sure what that'd mean for our draft (meaning
draft-ietf-tls-oldversions-deprecate) as we can't
"UPDATE" an I-D.

draft-ietf-rtcweb-security-arch-20 is in the RFC editor
queue, but is part of a giant cluster IIRC so I suspect
nobody will want to touch anything there:-)

I think something like this (or maybe exactly this) did
come up before and the answer was that it was best to
leave it as-is for now. (But I'm open to correction on
that and/or maybe things have changed.)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Oct 2019 13:14:36 -0700

> You should check if there are more drafts in the publication process that

I don't particularly mind, but this text was actually the result of some
pretty extensive discussion and compromising in rtcweb, so it's not just as
simple as changing this text.

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Oct 2019 14:17:01 +0100

> On Oct 1, 2019, at 21:14, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Oct 1, 2019 at 1:04 AM John Mattsson <john.mattsson=[email-masked]> wrote:
> Hi,
> 
> I don't particularly mind, but this text was actually the result of some pretty extensive discussion and compromising in rtcweb, so it's not just as simple as changing this text.

You can change the text, but I do not believe it will change the implementations.  I would leave the text as is and NOT do an updates header.

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Oct 2019 14:20:19 +0100

Hiya,

On 02/10/2019 14:17, Sean Turner wrote:
> You can change the text, but I do not believe it will change the
> implementations.  I would leave the text as is and NOT do an updates
> header.

WFM. I have executed that NOOP:-)

S.

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Oct 2019 14:45:08 +0000

Hi,

Sean Turner wrote:
> "You can change the text, but I do not believe it will change the implementations."

I would much rather have a future proof RFC that forbids negotiation of DTLS 1.0 with the knowledge that some implementations will temporary violate that, than having an RFC that long time in the future allows negotiation and use of DTLS 1.0.

Eric Rescorla wrote:
> "result of some pretty extensive discussion and compromising in rtcweb"

That does not surprise me, but I think that is part of the problem. These things should mainly be decided by the TLS working group. Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That is half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was submitted and almost 7 years after DTLS 1.0 was made obsolete.

No matter what is done in this particular case, I think the important thing to discuss is how we avoid drafts that only support obsolete versions of TLS/DTLS in the future. According to my understanding of the comments in the thread "Lessons learned from TLS 1.0 and TLS 1.1 deprecation", both me, Kathleen Moriarty, and Martin Thomson understands obsoleted as:

"New implementations and deployments MUST include support of the new version".

If this is not clearly defined somewhere, I think it needs to be specified. If it is specified somewhere, IETF needs to make sure to follow apply it.

Cheers,
John

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Oct 2019 17:11:42 -0700

On Wed, Oct 02, 2019 at 02:45:08PM +0000, John Mattsson wrote:
> That does not surprise me, but I think that is part of the problem. These
> things should mainly be decided by the TLS working group.

How?  Just by publishing BCPs, or is the TLS WG also supposed to (e.g.)
watch IETF LCs and complain about use of old protocol versions?

> Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That is
> half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was
> submitted and almost 7 years after DTLS 1.0 was made obsolete.

Mandating (D)TLS 1.0 is not going to get past the IESG in 2018.  We can
(and are) try to better communicate our expectations for this sort of thing
to the WGs, but it seems unrealistic to expect a 100% success rate from
them, since it's usually not the WG's core competency.  (See also
https://mailarchive.ietf.org/arch/msg/wgchairs/dfe_5obSQm7YK7JzVbmc-MbXNmU .)

> If this is not clearly defined somewhere, I think it needs to be specified. If it is specified somewhere, IETF needs to make sure to follow apply it.

Even supposing everyone agrees on this, there seem to be some fencepost
issues surrounding "new".  Is a protocol "new" when it gets published as an
RFC, or at WGLC, or even earlier?  I have been pretty laid-back until now
about requiring things coming in front of the IESG to pick up TLS 1.3,
since for the most part they were in progress (including implementations)
before TLS 1.3 implementations were readily available in production-grade
form.  It's about time to tighten up on that, since it's been over a year
since RFC 8446, but I'm not sure I fully understand where you want us to
fall across these boundary conditions.

-Ben

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Oct 2019 08:08:04 -0600

I do not think you have consensus for that change to WebRTC - it was discussed extensively. I would just leave things as they are. 

> On Oct 2, 2019, at 8:45 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
> 
> Sean Turner wrote:

---

From: Rob Sayre <[email-masked]>
Date: Fri, 4 Oct 2019 21:43:13 +0700

On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <[email-masked]> wrote:

>
> I do not think you have consensus for that change to WebRTC - it was
> discussed extensively. ...
>

 While that may be true, readers of this list might want to read a
rationale, rather than just the results of a negotiation. Is there a
rationale somewhere?

It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Oct 2019 07:47:50 -0700

> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.

A few points.

1. It doesn't pull it in. There's no reference and there's just an
informative statement.
2. There is a rationale. In fact, the relevant text pretty much is all
rationale.

   All Implementations MUST support DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
   curve [FIPS186
<https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>].
Earlier drafts of this specification required DTLS
   1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
   at the time of this writing some implementations do not support DTLS
   1.2; endpoints which support only DTLS 1.2 might encounter
   interoperability issues.

-Ekr

Rob

---

From: Rob Sayre <[email-masked]>
Date: Fri, 4 Oct 2019 21:57:53 +0700

> 1. It doesn't pull it in. There's no reference and there's just an

Shouldn't there be an informative reference?

>    curve [FIPS186 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>].  Earlier drafts of this specification required DTLS
Yes, I read this section and I was wondering what the rationale was for the
text: "endpoints which support only DTLS 1.2 might encounter
interoperability issues." Is there some data behind this? I'm not
suggesting a change in the draft without more information, but I do wonder
how the WG came to agree on this text.

thanks,
Rob

---

From: John Mattsson <[email-masked]>
Date: Sat, 5 Oct 2019 12:32:04 +0000

>watch IETF LCs and complain about use of old protocol versions?

Just by publishing BCPs and standard track documents. Watching out for old protocol versions in other WG’s is not really the TLS WG’s job. Hopefully, everybody in the security area complain if they see use of obsolete versions or weak algorithms.

>> If this is not clearly defined somewhere, I think it needs to be specified. If it is >specified somewhere, IETF needs to make sure to follow apply it.
>

I fully agree. There are several boundary conditions here and any best practice can probably not be summarized on a single line. Tightening up requirement of new drafts to support TLS 1.3 now seems about right. There could probably still be exceptions, but they would have to be well motivated. 

/John

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Friday, 4 October 2019 at 02:11
To: John Mattsson <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, Sean Turner <[email-masked]>, Sean Turner via Datatracker <[email-masked]>, "[email-masked]" <[email-masked]>, IESG Secretary <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

    
    
    https://protect2.fireeye.com/url?k=81062a4c-dd8ff05c-81066ad7-0cc47ad93e2a-1e749b7aef6efcb8&q=1&u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fwgchairs%2Fdfe_5obSQm7YK7JzVbmc-MbXNmU .)

    
    -Ben

---

From: John Mattsson <[email-masked]>
Date: Sat, 5 Oct 2019 12:57:49 +0000

Cullen Jennings <[email-masked]> wrote:

>discussed extensively. I would just leave things as they are.

My suggestion was to have draft-ietf-tls-oldversions-deprecate update the webrtc draft. I did not think that was controversial. My understanding was that IETF with this BCP had forbidden negotiation of DTLS 1.0 without exceptions. I thought the webrtc draft had simply been forgotten and that I had made a “good catch” as Kathleen expressed it.

I can live with the BCP not updating draft-ietf-tls-oldversions-deprecate if that delays publishing, but otherwise I see no reasons why WebRTC should get special treatment. There are other deployments out there with devices not supporting TLS 1.2.

---

From: John Mattsson <[email-masked]>
Date: Sat, 5 Oct 2019 13:12:42 +0000

Rob Sayre [email-masked] wrote:

"Is there some data behind this?

I agree with Rob, it would be interesting to get some data on why webrtc need to continue to negotiate and use DTLS 1.0. It would also be interesting to know for how long time webrtc plans to continue negotiate and use DTLS 1.0.

EAP-TLS also have legacy devices that do not support TLS 1.2 and in practice some EAP servers will probably continue to negotiate TLS 1.1 for a while. Still, the EMU WG agreed that the upcoming BCP forbidding use and negotiation of TLS 1.1 was the right thing to do as it puts increased pressure on implementations to improve.

Cheers,
John

From: Rob Sayre <[email-masked]>
Date: Friday, 4 October 2019 at 16:58
To: Eric Rescorla <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, "[email-masked]" <[email-masked]>, Sean Turner via Datatracker <[email-masked]>, IESG Secretary <[email-masked]>, "[email-masked]" <[email-masked]>, John Mattsson <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

I do not think you have consensus for that change to WebRTC - it was discussed extensively. ...

 While that may be true, readers of this list might want to read a rationale, rather than just the results of a negotiation. Is there a rationale somewhere?

A few points.

1. It doesn't pull it in. There's no reference and there's just an informative statement.

2. There is a rationale. In fact, the relevant text pretty much is all rationale.

   curve [FIPS186<https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>].  Earlier drafts of this specification required DTLS

   interoperability issues.

Yes, I read this section and I was wondering what the rationale was for the text: "endpoints which support only DTLS 1.2 might encounter interoperability issues." Is there some data behind this? I'm not suggesting a change in the draft without more information, but I do wonder how the WG came to agree on this text.

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 6 Oct 2019 09:42:05 -0700

> Shouldn't there be an informative reference?

I think that's largely a question for the sponsoring AD (CC'd) and the RFC
Editor.

> how the WG came to agree on this text.

My assumption (I was not following the work) is that it was a well-known
fact among implementors at the time that some large implementations only
implemented DTLS 1.0.  Accordingly, "might encounter interoperability
issues" is a bland uncontroversial fact, in that context.  It's not clear
to me that we are adding much value revisiting the rtcweb WG's decisions
over here on the TLS WG without getting input from rtcweb about why they
put it that way in the first place...

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Oct 2019 11:25:19 -0700

> Shouldn't there be an informative reference?

To what? Basically, what we had was the personal representations of WG
members that they had products or were aware of products that used DTLS 1.0
only.

> Yes, I read this section and I was wondering what the rationale was for
> the text: "endpoints which support only DTLS 1.2 might encounter

See above.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Oct 2019 11:27:03 -0700

On Sun, Oct 6, 2019 at 9:42 AM Benjamin Kaduk <[email-masked]> wrote:

> > >    curve [FIPS186 <
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>].
> the
> implemented DTLS 1.0.

Yes, though I don't have data on it.

Accordingly, "might encounter interoperability
> put it that way in the first place...

Fortunately, the WGs share a chair, so perhaps that chair could provide the
minutes, etc. :)

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Mon, 7 Oct 2019 10:30:38 +0700

> I think that's largely a question for the sponsoring AD (CC'd) and the RFC

Well, I hope we can all agree that the document refers to an RFC without a
citation in the references section.

> issues" is a bland uncontroversial fact, in that context.
>

That was definitely the case in November 2018, when the text was added:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-rtcweb-security-arch-17.txt

Chrome tried and failed to remove DTLS 1.0 in April 2019:
https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c38

But now all major browsers are removing TLS 1.0 and 1.1 support in January
of 2020:
https://groups.google.com/forum/#!searchin/discuss-webrtc/dtls$201.0%7Csort:date/discuss-webrtc/Dsq_14_WoUk/U2vFXSYlCgAJ
https://security.googleblog.com/2018/10/modernizing-transport-security.html

So, it seems like endpoints that don't support DTLS 1.2 will soon be the
ones "encountering interoperability issues".

Not sure whether a change to draft-ietf-rtcweb-security-arch or an update
in draft-ietf-tls-oldversions-deprecate is better.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 8 Oct 2019 00:29:29 +0700

On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla <[email-masked]> wrote:

> To what?

Hi, I missed this response. This discussion seems a bit tedious, but

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.
2) if "DTLS 1.0" remains in the document, I /think/ the document should
cite RFC 4347, and maybe the updates to it. But, perhaps there's a chain of
unstated dependencies in these documents, and I've only noticed the latest
one.

This thread also has some other unusual claims:

On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <[email-masked]>
wrote:
> we can't "UPDATE" an I-D.

Not true. If you need to refer to something that's been IESG-approved but
still in the RFC queue, you can leave a note for the RFC editor to update
the reference to the eventual RFC number.

> You can change the text, but I do not believe it will change the
implementations.

If true, changing the text would seem to be uncontroversial.

Anyway, leaving strange text like this DTLS 1.0 stuff in the webrtc
document is one thing (although I'm surprised the IESG allowed it).
Claiming that a document like draft-ietf-tls-oldversions-deprecate can't
update documents from a concluded WG is another.

If the IETF can't get consensus on actually deprecating DTLS 1.0, maybe
something similar to the text from draft-ietf-rtcweb-security-arch should
be added to draft-ietf-tls-oldversions-deprecate.

"Earlier specifications required DTLS 1.0. Endpoints which support only
DTLS 1.2 might encounter interoperability issues."

That would seem to subvert the point of the draft--I think this is the
point that the original post in this thread was making.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Oct 2019 21:12:44 +0100

Hiya,

> the reference to the eventual RFC number.

That would be an UPDATE on the eventual RFC and not on the
I-D. And in this case, it'd IMO not be a good plan as a) the
relevant WG didn't want that, b) the I-D in question is part
of a mega-cluster, so any dependency on it (as you suggest)
risks loadsa delay if the cluster doesn't get unstuck, which
can happen and c) our draft already stretches the header
enough updating 85 RFCs - trying to add an I-D to that list
would break tools and cause much pointless process-angst.

Mostly (a) is the reason to not do it though. If you want
to disagree with (a), then the right list for that would be
the rtcweb list I guess, even though the WG is now concluded
(which could, I guess, be (d);-)

Overall, the cost isn't worth the benefit IMO.

Cheers,
S.

---

From: Sean Turner <[email-masked]>
Date: Mon, 7 Oct 2019 20:30:47 -0400

> On Oct 7, 2019, at 16:12, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

draft-ietf-rtcweb-security-arch shepherd hat on

To ekr’s point, the decision to make that switch I think actually pre-dated me.  But before I go off and dig up the history, I think we should consider what an "updates” in terms of draft-ietf-tls-oldversions-deprecate would be.  First the 2119 requirement in draft-ietf-rtcweb-security-arch is as follows:

   curve [FIPS186].   

The rest of the quote contains no 2119 language and is merely an informative statement:

So, draft-ietf-tls-oldversions-deprecate would say nothing about DTLS1.2 because DTLS1.2 is not being deprecated.  It could update the informative statement to say something else, but it is a factual statement.  Maybe changing the last sentence to say “... which support only DTLS 1.0 might encounter interoperability issues” sounds somehow better, but maybe this is better just leave it alone.

spt

---

From: Rob Sayre <[email-masked]>
Date: Tue, 8 Oct 2019 12:02:24 +0700

On Tue, Oct 8, 2019 at 7:31 AM Sean Turner <[email-masked]> wrote:

> To ekr’s point, the decision to make that switch I think actually
> pre-dated me.  But before I go off and dig up the history, I think we
> should consider what an "updates” in terms of
> draft-ietf-tls-oldversions-deprecate would be.
>

I think the relevant text from draft-ietf-tls-oldversions-deprecate is
"Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347],
[RFC6347]."

The WebRTC text implies that it's ok to negotiate DTLS 1.0 [RFC4347], and
certainly doesn't rule it out.

thanks,
Rob

---

From: John Mattsson <[email-masked]>
Date: Tue, 8 Oct 2019 10:28:23 +0000

The way I see it, the upcoming BCP applies to WebRTC irrespectively of whether it formally updates the document or not. The formal updates are important so people easily find the BCP, but not critical. Companies can anyway choose to implement WebRTC without implementing the BCP.

I do not think the BCP need to change any text in the WebRTC draft. The BCP updates a lot of other RFCs without changing the text in them.

I do not think the TLS WG should ask the WebRTC working group for permission, the BCP updates a huge number of RFCs from a lot of different groups. These groups were not asked.

I would like to see a formal update, but b) might be a valid reason to not do that.

John
From: Rob Sayre <[email-masked]>
Date: Tuesday, 8 October 2019 at 07:02
To: Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IESG Secretary <[email-masked]>, John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

On Tue, Oct 8, 2019 at 7:31 AM Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
draft-ietf-rtcweb-security-arch shepherd hat on

To ekr’s point, the decision to make that switch I think actually pre-dated me.  But before I go off and dig up the history, I think we should consider what an "updates” in terms of draft-ietf-tls-oldversions-deprecate would be.

I think the relevant text from draft-ietf-tls-oldversions-deprecate is "Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347],  [RFC6347]."

The WebRTC text implies that it's ok to negotiate DTLS 1.0 [RFC4347], and certainly doesn't rule it out.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Oct 2019 11:35:38 +0100

On 08/10/2019 11:28, John Mattsson wrote:
> I do not think the TLS WG should ask the WebRTC working group for
> permission, the BCP updates a huge number of RFCs from a lot of
> different groups. These groups were not asked.
IETF last call and IESG evaluation is when each of those
will ll turn out to be an issue, or a non-issue.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Oct 2019 05:05:06 -0700

> I-D. And in this case, it'd IMO not be a good plan as a) the

Recent IESGs have been taking the stance that it's weird to have "Updates:"
to a document that's not yet an RFC, mostly preferring to pull the document
in question back and get changed directly.  But ...

> can happen and c) our draft already stretches the header

... given that C238 is unblocked, dependencies-wise, that seems
questionable in this case.  (The whole set of documents does have to go
through the xmlv2-->xmlv3 conversion, though.)

> Overall, the cost isn't worth the benefit IMO.

That's roughly where I'm landing, too, though as noted previously, it's
largely up to the sponsoring AD.

-Ben

---

From: Daniel Migault <[email-masked]>
Date: Tue, 8 Oct 2019 09:22:23 -0400

Hi,

For clarity to the WG I am summarizing the discussion of the "lesson learnt
from deprecation" thread.

There is in my opinion a consensus that the current text does not emphasize
enough that TLS 1.3 is the current version of TLS. There is also a
consensus that the current draft limits the wording in emphasizing that TLS
1.3 obsoletes TLS 1.2 and is the current version to consider.

The current texts that are subject to changes are the following:

TEXT A:

"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""

Proposed alternatives are:
a) remove the sentence
b) leave the sentence as it is
c) clarify the sentence for example with the following text:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""

TEXT B:

"""TLSv1.2 has been the recommended version for IETF protocols since 2008,
providing sufficient time to transition away from older versions."""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""The current recommended version for TLS is 1.3 and version 1.2 has been
recommended since 2008, providing sufficient time to transition away from
older versions."""

TEXT C:

"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2. At the time of writing this document
this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly
RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is
RECOMMENDED.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

My personal opinion is to have some text that reflects what we think.

Yours,
Daniel

On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk <[email-masked]> wrote:

> .... given that C238 is unblocked, dependencies-wise, that seems

---

From: Rob Sayre <[email-masked]>
Date: Tue, 8 Oct 2019 20:25:51 +0700

On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk <[email-masked]> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 05:20:18 -0700

On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre <[email-masked]> 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.

> point that the original post in this thread was making.

When we agreed to discuss this draft, there was an explicit discussion of
the fact that this was the IETF's opinion based on security and protocol
maturity but that we expected the transition to take longer in some domains
than others, so I wouldn't have a problem with that kind of text, as I
think it's factually accurate and implicit.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 05:22:14 -0700

On Wed, Oct 9, 2019 at 5:20 AM Eric Rescorla <[email-masked]> wrote:

> When we agreed to discuss
>

adopt.

this draft, there was an explicit discussion of the fact that this was the
> IETF's opinion based on security and protocol maturity but that we expected
> the transition to take longer in some domains than others, so I wouldn't
> have a problem with that kind of text, as I think it's factually accurate
> and implicit.
>
> -Ekr
>
>
>> thanks,
>> Rob
>>
>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 9 Oct 2019 19:28:02 +0700

> 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.

That seems like the inconsistency to discuss.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 06:04:08 -0700

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

>> 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.
>>
>

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Oct 2019 12:15:15 +1100

On Thu, Oct 10, 2019, at 00:04, Eric Rescorla wrote:
> 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.

This is, I think, the best interpretation of the current situation.  At best, you make the same inference you always do: disabling DTLS 1.0 right away comes with some interoperability risks.

Just to add some data on this point: browsers are looking to disable DTLS 1.0 at around the same time, but our data about DTLS 1.0 usage isn't as good as for TLS 1.0, so this is less of a firm commitment.  For instance, this (https://mzl.la/31255vp) is a much higher proportion of the overall, but it is also quite noisy.

Either way, I expect this to go away at the same time or soon after.  We're a little more comfortable being a more aggressive with WebRTC.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Oct 2019 10:00:18 +0700

On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla <[email-masked]> wrote:

>  So, 6347 was totally reasonable at the time and I expect the guidance in
> this document to override 6347 which all seems quite normal.
>

Right, that makes sense.

> non-2119 sense).

It does have a normative reference to RFC 6347, and seems to be referencing
this part of it: "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)"

I can understand the WG's "MUST (but we know you won't)" situation. Trying
to write spec text for those situations always ends badly over time (imho),
but maybe editing the draft itself would be controversial.

It does look like draft-ietf-tls-oldversions-deprecate should update the
draft, if it's changed so that it updates DTLS-using RFCs. For example, if
the document had been published in 2017, would there even be a debate?

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Oct 2019 20:48:28 -0700

On Wed, Oct 9, 2019 at 8:00 PM Rob Sayre <[email-masked]> wrote:

> It does have a normative reference to RFC 6347, and seems to be
> referencing this part of it: "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)"
>

Yes, but this section of 6347 will be overriden by the present document

> the document had been published in 2017, would there even be a debate?

Yes. You don't need to mark the transitive closure of all dependent RFCs as
Updated.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Oct 2019 10:53:20 +0700

On Thu, Oct 10, 2019 at 10:49 AM Eric Rescorla <[email-masked]> wrote:

>
> You don't need to mark the transitive closure of all dependent RFCs as
> Updated.
>
Isn’t that one of the things the draft is doing, though?

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Oct 2019 09:16:57 -0700

> 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.

> 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.

> "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.

> is something I expect Area Directors to be doing. It's a predictable

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

---

From: Rob Sayre <[email-masked]>
Date: Fri, 11 Oct 2019 00:45:11 +0700

On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk <[email-masked]> wrote:

> The decision about
I don't think that is true. Here is one comment from the document shepherd:
https://mailarchive.ietf.org/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0

This one of those situations where the IETF rules are deliberately
ambiguous (I know most of the rules...).

> needs, but rather do so indirectly.

That is not what the draft does. For example, it updates RFC 4823, "FTP
Transport for Secure Peer-to-Peer Business Data Interchange over the
Internet".

Have you read the draft?

> from the IETF perspective

Nope, it can get changed. And it can get updated too. It's just a text
file, and the rules are fluid. :)

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Oct 2019 11:38:52 -0700

> https://mailarchive.ietf.org/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0

I don't think the cited message supports your claim (instead, it's just
commenting on whether changing the text would have any value independently
of the mechanics for doing so).

> ambiguous (I know most of the rules...).

I'm the AD for the TLS WG, and am charged with enforcing the rules.  If you
tell me a rule that I'm not enforcing or am misinterpreting, I'm happy to
adjust accordingly, but in the absence of such concrete details, I'm going
to trust my knowledge of the rules more than yours.

> Transport for Secure Peer-to-Peer Business Data Interchange over the

"for the reason you give" being the operative phrase.

> Have you read the draft?

Not recently; as noted upthread, it's in my queue of "publication
requested" documents accumulated backlog, but I have to do an AD evaluation
before it goes to IETF LC.

> file, and the rules are fluid. :)

I did not say it was impossible, just that there is a very high barrier and
in my assessment the value does not justify the cost of changing it.  But
as I've said repeatedly, I'm not the AD whose judgment matters, and I am
confused at why you're continuing to engage on the topic in this forum.

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Fri, 11 Oct 2019 03:37:55 +0700

> of the mechanics for doing so).

It says "You can change the text".

thanks,
Rob