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
