Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Nick Sullivan <[e-mail]>]

Putting questions of whether or not this belongs as a working group
document, I think there are some necessary requirements for
intra-datacenter passive decryption schemes that are not met by this draft.

Specifically, any passive decryption scheme should the following two
properties:
1) Both server and client must explicitly opt-in
2) A third party should be able to tell whether or not this feature is
enabled by observing the stream

These two requirements protect services on the wider Internet from being
accidentally (or surreptitiously forced to be) subject to unauthorized
decryption. The static DH proposal satisfies neither of the above
requirements.

What you likely want is something similar to TLS 1.2 session tickets with
centrally managed session ticket keys. The client would advertise support
for "passive session decryption" in an extension and the server would
return an unencrypted extension containing the session keys encrypted by a
server "passive decryption key". The passive decryption key would be
managed in the same way as the static DH key in this draft: rotated
frequently and synchronized centrally.

A TLS 1.2 session ticket-like scheme provides the same semantics as this
static DH but provides more safeguards against accidental use outside the
datacenter. Both client and server need to opt in, it's visible from the
network, and limits the data visible to the inspection service to the
session (rather than exposing the master secret which can be used to
compute exporters and other things outside of the scope of session
inspection). Furthermore, in the session ticket-like scheme, a *public
key *could
be used to encrypt the session keys, removing the need for a secure
distribution scheme for the endpoints. The passive decryption private key
could me managed in a secure location and only the public key distributed
to the endpoints.

Session ticket-like scheme advantages vs this static DH proposal:
1) Mandatory client opt-in
2) Passive indication that scheme is being used
3) Decryption service only gets session keys, not master secret
4) No need for private distribution system for static keys to endpoints

In summary, even if this was to be considered as a working group document,
I think this is the wrong solution to problem.

Nick

On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <[e-mail]>
wrote:

> The need for enterprise datacenters to access TLS 1.3 plaintext for
> security and operational requirements has been under discussion since
> shortly before the Seoul IETF meeting. This draft provides current thinking
> about the way to facilitate plain text access based on the use of static
> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
> on a regular schedule. A key manager in the datacenter generates and
> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
> used to transfer and load the keys wherever they are authorized for use.
>
> We have asked for a few minutes to talk about this draft in the TLS WG
> session at the upcoming Prague IETF. Please take a look so we can have a
> productive discussion.  Of course, we're eager to start that discussion on
> the mail list in advance of the meeting.
>
> The draft can be found here:
>
> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>
> Thanks for your attention,
> Matt, Ralph, Paul, Steve, and Russ
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>