On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins <nalini.elk...@e-dco.com>

> 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.


[0] https://www.imperialviolet.org/2018/03/10/tls13.html
TLS mailing list

Reply via email to