Subject: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

From: "Christopher Wood" <[email-masked]>
Date: Fri, 12 Apr 2019 19:28:36 -0400

This is the working group last call for the "Deprecating TLSv1.0 and TLSv1.1” draft available at:

    https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/

Please review the document and send your comments to the list by April 26, 2019.

Thanks,
Chris, Joe, and Sean

---

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Apr 2019 18:59:29 -0700

> Please review the document and send your comments to the list by April 26,

Do it! It's time to end the Vaudenay attack before it's old enough to vote.

>
> Thanks,
> Chris, Joe, and Sean
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 13 Apr 2019 00:15:55 -0400

Section 1.1 doesn't say *how* those listed documents are updated.  Might pay to include a few works on how.

Section 2 can be cut down a lot.  The quote from another document is longer than the rest of the text.  In many ways, saying that the IETF is moving last is not a great thing to memorialize in RFC, as much as it is useful in an Internet-Draft or in argumentation in support of publication of the doc.

The title of Section 3 could be a bit clearer.

It might pay to explain what RFC 7525 is in Section 6.  Why does that document warrant special attention over the 70-odd other ones.

Otherwise, publish this.

---

From: John Mattsson <[email-masked]>
Date: Sat, 13 Apr 2019 07:43:30 +0000

Publish!

---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>

On 13 April 2019 at 01:29:59 CEST, Christopher Wood <[email-masked]> wrote:
This is the working group last call for the "Deprecating TLSv1.0 and TLSv1.1” draft available at:

Thanks,
Chris, Joe, and Sean

---

From: "Maarten Aertsen (NCSC-NL)" <[email-masked]>
Date: Wed, 24 Apr 2019 09:42:58 +0200

Hi,

> Please review the document and send your comments to the list by April 26, 2019.

I'd like to see this published.

@Kathleen, Stephen: in case there's any value in an additional ref for 
section 2, we published updated TLS-guidelines yesterday, with clear 
advice to phase out TLSv1, TLSv1.1.

https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.html

kind regards, Maarten

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Apr 2019 09:44:57 +0100

Hiya,

> https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.html

Thanks. Will take a peek when I go over the LC comments
(most likely over the w/e).

Funnily enough, the substantive LC comments so far as I
recall 'em are all from folks named Martin/Maarten - any
other similarly named folks out there with a comment? :-)

Cheers,
S.

---

From: Gary Gapinski <[email-masked]>
Date: Wed, 24 Apr 2019 09:51:28 -0400

On 4/12/19 7:28 PM, Christopher Wood
wrote:

I think the document should be published.

I agree with Martin Thomson's observation that the SP 800-52r2
quotes in Section 2 are a bit prolix considering the relatively
small content that would remain if excised, and that NIST document
has been in draft for a prolonged time (reducing its authority).
The quotes imply but do not demand disuse of TLS 1.0 and TLS 1.1,
and could inadvertently be interpreted to mean that use of TLS 1.2
rather than TLS 1.3 is sinful.

An additional (congenial) informative reference could be BSI
TR-02102-2 found at

https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html

which in §3.2 states "TLS 1.0 and TLS 1.1 are not recommended".

Regards,

Gary

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 24 Apr 2019 10:17:11 -0400

Thanks, Gary and others for the helpful feedback and support!  I like
Stephen can look at integrating the suggestions this weekend/early next
week.  Please do keep the comments coming.

Best regards,
Kathleen

On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski <gary=
[email-masked]> wrote:

> On 4/12/19 7:28 PM, Christopher Wood wrote:
>
> I agree with Martin Thomson's observation that the SP 800-52r2 quotes in
> Section 2 are a bit prolix considering the relatively small content that
> would remain if excised, and that NIST document has been in draft for a
> prolonged time (reducing its authority). The quotes imply but do not demand
> disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to
> mean that use of TLS 1.2 rather than TLS 1.3 is sinful.
>
> An additional (congenial) informative reference could be BSI TR-02102-2
> found at
>
>
> which in §3.2 states "TLS 1.0 and TLS 1.1 are *not recommended*".
>
> Regards,
>
> Gary

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Apr 2019 21:30:00 -0400

> On Apr 12, 2019, at 7:28 PM, Christopher Wood <[email-masked]> wrote:
> 

My concern is whether the time is yet nigh for TLS 1.0 to be disabled
in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
common to cause deprecation to do more harm than good via unnecessary
downgrades to cleartext.

I don't have survey numbers for SMTP TLS protocol versions across MTAs
generally to shed light on this, perhaps someone does.  What I do have
is numbers for those MTAs (not a representative sample) that have DANE
TLSA records (so presumably a greater focus on security).

The observed version frequencies are approximately:

	TLS 1.0:  1%
	TLS 1.1:  0%
	TLS 1.2: 87%
	TLS 1.3: 12%

essentially regardless of whether I deduplicate by name, IP or name and IP.
The respective sample sizes are 5435, 6938 and 7959.

So if a DANE-enabled sender were to disable TLS 1.0 today, approximately
1% of the destination MX hosts would be broken and need remediation.  These
handle just of 189 mostly small SOHO domains out of the ~1.1 million total
DANE SMTP domains, but four handle enough email to show up on the Gmail
SMTP transparency report:

  tu-darmstadt.de
  t-2.net
  t-2.com
  t-2.si

So on the whole, the draft should proceed, but some caution may be appropriate
outside the browser space, before operators start switching off TLS 1.0 support.

I don't see an operational considerations section.  Nor much discussion of
"less mainstream" (than Web browser) TLS application protocols.  Would a few
words of caution be appropriate, or is it expected that by the time the RFC
starts to change operator behaviour the "market share" of TLS 1.0 will be
substantially lower than I see today even with SMTP, XMPP, NTTP and the like.

[ I would speculate that TLS 1.0's share is noticeably higher among MTAs
  generally than among the bleeding-edge MTAs that have published DANE TLSA
  RRs. ]

-- 
	Viktor.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Apr 2019 21:48:20 -0400

I believe the doc is fine as it is.
Yours,
Daniel

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 26 Apr 2019 10:16:06 +0400

I also believe that it's ready.

On Fri, Apr 26, 2019 at 5:49 AM Daniel Migault
<[email-masked]> wrote:
> On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni <[email-masked]> wrote:
>>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 26 Apr 2019 17:07:32 +0200

I think it's fine as it is. This use case is very specific and the impact for 
it is limited. So yes, I think that the delay between publishing and now will 
change the situation even more out of favour of TLS 1.0.

On Friday, 26 April 2019 03:30:00 CEST Viktor Dukhovni wrote:
> So on the whole, the draft should proceed, but some caution may be
> appropriate outside the browser space, before operators start switching off
> TLS 1.0 support.
> 

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Töma Gavrichenkov <[email-masked]>
Date: Fri, 26 Apr 2019 18:14:21 +0300

Peace,

> change the situation even more out of favour of TLS 1.0.

Exactly my thought: polishing it further would hardly make the document
significantly better, taking in the account the delay necessary to do that.

--
Töma

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Apr 2019 15:24:35 +0000

If they haven’t already moved off TLS 1 then maybe this document will give the right people a push to do so.

Nobody is going to arrest an MTA for non compliance.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Apr 2019 17:28:39 -0400

> On Apr 26, 2019, at 11:24 AM, Salz, Rich <[email-masked]> wrote:
> 

Of course.

And as I said, I'd like to see the document move forward, I just
wanted to see whether there was any appetite for adding some
operator guidance.  It's not an issue of internet policing,
rather it is a question of whether there should advice for
operators who are considering disabling the legacy protocols.

The sound-bite version is: first raise the ceiling, *then* the floor.

The advice would therefore be for everyone to first make sure that
their systems support at least TLS 1.2, and not just the now deprecated
versions.  And then check whether the same holds true for their application
ecosystem and if so disable the protocols at that time.

In unauthenticated opportunistic TLS where cleartext is used when TLS
handshakes fail, removing support for TLS 1.0 can reduce security in the
short term (some messages needlessly going in cleartext).  Yes, this may
be what it takes to finally get the long tail procrastinators to upgrade.

The operational question then boils down to timing: when is your application
ecosystem ready to drop the training wheels.

Anyway, it does not look like there's much interest in adding operational
considerations, which users will then perhaps learn about elsewhere if
need be.  That's fine...

-- 
	Viktor.

---

From: Roland Zink <[email-masked]>
Date: Fri, 26 Apr 2019 23:55:36 +0200

This is of cause true. The MTA will not be arrested the question is if 
somebody will arrest the administrator or the owner. This will become 
part of the "push" the right people.

Regards,

Roland

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 28 Apr 2019 19:26:58 -0400

> The sound-bite version is: first raise the ceiling, *then* the floor.

Yep.  We've done the ceiling bit twice now.  Once in 2008 when we published TLS 1.2 and then in 2018 with the publication of TLS 1.3.  I'd say we're overdue for the floor bit.

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 29 Apr 2019 12:20:56 -0400

The WGLC is finished with no substantial blockers. We'll work with the authors in moving this document to the next stage in the process.

Thanks to everyone who reviewed and commented on this document. 

Best,
Chris, Joe, and Sean

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 29 Apr 2019 11:55:05 -0400

> On Apr 28, 2019, at 7:26 PM, Martin Thomson <[email-masked]> wrote:
> 

Agreed.  That comment was about the *operators* and application ecosystems,
not the TLS WG.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 May 2019 01:49:52 +0200 (CEST)

Martin Thomson <[email-masked]> wrote:
> Yep.  We've done the ceiling bit twice now.
> Once in 2008 when we published TLS 1.2 and then in 2018
> with the publication of TLS 1.3.  I'd say we're overdue for the floor bit.

Just that this rationale is a blatant lie.

It is formally provable that from the three protocol versions:

 TLSv1.0, TLSv1.1, TLSv1.2

the weakest one is TLSv1.2, because of the royally stupid downgrade
in the strength of digitally signed.

Disabling TLSv1.0 will only result in lots of interop failures
and pain, but no improvement in security.

-Martin

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 1 May 2019 03:35:00 +0300

On Wed, May 1, 2019 at 2:50 AM Martin Rex <[email-masked]> wrote:
> It is formally provable

Everything must be accounted for as provable until it's proved unless
it's proved to be false.

Do you possess an external (academic?) reference?

--
Töma