I am completely indifferent on Updates versus Obsoletes (Indeed, this discussion seems like more support for my argument that we should get rid of the distinction). With that said, I believe that this analysis is broadly correct.
To recap the situation as I understand it: TLS always provided anti-version downgrade defenses because the Finished message covers the version negotiation [0]. However, the version fallback mechanism involved generating a new handshake without the (potentially) incompatible version, thus was not subject to the Finished check. The SCSV was an anti-downgrade mechanism (essentially a version signal) which could be sent in the new handshake, thus being subject to the Finished check. TLS 1.3 provides an alternate mechanism for the case where the server speaks TLS 1.3 but the client/server pair negotiate < 1.3. Thus, in the world where the only valid values of TLS are 1.2 and 1.3+, then this mechanism should render the SCSV unnecessary. -Ekr On Wed, Sep 23, 2020 at 5:43 AM Sean Turner <s...@sn3rd.com> 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 <ka...@mit.edu> 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 <ka...@mit.edu> 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) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
