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

Ion Larranaga Azcue <> Tue, 17 October 2017 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D614913303F for <>; Tue, 17 Oct 2017 08:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 hHhOaSrc8Azw for <>; Tue, 17 Oct 2017 08:46:19 -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 76500133032 for <>; Tue, 17 Oct 2017 08:46:18 -0700 (PDT)
From: Ion Larranaga Azcue <>
To: Florian Weimer <>, Stephen Farrell <>, Hubert Kario <>
CC: "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuCAAPX8AIAABTcAgAFt2gCAABvygIAGS3YAgAA4PXA=
Date: Tue, 17 Oct 2017 15:46:15 +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="us-ascii"
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 15:46:22 -0000

> I don't understand why this complicated approach is needed.  Why can't the server provide an OOB 
> interface to look up sessions keys, or maybe export them proactively?  The proposed draft needs a 
> protocol like this anyway because SSWrapDH1 keys need to be distributed, and periodic key 
> regeneration is needed because it is the only way to implement revocation of access privileges 
> without revealing the existence of other authorized parties.

In my opinion, the proposed draft does not define a protocol because it expects that SSWrapDH1 keys will be distributed manually (I may be wrong with this, but that's what I understood as the draft does not specify any key exchange protocol between server and third-party). That's why I think that SSWrapDH1 keys will be very long-lived (administrators will hate having to manually distribute the new key in an hourly or even daily schedule), jeopardizing perfect forward secrecy for a long time.

The problem I see with a "server to third party" OOB look up or export of the keys is that the client will not be notified of this export taking place and so will lose the chance to reject surveillance...