Subject: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Mar 2018 08:48:13 +0000

On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley <[email-masked]> wrote:
> Nick Sullivan summarized
> four concerns with that approach.  See
> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>
> draft-rhrd-... addresses all four of these concerns.

This isn't quite right.  One of the goals Nick outlined was
"Decryption service only gets session keys, not master secret".  The
current design causes them to gain the handshake secrets, from which
it is trivial to derive the master secret and other secrets [1].  This
includes the resumption master secret and exporter secret.

So aside from enabling MitM, this also enables session resumption by
the decryption service, something that the security considerations
neglects to include in its list.  What, if anything, can be done with
the exporter secret will need more thought.

[1] draft-rescorla-tls13-semistatic-dh-00 and its OPTLS-based
insertion of another DH exchange would prevent the decryption service
from working for anything other than the handshake and 0-RTT.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Mar 2018 13:42:22 +0000

the decryption service, something that the security considerations
    neglects to include in its list.

So I think this is an important point.  I assume the authors did not realize this. That shows how hard, and risky, it is to get this right.  In the US, we have been having arguments where the national police force (FBI) is insisting that tech companies can create a "golden key" that only they can use, and the security people are saying it is impossible.  This seems like another instance, no?

Oh heck, let me ask the uncomfortable question:  Russ, did you know this or was Martin's point new to you?

	/r$

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Mar 2018 15:25:39 -0400

> On Mar 14, 2018, at 4:48 AM, Martin Thomson <[email-masked]> wrote:
> 

You are right.  It would be a significant improvement to narrow the portions of the key schedule that are shared.

To avoid the issue with resumption that you raise, is seems that these entries in the key schedule are needed:
	client_early_traffic_secret
	client_handshake_traffic_secret
	server_handshake_traffic_secret
	client_application_traffic_secret_0
	server_application_traffic_secret_0

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Mar 2018 15:28:39 -0400

> On Mar 14, 2018, at 9:42 AM, Salz, Rich <[email-masked]> wrote:
> 
> 

I think my reply to Martin already sows that I missed the point about resumption.  I was trying to send the smallest amount of data, I should have made sure the things needed for resumption were not included.

Russ

---

From: Hot Middlebox <[email-masked]>
Date: Wed, 14 Mar 2018 18:08:44 -0400

The requirements for visibility exist in an array of regulated environments
worldwide.  It is one of the presentation areas in the Hot Middlebox
Workshop.
http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1

The Middlebox Hackathon site is also now public so everyone can
experience how a browser plug-in client (to be provided) can be used in
conjunction with a fine grained Middlebox Security Protocol for Middlebox
discovery and controlled visibility by an end-user in a way that meets both
user and regulatory interests.  The draft specification will be published
in two weeks.

--the Hot Middlebox organizers

On Wed, Mar 14, 2018 at 9:42 AM, Salz, Rich <[email-masked]> wrote:

> So I think this is an important point.  I assume the authors did not
> realize this. That shows how hard, and risky, it is to get this right.  In
> the US, we have been having arguments where the national police force (FBI)
> is insisting that tech companies can create a "golden key" that only they
> can use, and the security people are saying it is impossible.  This seems
> like another instance, no?
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Mar 2018 22:17:59 +0000

*   The requirements for visibility exist in an array of regulated environments worldwide.  It is one of the presentation areas in the Hot Middlebox Workshop.  http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.etsi.org_etsi-2Dsecurity-2Dweek-2D2018_middlebox-2Dsecurity-3Ftab-3D1&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Yz_0b8nsA9CDyOxIGLCsjdmfsbcx2aanAH-oeuvMpkk&s=NW0inE5_1gzb4brUZGMm47dZyrYtkYXtAXf7Ii6S8kk&e=>

Do you know if they require packet traces to be decoded, or if one of the nodes can just log the traffic?  Do they require this to be true for traffic over the public Internet or just within an enterprise?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Mar 2018 22:21:15 +0000

Hi Rich (and Tony Rutkowski == hot_middlebox I assume?)

> Do you know if they require packet traces to be decoded, or if one of the nodes can just log the traffic?  Do they require this to be true for traffic over the public Internet or just within an ent…

I see no content at that URL. This seems to be another case of
claiming regulations exist but yet again being unable to point
to any such regulation that others can read. (And yes, we did
this before for PCI-DSS so let's not repeat that if there's no
new information offered.)

S.

---

From: Sean Turner <[email-masked]>
Date: Thu, 15 Mar 2018 11:24:06 +0000

I have placed this poster in the moderator queue based on RFC2418: Participation is by individual technical contributors, rather than by formal representatives of organizations [0].  They can rejoin using a personal account or identify who they are in their email’s signature.

spt

[0] https://tools.ietf.org/rfcmarkup?doc=2418#section-1

> Begin forwarded message:
> 
> From: Hot Middlebox <[email-masked]>
> Subject: Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)
> Date: March 14, 2018 at 22:08:44 GMT
> To: "Salz, Rich" <[email-masked]>
> Cc: IETF TLS <[email-masked]>
> 
> The requirements for visibility exist in an array of regulated environments worldwide.  It is one of the presentation areas in the Hot Middlebox Workshop.  http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1 <http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1>
> 
> The Middlebox Hackathon site is also now public so everyone can experience how a browser plug-in client (to be provided) can be used in conjunction with a fine grained Middlebox Security Protocol for Middlebox discovery and controlled visibility by an end-user in a way that meets both user and regulatory interests.  The draft specification will be published in two weeks.
> 
> On Wed, Mar 14, 2018 at 9:42 AM, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>