> On 13 Mar 2018, at 17:23, Eric Rescorla <e...@rtfm.com> wrote:
>> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

TLS mailing list

Reply via email to