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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 October 2017 18:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF71323F7 for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 11:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GODIXCDI78cr for <tls@ietfa.amsl.com>; Tue, 17 Oct 2017 11:39:00 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08549126B6E for <tls@ietf.org>; Tue, 17 Oct 2017 11:38:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3045BE38; Tue, 17 Oct 2017 19:38:57 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqXfUWviNBUR; Tue, 17 Oct 2017 19:38:57 +0100 (IST)
Received: from [134.226.62.25] (cswireless-25.scss.tcd.ie [134.226.62.25]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A4A9BDF9; Tue, 17 Oct 2017 19:38:57 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508265537; bh=bMPm52LiiO2Oonkej8Idi7hcBxkEvWLFAJH9WJQsecI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4Opqiwp19jQRx7BJar0uxptmSUcfDMMccZHNixEGlUlsKOax/QQm1kQ8cscyz4QCQ 5iMfvbIEjvaYfyp7nX8RuheW1zoRQWdN53P1KVLrIXD5cATEe+BxIWHHVr9g6diqUp BVrkIyXaT0N5AYeV5cnbmG9VKmkaXcA4Dkub+3NU=
To: Ion Larranaga Azcue <ilarra@s21sec.com>, Florian Weimer <fweimer@redhat.com>, Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com> <d74976e1-6c0a-a833-178b-d0cfa9ef68cf@cs.tcd.ie> <2530307.EziazPmtDQ@pintsize.usersys.redhat.com> <03d1ea01-d6d7-bf2b-89ed-97a8a270a62e@cs.tcd.ie> <eaeae6e9-dd17-1482-ccae-2af6a14a8b18@redhat.com> <ba29233fe2aa48c78a6ee0e1f7f0584e@LXDOMEXC01.ssidom.com> <7fb19d55-1d51-aa95-5ba5-d383be6c7c47@cs.tcd.ie> <1508265272860.41983@s21sec.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <75f64d63-12c1-a5b3-ea4d-8a612e86d371@cs.tcd.ie>
Date: Tue, 17 Oct 2017 19:38:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1508265272860.41983@s21sec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R2aUdNFcJ6J48aTWw4RJsLnLQD1p00vKH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8gm59gfyGQss57qwAnZPFylgOQo>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2017 18:39:02 -0000


On 17/10/17 19:34, Ion Larranaga Azcue wrote:
> 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.
I agree.

My point is that if this draft were accepted, then the
infrastructure for the above scenario would all be in
place (the DH value for the snooper and the code to expose
session information to that snooper) and the above
scenario would be more likely to happen, more often.
IOW, by standardising draft-rehired, we'd *also* be
putting in place standard building blocks for an OOB,
client is never told mechanism.

S.