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

Ion Larranaga Azcue <> Tue, 24 October 2017 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AE5713D2D6 for <>; Tue, 24 Oct 2017 00:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Status: No, score=-4.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0D7VOc182i11 for <>; Tue, 24 Oct 2017 00:31:48 -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 4449913D234 for <>; Tue, 24 Oct 2017 00:31:47 -0700 (PDT)
From: Ion Larranaga Azcue <>
To: "Ackermann, Michael" <>, Benjamin Kaduk <>, Tony Arcieri <>, Adam Caudill <>
CC: "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Date: Tue, 24 Oct 2017 07:31:43 +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="utf-8"
Content-Transfer-Encoding: base64
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, 24 Oct 2017 07:31:51 -0000

Even if YOUR objective is to passively observe, you have to admit that this mechanism allows OTHER PEOPLE using it to modify the encrypted data, and we should always consider the worst-case scenario.

In fact, my opinion a couple of weeks ago was that we had to find some way to provide visibility for TLS 1.3, but after reading other people's comments on this thread, I think there are lots of solutions to provide visibility of the encrypted data within internal networks. And if the transition requires work and money... Well, security always does.

I side with the people that think we should close this topic and move on (I am even wondering if it was a good idea to send this mail and thus fuel the discussion). I'm eager to see a final specification of TLS 1.3 and I'm currently frustrated with being unable to see the light at the end of the tunnel while we are just going round and round the same discussion...

> -----Mensaje original-----
> De: TLS [] En nombre de Ackermann, Michael
> Enviado el: martes, 24 de octubre de 2017 1:31
> Para: Benjamin Kaduk <>;; Tony Arcieri
> <>;; Adam Caudill <>;
> CC:
> Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> NO
> The objective is to be passively observe, out of band and not to be a MitM or
> modify/inject text.    Just as we all do today.
> -----Original Message-----
> From: Benjamin Kaduk []
> Sent: Monday, October 23, 2017 6:33 PM
> To: Ackermann, Michael <>;; Tony Arcieri
> <>;; Adam Caudill <>;
> Cc:
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> On 10/23/2017 05:09 PM, Ackermann, Michael wrote:
> > No one I am aware of is pushing for a MitM capability to address this.
> > In fact it was one of the alternative solutions for which many
> > implementation issues were cited at the Prague meeting and on this
> > list.    But I would like to ask,  what is the solution that your
> > company and others that you reference,  have solved this problem by
> > implementing?
> Is not draft-rhrd-tls-tls13-visibility a MitM, in that the holder of the
> SSWrapDH1 private key has the cryptographic capability to inject traffic and
> modify plaintext for the affected connections?
> -Ben
> The information contained in this communication is highly confidential and is
> intended solely for the use of the individual(s) to whom this communication
> is directed. If you are not the intended recipient, you are hereby notified
> that any viewing, copying, disclosure or distribution of this information is
> prohibited. Please notify the sender, by electronic mail or telephone, of any
> unintended receipt and delete the original message without making any
> copies.
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
> _______________________________________________
> TLS mailing list