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

Ion Larranaga Azcue <> Tue, 17 October 2017 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54E7A1323F7 for <>; Tue, 17 Oct 2017 11:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oIzsDjfJnDcI for <>; Tue, 17 Oct 2017 11:34:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCE51126B6E for <>; Tue, 17 Oct 2017 11:34:35 -0700 (PDT)
From: Ion Larranaga Azcue <>
To: Stephen Farrell <>, Florian Weimer <>, Hubert Kario <>
CC: "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Date: Tue, 17 Oct 2017 18:34:32 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: es-ES, pt-PT, en-US
Content-Language: es-ES
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 17 Oct 2017 18:34:41 -0000

> IIUC, with the draft-rehired proposal, the client
> can in any case not be told - the TLS protocol
> extensions are mere politeness and the client does
> not get to know what snooper(s) are involved, nor
> can the client influence the snooping keys. Once,
> any infrastructure for this was deployed, I think
> it'd be used without telling clients for sure. (And
> we would be fully complicit in helping that happen,
> if the WG adopted this stuff, because we know that
> such abuses would be inevitable.)

Not really. The draft relies on the server sending a non-encrypted extension containing critical information (the session keys encrypted using a shared key between server and third party). The third party is expected to intercept this non-encrypted extension and decrypt it using Ke in order to obtain the session keys. Without this information the third party is unable to fully decrypt the TLS connection. 

If the extension is not sent, the client does not realize there is a third party, but the third party does not have the session keys either, and the server has to provide them in a different way (for instance, using an OOB lookup as Florian suggested). In any case, it's not the same scenario as the draft proposes (the keys are shared in a different way) and can happen with or without this draft being accepted.