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

Ion Larranaga Azcue <> Tue, 17 October 2017 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C54F132705 for <>; Tue, 17 Oct 2017 12:55:31 -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 O8tDohAIo03n for <>; Tue, 17 Oct 2017 12:55:28 -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 CEDDD13292A for <>; Tue, 17 Oct 2017 12:55:27 -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 19:55:24 +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 19:55:31 -0000

> 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.

I don't see it that way... For me, using the capabilities provided by this draft in order to get an OOB-only  "no client involved" mechanism is more difficult and probably less efficient than creating one from scratch...

That being said... One thing that bothers me from my last emails is that I seem to find myself on the draft-defending side of the discussion while I don't really like the draft itself due to the concerns I pointed out in my first email... I'm not fully against adding monitoring capabilities to the protocol, but I would prefer a "no-monitoring-allowed" TLS if the alternative was going with an insecure tapping mechanism.