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

[Sean Turner <[e-mail]>]

> On Sep 23, 2020, at 08:43, Sean Turner <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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