Subject: [Patient] DOJ first on encryption services

From: Tony Rutkowski <[email-masked]>
Date: Sun, 18 Mar 2018 07:20:04 -0400

Hi Brian,

https://www.justice.gov/usao-sdca/pr/chief-executive-and-four-associates-indicted-conspiring-global-drug-trafficker

This action announced on Thursday by the US Attorney's office is a 
first.  It suggests the US Feds will be going after companies who cater 
to the wrong customers with encryption services.

It seems likely that most countries, providers, and enterprises will 
simply block or degrade TLS 1.3, QUIC, and other pervasive encryption 
protocols. However, there will always be outliers who will take the risk.

This DOJ action (and likely clones elsewhere in the world) adds some 
greater risk to the equation when the provider fails to undertake due 
diligence on the uses being undertaken by the customers running TLS 1.3 
and QUIC servers.  Where the customer is using the technology to evade 
law enforcement, including DCMA strictures, the provider may find 
themselves complicit through criminal or civil proceedings.

--tony

ps. They probably will not come after those developing the standards, 
but then the IESG probably has sufficient liability insurance courtesy 
of ISOC to handle litigation costs and fines.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 18 Mar 2018 11:25:16 +0000

Hi Tony,

The link seems not to work... Can you check it?

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------
On 18/03/2018, 11:20, "PATIENT on behalf of Tony Rutkowski" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Brian,

    --tony

    _______________________________________________
    PATIENT mailing list
    [email-masked]
    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

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 18 Mar 2018 08:11:20 -0400

https://www.justice.gov/opa/pr/chief-executive-and-four-associates-indicted-conspiring-global-drug-traffickers-providing

Sorry.  It was truncated.  In addition, DCMA should be DMCA.  The recent 
4th Circuit opinion in BMG v. Cox on that compliance obligation also 
raised the risk for non-compliance.  A jury awarded a $25 million fine.  
Those amounts tend to alter risk equations for ISPs and data centre 
hosting providers.  See http://www.ca4.uscourts.gov/opinions/161972.P.pdf

-t

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 18 Mar 2018 08:30:30 -0400

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.

--tony

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 12:45:48 +0000

On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <[email-masked]>
wrote:

> 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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 18 Mar 2018 12:51:02 +0000

Hmmm… The SNI would be a much weaker evidence than the server certificate, wouldn’t it?

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------
On 18/03/2018, 12:46, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/patient

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 18 Mar 2018 08:54:41 -0400

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?

-t

On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>     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
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/patient>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 12:54:21 +0000

> Hmmm… The SNI would be a much weaker evidence than the server certificate,

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

> 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" <[email-masked]> wrote:
>
>
>
> 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
>
>
>
> ------------------------------
>
> 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
>

---

From: Bret Jordan <[email-masked]>
Date: Sun, 18 Mar 2018 13:04:27 +0000

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 <[email-masked]> wrote:
> 
>> On Sun, Mar 18, 2018 at 12:51 PM, Diego R. Lopez <[email-masked]> wrote:
> This comes up a lot, but no. The basic issue is that there are two types of clients
> 
> 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.
> 
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <[email-masked]> wrote:
>> 
>> Hi Diego,
>> 
>> 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
>> 
>> 
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 13:06:58 +0000

> 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:
> PATIENT mailing [email-masked]://www.ietf.org/mailman/listinfo/patient
>
>
>