Subject: Re: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

From: Sean Turner <[email-masked]>
Date: Fri, 2 Oct 2020 13:44:18 -0400

> On Sep 23, 2020, at 08:43, Sean Turner <[email-masked]> wrote:
> 
> Hi! this issue was buried in the Ben’s review, but I think it is worth getting some attention on.
> 
>> On Aug 13, 2020, at 13:54, Benjamin Kaduk <[email-masked]> wrote:
>> 
>> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
>>> 
>>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk <[email-masked]> wrote:
>>>> 
>>>> - Similarly, the downgrade protection provided by the SCSV of RFC 7507
>>>> seems to be entirely obsolete.  Any implementation that is compliant
>>>> with this document will support only 1.2 or higher.  If it only
>>>> supports one version, no downgrade is possible; if it also supports
>>>> 1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
>>>> applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
>>>> We could effectuate that status change in this document as well.
>>>> 
>>> 
>>> Has this been addressed in RFC8446?  If not, the specific downgrade
>>> examples are just listed as examples.  If a gap is left, then the full
>>> document should not be deprecated and made obsolete.  The text infers other
>>> versions in my read.  I have not looked to see if this was addressed in
>>> RFC8446 yet though.
>> 
>> I'd really like to get a few more people to weigh in on this one -- IIRC
>> David Benjamin and Martin Thomson had mentioned some thoughts in the chat
>> during the session at 108, and Ekr as author of 8446 would be expected to
>> have a good sense of what it does.  
>> 
>> The specific RFC 8446 mechanism here is described at
>> https://tools.ietf.org/html/rfc8446#section-4.1.3 : "TLS 1.3 has a
>> downgrade protection mechanism embedded in the server's random value.
>> [...]"
>> 
>> While the RFC 8446 mechanism has the client do the actual detection of
>> downgrade, there's a MUST-level requirement on clients to make the check,
>> so from a specification point of view the check can be treated as reliable.
>> The RFC 7507 mechanism has the server do the detection, but I think the end
>> result is still the same: in an "downgraded" exchange between two honest
>> participants, the handshake fails and the downgrade is detected.
>> 
>> Since the functionality is still useful, just superseded, this one seems
>> like a better fit for "obsoletes" (vs. "historic).
>> 
> 
> Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate will update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks" (https://datatracker.ietf.org/doc/rfc7507/) is in this list. If you agree with Ben’s logic then we would be move 7507 out of the list of “updates” and adding an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, and moving 7507 down in s1.1 to the obsoletes paragraph. While this might seem like a minor point, this is the kind of the IESG loves to sink its teeth into so have a WG opinion on this matter can make overcoming later hurdles easier for the AD and doc shepherd.
> 
> Thanks for the your time,
> 
> spt (doc shepherd)

All I have gone ahead and submitted a PR to address the point raised by Ben:
https://github.com/tlswg/oldversions-deprecate/pull/4

spt

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 2 Oct 2020 22:11:06 +0400

Please go ahead. I remembered a discussion (outside of the ietf) where
not everybody agreed
with it but reluctantly implemented it.

On Fri, Oct 2, 2020 at 9:44 PM Sean Turner <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 2 Oct 2020 22:15:28 +0400

> with it but reluctantly implemented it.

Found the commit message in LibreSSL:

"

Reluctantly add server-side support for TLS_FALLBACK_SCSV.

   This allows for clients that willingly choose to perform a downgrade and
   attempt to establish a second connection at a lower protocol after the
   previous attempt unexpectedly failed, to be notified and have the second
   connection aborted, if the server does in fact support a higher protocol.

   TLS has perfectly good version negotiation and client-side fallback is
   dangerous. Despite this, in order to maintain maximum compatability with
   broken web servers, most mainstream browsers implement this.

"

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Oct 2020 13:02:07 -0400

Ben,

Thanks for pointing out I missed a couple. Inline …

spt

> Hi Kathleen,
> Also inline.
>> Hi Ben,
>> Thanks for your review.  Some initial responses are inline.
>> 
>>> I found three documents (3656, 4540, 7562) in the list of update targets
>>> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
>>> preliminary review, and in principle it is permissible to make those
>>> updates as part of this document, but we will need specific ISE approval
>>> to do so.  I am supposed to sync up with him during IETF LC, but the
>>> document needs to be updated to clarify that the updates of ISE
>>> documents are/will be done with permission of the ISE.  (Please also try
>>> to double-check that the list is complete; I didn't find an
>>> authoritative list of "all documents on the ISE stream" to grep against,
>>> and I didn't try to have something parse rfc-index.xml to output such a
>>> list.
>>> 
>> 
>> OK, so you'd like a list added and that's not in your pull request, is that
>> right?  We'll figure it out. Thanks in advance with the coordination with
>> Adrian.
> 
> That's correct, this is not in my pull request (not least because that list
> of three documents is incomplete -- I sent a more-likely-complete list of 6
> documents in an off-list follow-up.
> https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent&page=All
> will get a (presumably authoritative) list of ISE-stream documents, FWIW.

After going through the list I found six. Here’s some text that addresses the fact that will have permission from the ISE:
https://github.com/tlswg/oldversions-deprecate/pull/6

>>> Section 1.1
>>> 
>>> I went through all 83 of the references in the big list, that are
>>> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
>>> as well as the shorter list of already-obsoleted documents.
>>> 
>>> I won't bore you with my full notes, but there are some particular
>>> things that stood out from the review:
>>> 
>>> - We have a separate list of updates for documents that are already
>>>  obsolete (but don't say much about why we're going go the extra
>>>  bother).  However, three of the documents in our main list of updates
>>>  (4743, 4744, and 6460) are already Historic, and presumably should be
>>>  treated more like the already-obsolete ones.
>>> 
>> 
>> Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
>> been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
>> extra step to say not to use it and it triggers many to begin phase out
>> plans.  Am I misunderstanding the question?
> 
> I think you're misunderstanding the question, yes, sorry.
> 
> I think we want the documents that are Historic to be listed separately
> from the other ("regular") updates, in a manner akin to what is already
> done for the documents that are currently obsolete.  Or, perhaps, to say
> that there is no point in deprecating something that is already historic,
> and not bother updating those three documents, but it seems okay to keep
> the current status with a comprehensive list of updates.

How about this:
https://github.com/tlswg/oldversions-deprecate/pull/7

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2020 11:34:20 -0700

Thanks, Sean, the linked pull requests seem to do the trick.

Skimming through
https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ once
more, I think I still plan to put out a status-change document to move RFC
5469 (IDEA and DES ciphers) to Historic in parallel with the IETF LC for
this document.  It is probably not critical that we mention such a change
in the document text, though we could if we want to.

I think we still need to check for the latest version of the SP800-52r2
reference, too.

Thanks again,

Ben

---

From: "Michael D'Errico" <[email-masked]>
Date: Tue, 13 Oct 2020 15:09:15 -0400

I know that saying this will have no effect, but I'd
rather see deprecation of just TLS 1.0 and retain
version 1.1 as not recommended.

Also, we should not abandon RFC 7507 (downgrade
protection SCSV).  What harm is there in keeping it
around?  None.

Mike

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2020 12:15:12 -0700

Hi Mike,

> version 1.1 as not recommended.

Saying that it's your preference without saying why is likely to have
little effect, yes.  (We endeavor to make decisions based on technical
merit, not voting, after all.)  Why do you want this?  TLS 1.1 seems to
have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2
(let alone 1.3) in terms of design and safety.

> protection SCSV).  What harm is there in keeping it

I don't expect implementations to abandon SCSV any faster than they abandon
TLS 1.0 or 1.1.  But if the official advice is that 1.0 and 1.1 are
obsolete, then the official advice should also be that SCSV is obsolete --
its function is performed in a different way by the newer versions of TLS.

-Ben

---

From: "Michael D'Errico" <[email-masked]>
Date: Tue, 13 Oct 2020 15:59:27 -0400

> Saying that it's your preference without saying why is likely
> to have little effect, yes.  (We endeavor to make decisions
> based on technical merit, not voting, after all.)  Why do you
> want this?

Hi,

I think the advice should be: "If your code currently
only supports TLS 1.0, please spend a week or two
adding support for both TLS 1.1 and the downgrade
protection SCSV."

Since the vast majority of the 1.0 and 1.1 specifications
is the same, someone who takes the advice has a
good chance of succeeding.

(You could then also say which other extensions are
important and why, roughly in order of importance.)

Recommending that people wholesale abandon
their legacy system and implement TLS (1.2 and)
1.3 is asking too much, and will largely be ignored
by the people who would be able to add 1.1 to their
1.0 code.

I understand that we don't vote here.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Oct 2020 21:08:54 +0000

The folks you have to convince isn't just the IETF, but rather groups like the payment card industry (PCI-DSS), and NIST which deprecated 1.0 and 1.1 before the IETF did.  No doubt there are others.  And then you have to convince the browsers.

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Oct 2020 20:44:42 -0400

> On Oct 13, 2020, at 14:34, Benjamin Kaduk <[email-masked]> wrote:
> 

You are correct - the date should be August 2019:
https://github.com/tlswg/oldversions-deprecate/pull/8

spt

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Oct 2020 20:24:07 -0700

Hi Mike,

> important and why, roughly in order of importance.)

I don't see much to object to in that advice, but the precondition is
rather limiting.  Have you considered writing a draft that covers it
(including fleshing out the important extensions)?

> by the people who would be able to add 1.1 to their

It may be true that such recommendations will largely be ignored by people
who have 1.0-only implementations (recall that the IETF does not have an
enforcement arm!), but draft-ietf-tls-oldversions-deprecate aims to be a
Best Current Practice, and there are not preconditions to that Best.  The
Best thing you can do for TLS involves TLS 1.3, and TLS 1.2 is probably
okay, too.  I don't see anyone arguing that the Best Curent Practice for
TLS, in general, involves TLS 1.0 or 1.1, at this point.

-Ben