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 
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.
TLS mailing list