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

Richard Barnes <> Sat, 08 July 2017 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D53D126C83 for <>; Sat, 8 Jul 2017 10:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 y3qlnVCBDjop for <>; Sat, 8 Jul 2017 10:30:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3766129B04 for <>; Sat, 8 Jul 2017 10:30:37 -0700 (PDT)
Received: by with SMTP id c11so86055879wrc.3 for <>; Sat, 08 Jul 2017 10:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VbfXo/G2fHxKT6Oi7WT5KLm06Wd8cfKp7F1rPk5BIho=; b=QYUdR1OKMmMwA74zoLxizIGw8u9xMCdyMjKQepY5Grj2iVhZkRIij/G116pBithn0H r+zphZcQMxu6/aV78gfBnGpsClIKXEnqCDewL0PrspzJI6kEGAjW3v5qhA64l/5fGzAs ihTeo26VJm+VJOFAjQSsGPd4dyOv6G2rVYrmmSedbt8NQ2K3cy5J8JY10vFhHOlXMfQv 153S4WBPGIxmZ1tRtc34Wx/wPEy1qjQT6D7ubYMm1gWruApjvcEWyMkJBsu0JBNmeROE 8DeWSAeySNpZP9XDiWBnWMAl/w/vObvMmPsMs+KVlpeimud5CsukV9l7yjLU16J6VhwV NpBg==
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=VbfXo/G2fHxKT6Oi7WT5KLm06Wd8cfKp7F1rPk5BIho=; b=lnmmrWGeW3fUUl4tS0sAhqy7Tx6b9T0FqexSZahZECYxI1ipWZ4PYIipwNhUbMlI53 GH5EnsxSQjzRBrC81ZAe0QczwyOtDW952d7Jg6aMzcnU3k3/+2psey3rtT8G19R3WAvv Mjyf6gvo5pCjMcsX7qXpYBg1r1TrMYzY52OjmhKZ3TKO3LOW4QSGSiztBsI34Ch/u15b XG/vOv5Z+QVAFxtbWE/CbZwfz/QpIC8t8W8WJh9PT1m7WuWiJi1s9T8UeGtor7pIhgJi 5V82yXMn001tZYWfra68bi/iXrDqhw15vI3ncsH2Ww1Qf2kgkVrRpLxXiw9v67E/ckPF Y8lg==
X-Gm-Message-State: AIVw110z3Y3gqOHxgTZgicRmG5DVYu5ifOKQ5fAeQUeU55fXZPNO3td2 h5L70DlmW2IcqzWBRN8bCF+KYkZgxRUA
X-Received: by with SMTP id x105mr3716739wrb.18.1499535036061; Sat, 08 Jul 2017 10:30:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 8 Jul 2017 10:30:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Richard Barnes <>
Date: Sat, 8 Jul 2017 13:30:35 -0400
Message-ID: <>
To: Tony Arcieri <>
Cc: Matthew Green <>, "<>" <>
Content-Type: multipart/alternative; boundary="f403045d573227303e0553d1b5d9"
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 17:30:41 -0000

On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri <> wrote:

> On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <> wrote:
>> You could avoid changing how the DH works altogether by simply exporting
>> the DH private key, encrypted with a key shared with the monitoring device,
>> in a server extension.  (Not in EncryptedExtensions, obviously.)  This
>> would also have the benefit of explicitly signaling when such monitoring is
>> in use.  The only real challenge here is that the client would have to
>> offer the extension in order for the server to be able to send it, which I
>> expect things like browsers would be unlikely to do.  However, given that
>> the target of this draft seems to be intra-data-center TLS, perhaps this is
>> a workable requirement?
> I very much like the property that by using an extension, the client must
> consent to being MitMed.
> But in this case, why not just keywrap the session master secret with a
> preshared KEK as opposed to exfiltrating the DH private key?

Actually, now that you mention it, something like that is probably
necessary -- I expect that there are unstated requirements here to support
for resumption (without having to find the previous session) and probably
0xRTT, and those modes use in a shared secret in addition to the DH
secret.  So you would need to exfiltrate the PSK as well.

Looking at the key schedule [1], it looks like it would not be sufficient
to send the master secret, since that wouldn't get you early data or
handshake messages, but it would be enough to exfiltrate the DH and PSK

Nonetheless, I don't think this significantly changes the proposed design.
The interesting question is still whether opt-in is an acceptable
requirement for the folks looking for a mechanism here.