Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ted Lemon <> Wed, 25 October 2017 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C686137ED6 for <>; Wed, 25 Oct 2017 13:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 Rjw7ZA7zV83C for <>; Wed, 25 Oct 2017 13:03:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19AFC1386F3 for <>; Wed, 25 Oct 2017 13:03:41 -0700 (PDT)
Received: by with SMTP id 17so1591023qkq.8 for <>; Wed, 25 Oct 2017 13:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7YinkYvePlLsr/SCP/3uFcks3mQhLrP2pFIEAL42NEs=; b=UVjO9PofnDSJ+Slepw0qQ8dOtNs8idRfB4xyhgH4bKGMiBreU/v6ycyrPWGv2Z1ctF yY9J+9oI+o8NhjJxqJH4gFkI86glDHa7fkRdcjD51QF61K7ksvUiTl1I4zQkI6QtVbYl joBgvgIqJH/XxWx+KxZEjAoWastft8S3w9XWfXFHw/JcohBcbIGh9Ewc3uTXhJZP0K8y wcxS/143jwPXiCb+uzf//n2OepRUVdz6/+VS9ByGkTtqppIvuQ18jG966bqBBW4MAw/i OQPSEYN5CBMDKSN3lRZe2TENhPKog66DNIpsd9PmP5jWTNK67ZQxwwlBRqWsGMlI/kX3 pBmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7YinkYvePlLsr/SCP/3uFcks3mQhLrP2pFIEAL42NEs=; b=J77OaDeiHaxwHUIFlOiyz3PKhN84FUHFRX12Ww1owDbEj8D0gUsPq0dgsUW1uGkakn 07dhHx/AHY6FYrN73DTQJzxxOWJKaH8My5c5wDqR2KmXtYf+0makrBn30zdgSoe1kRsH rziMre2WHNM0sstklxo9UEkJR7Zf2/tZ690mobBLXbTuYy+ZSKFXr9FabDjPMxm3nLW+ k/8q7sb6rFLX3Palr1xUQOCnpiYVovRddpne0aZaR7McuSjIyAoGqvgv1rmUB1UQubFY +OILaOI9w6fwB31DcJqEC77nqNwEO5GN9MKVvC4dAQJjmzavd2RMRt7zuzLN7P4OLtwr MEzQ==
X-Gm-Message-State: AMCzsaWvcbHeLwxSHSMteXV2lbGMrs21PetYfoC9a5uamonxawTyoO8m FhwC1eSUVZDxTIuLxS2KZYO92g==
X-Google-Smtp-Source: ABhQp+Rd+ZAs4K9hZRNsU/Epf1W2EtgWWW8e4erFOfbYwDIZ91FUm2i8o0sLXTL7pXh4r5Vh2stPSQ==
X-Received: by with SMTP id h5mr4828960qke.209.1508961820132; Wed, 25 Oct 2017 13:03:40 -0700 (PDT)
Received: from cavall.lan ( []) by with ESMTPSA id h21sm2529321qte.72.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 13:03:39 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_55B59970-5B07-43D5-9552-7556F0525C4C"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 25 Oct 2017 16:03:38 -0400
In-Reply-To: <>
Cc: "Salz, Rich" <>, Paul Turner <>, "" <>
To: Nick Sullivan <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Wed, 25 Oct 2017 20:03:43 -0000

On Oct 25, 2017, at 3:34 PM, Nick Sullivan <>; wrote:
> Forward secrecy with respect to other keys, like the session ticket key or other keys that can be generated centrally, are things that need to be looked at more closely for TLS 1.4 (or whatever’s next).

Unless I am very much mistaken, it is literally impossible to prevent a server from escrowing a key so that the contents of the communication can be decrypted.

> - having such a system on the internet is a bad idea because it reduces the security of multiple connections down to a single piece of data
> - on the other hand using draft-rhrd is safer than allowing organizations to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret cipher suites

There's no question of allowing or not allowing—that's outside of IETF's sphere of influence.   But the case has been (to me convincingly) made that making it possible for an eavesdropper on the conversation to easily tell whether a client is willing to accept key escrow makes things worse, from a security perspective.

The main sense in which it makes things worse is that such a feature might be added to standard libraries, and thus be available at low cost, and thus might become easy to impose as a regulatory requirement.

This is why I have been advocating for simply not using TLS for this use case.   There exist solutions to this problem that do not require breaking TLS 1.3, that are standard, and that are already allowed for PCI compliance.   It's better for everyone if these two domains are kept separate, and I haven't yet heard a good argument for not doing so.

> The fundamental assumption of this draft is that that 3) is not feasible for all enterprises because rearchitecting their systems for a multi-key escrow is either too costly or that the requirement for TLS 1.3 will come too soon. Ted Lemon had some convincing arguments earlier about why enterprises should see this coming and invest in migrating to a model closer to 3),

To be clear, I actually don't think that per-session key escrow is feasible in the use case that we are talking about here.   From a security perspective I think it's a pretty good idea, because it allows for things like rate-limiting the number of connections that can be monitored, but from a practical perspective, arranging to have the keys available in a timely manner during debugging seems to me not to be tractable, since the number of keys involved would be substantial, and the timing would be quite exact; indeed, if the debugging process requires debugging all active streams in order to find an ID in the stream that is actually sought, I think it would be almost impossible, and certainly ludicrously expensive.

What I've been arguing for is to switch away from TLS for this use case.