Re: [Patient] DOJ first on encryption services

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 <+34%20913%2012%2090%2041>
>
> Mobile:  +34 682 051 091 <+34%20682%2005%2010%2091>
>
> ----------------------------------
>
> 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
>