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

Shumon Huque <> Sat, 08 July 2017 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A0D0129AAA for <>; Sat, 8 Jul 2017 15:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S_bbg07qpAGf for <>; Sat, 8 Jul 2017 15:14:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF90C126E64 for <>; Sat, 8 Jul 2017 15:14:48 -0700 (PDT)
Received: by with SMTP id r126so32666864vkg.0 for <>; Sat, 08 Jul 2017 15:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4HYJpwia55WFLHfs4tsSpvjPxAAZ1Elu4zHSLCRj3/w=; b=VA6wTnc73lG/ouxMFdS+p/ojcMqVBpTj1Lf8Y2ncEHir2zGJkWqP3+UtYjvPSQTLuD m9w8JGsTSSHSZ8rnBBdDA/EofbglhIV066W7ik3tv79CwTNO9N1Sk1L+5XIuafISPgiR UGe5engXlRxdLylZ8Oq7750i7LXjx8wawz60EED3XSwzjqupUWQoEZhcHMRJ//W4OCIi EBVzY07vzAPuSRPJqYTqgnPM6wWRUwSNVHGLNI9Rn4f8UDUiOzRwMQiV+wIYmvHUWP1+ eiD+/xKvWNQNnWay8gleq1GwdDEh3MrVXZcwcNA8HQoxYtrJHNQpDEm4KdpNeqsXpwyD JUYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4HYJpwia55WFLHfs4tsSpvjPxAAZ1Elu4zHSLCRj3/w=; b=KZREX6yna80FPSheToPCoDsnKeb5DxZw6PPbyPf4edN1eMqGFhYoUpnBl+5TdqQ8Mu T/G+cIxBdnDFW4GojnMPoC/MY5wEEJriYkTrp8ZA3/9fci1IXxay0zo4rnQi42O9uU05 jHBh92Bkl7yVe8o1yiFFX9c2psrEiz3HNAwfO1Gknmd8GdQZQFvqV9GceT8JoT58xvC5 ZjK4oib+3+9OaUhTQDvj1JiuAd/BzwOPHw8F+ZE+gMf8J33obqV1tKQBuMaxEP7ihi+q C/d5hCXkBJOJSMl5KQ0jPJM/wvkJQvMiRtzgij7ptk5VGWPguKr8kJ3mY3qD4ys0GL+f hdHQ==
X-Gm-Message-State: AIVw113Y5+5Y5Gm/ab4dsWnW1Wp3gn44WX/QijRDQxEDEQitXDLMFbjG JHYxGk0eWZIVro/l2CsfNcZdSKgoHw==
X-Received: by with SMTP id g3mr4080593vkh.91.1499552087793; Sat, 08 Jul 2017 15:14:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 8 Jul 2017 15:14:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Shumon Huque <>
Date: Sat, 8 Jul 2017 18:14:46 -0400
Message-ID: <>
To: Nick Sullivan <>
Cc: Matthew Green <>, TLS WG <>
Content-Type: multipart/alternative; boundary="94eb2c0949e883e8850553d5ad60"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Jul 2017 22:14:50 -0000

On Sat, Jul 8, 2017 at 5:16 PM, 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.

I absolutely agree.

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.

This is the best proposal I've seen so far.

What is the problem of publishing a scheme like this as an Informational
RFC? After all, we can cite many examples of protocols described in
Informational RFCs that are widely deployed by industry. If the proponents
of this draft think it critical that this needs formal IETF endorsement as
a standard, then I believe they ought to be also working on persuading the
IETF to withdraw or at least backtrack on some of our previous statements
(such as RFC 7258, which declared that IETF protocols need to have
technical countermeasures to prevent pervasive monitoring).

I doubt that we will be able to get consensus on IETF endorsement. Speaking
only for myself, I am against the IETF/TLS wg endorsing a protocol that
degrades the security of the TLS protocol. But I am perfectly fine with
publishing it as Informational document.

Shumon Huque