Hi Eric, The author probably refers to a case where an infosec dept of an enterprise will not just disable TLSv1.3 on the servers, but will also set up some deep-juju DPI for filtering v1.3 in transit to make sure no one will enable v1.3 accidentally somewhere.
As those DPI solutions are often of questionable reliability, that may affect other transit users of that network. вт, 13 мар. 2018 г., 13:24 Eric Rescorla <e...@rtfm.com>: > On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins <nalini.elk...@e-dco.com> > wrote: > >> Stephen (and TLS group) >> >> We need to look at the bigger picture. >> >> The TLS working group has been concentrating on making the Internet >> secure for the individual user. We feel that there is also an underlying >> motivation to help the underdog and protect the political dissident. These >> are all laudable goals. >> >> But, the Internet is much more than that. The Internet is the >> underpinnings of much of the business community which is utilized by >> consumers (end users). Making a change which makes businesses less secure >> because crucial functions cannot be done will lead to enormous chaos and >> disruption. Many businesses are likely to not want to adopt TLS1.3 or >> seek unique DIY type alternatives. In fact, we have already heard of some >> planning to block TLS 1.3 traffic just for this reason. >> > > As a break from the meta-discussion about whether this topic should be > on the agenda, I'd like to make a technical point. There are two > separate settings where TLS 1.3 makes inspection more difficult: > > 1. Cases where the inspecting entity controls the server and does > passive inspection: TLS 1.3 mandates PFS and so designs > which involve having a copy of the server's RSA key won't work > > 2. Cases where the inspecting entity controls the client and does > MITM: TLS 1.3 encrypts the certificate and so conditional > inspection based on the server cert doesn't work (though see [0] > for some of the reasons this is problematic.) > > The two drafts under discussion here only apply to case #1 and not to > case #2. However, for case #1, because you control the server, there's > no need to look at blocking TLS 1.3, you merely need to not enable it > on your server, so this framing is a bit confusing. > > > -Ekr > > [0] https://www.imperialviolet.org/2018/03/10/tls13.html > > > > _______________________________________________ > 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
