Re: [Patient] DOJ first on encryption services

Ekr,

How does the encrypted SNI work fit in to this holistically?  

Bret

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Mar 18, 2018, at 12:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>> On Sun, Mar 18, 2018 at 12:51 PM, Diego R. Lopez <diego.r.lopez@telefonica.com> wrote:
>> Hmmm… The SNI would be a much weaker evidence than the server certificate, wouldn’t it?
>> 
> 
> This comes up a lot, but no. The basic issue is that there are two types of clients
> 
> 1. You have an ordinary client (e.g., a Web client)
> 2. You have a client which was really written by the attacker.
> 
> In the former case, SNI will appear and the client will enforce that the certificate and SNI match up, so you don't need the certificate. In the latter case, the client can of course lie about SNI, but then you can also just apparently do TLS 1.2 but actually encrypt the plaintext with some key that's been externally arranged, while generating a valid TLS 1.2 transcript. So, in neither case does the certificate really help.
> 
> Adam Langley did a good job of explaining this in more detail:
> https://www.imperialviolet.org/2018/03/10/tls13.html
> 
> -Ekr
> 
>>  
>> 
>> --
>> 
>> "Esta vez no fallaremos, Doctor Infierno"
>> 
>>  
>> 
>> Dr Diego R. Lopez
>> 
>> Telefonica I+D
>> 
>> https://www.linkedin.com/in/dr2lopez/ 
>> 
>>  
>> 
>> e-mail: diego.r.lopez@telefonica.com
>> 
>> Tel:         +34 913 129 041
>> 
>> Mobile:  +34 682 051 091
>> 
>> ----------------------------------
>> 
>> On 18/03/2018, 12:46, "Eric Rescorla" <ekr@rtfm.com> 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-against-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
>> 
>>  
>> 
>> 
>> 
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>> 
>> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>> 
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> 
> _______________________________________________
> PATIENT mailing list
> PATIENT@ietf.org
> https://www.ietf.org/mailman/listinfo/patient