Re: [Patient] DOJ first on encryption services

On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony@yaanatech.co.uk>
wrote:

> Your point is one that deserves further discussion, Eric - which seems
> likely to scale rapidly going forward.  It is key.
>
> So how does draft-ietf-tls-sni-encryption it into the argument?
>

As you suggest, SNI encryption is intended to conceal the SNI, which of
course would make SNI inspection difficult.

My evaluation of the current state of SNI encryption is that given the
current technical state, it will not see particularly wide deployment, with
the primary scenario being "at-risk" sites who are subject to censorship
who either hide behind or co-tenant with sites which are not subject to
censorship. That probably isn't going to be incredibly common right now. Of
course, this is regrettable from the perspective of people designing these
protocols, but I think that's the situation.

-Ekr

On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>
> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony@yaanatech.co.uk>
> wrote:
>
>> Hi Diego,
>>
>> It is also worth referencing a relatively recent Lawfare article on the
>> scaling litigation in the U.S. against those supporting e2e encryption
>> services or capabilities.
>> https://www.lawfareblog.com/did-congress-immunize-twitter-ag
>> ainst-lawsuits-supporting-isis
>>
>> This litigation trend is also likely to increase the insurance costs of
>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may
>> not even be able to get insurance.  It may be fun and games to play crypto
>> rebel in venues like the IETF where the risk exposure is minimal, but when
>> it comes to real world consequences and costs, the equations for providers
>> are rather different.
>
>
> I think this rather overestimates the degree to which both TLS 1.3 and
> QUIC change the equation about what a provider is able to determine from
> traffic inspection. As a practical matter, the primary change from TLS 1.2
> is that the provider does not get to see the server's certificate, but it
> does see the SNI. Given that the SNI contains the identity of the server
> that the client is connected to and that the other identities in the
> certificate are often whatever the provider decided to co-locate on the
> same machine, I'm not sure how much information you are really losing.
>
> -Ekr
>
>
>>
>>
>> --tony
>>
>>
>> _______________________________________________
>> PATIENT mailing list
>> PATIENT@ietf.org
>> https://www.ietf.org/mailman/listinfo/patient
>>
>
>
>
> _______________________________________________
> PATIENT mailing listPATIENT@ietf.orghttps://www.ietf.org/mailman/listinfo/patient
>
>
>