On Fri, Oct 2, 2020 at 10:11 PM Loganaden Velvindron <logana...@gmail.com> wrote: > > Please go ahead. I remembered a discussion (outside of the ietf) where > not everybody agreed > 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. " > On Fri, Oct 2, 2020 at 9:44 PM Sean Turner <s...@sn3rd.com> wrote: > > > > > > > > > On Sep 23, 2020, at 08:43, 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) > > > > 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 > > _______________________________________________ > > 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
