Nice requirements. Will those be applied to all protocols around TLS?
For example HTML/HTTP/QUIC tend to send data to third parties through
additional connections and the HTTP referer header tells all those 3rd
parties the URL used. This is a breach of the users privacy. For
surveillance no wiretapping is necessary. A secret service just needs to
infiltrate a few big companies and will get a pretty good overview who
browse what. The user didn't explicitly opt-in into this although you
may argue the client software (browser) does. A third party can't tell
if this feature is enabled or not by observing the stream. So should the
usage of HTTP/HTTP2/QUIC over (D)TLS in the current form be forbidden?
The referer header not allowed when TLS is used?
As a server (and client) can always silently forward the unencrypted
data neither 1) nor 2) can be enforced so I guess those are only should
requirements.
Roland
Am 08.07.2017 um 23:16 schrieb Nick Sullivan:
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 <matthewdgr...@gmail.com
<mailto:matthewdgr...@gmail.com>> 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
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
