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

"Ackermann, Michael" <> Wed, 25 October 2017 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 665D2139101 for <>; Wed, 25 Oct 2017 09:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.091
X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tvNalJ9Mud0f for <>; Wed, 25 Oct 2017 09:11:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 124CC138F83 for <>; Wed, 25 Oct 2017 09:11:43 -0700 (PDT)
Received: from (ZixVPM []) by (Proprietary) with SMTP id 798E4C0DBF for <>; Wed, 25 Oct 2017 11:11:42 -0500 (CDT)
Received: from (unknown []) by (Proprietary) with SMTP id E5070C0DAE; Wed, 25 Oct 2017 11:11:41 -0500 (CDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id AB41AFE0F0; Wed, 25 Oct 2017 12:11:41 -0400 (EDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 50F78FE04E; Wed, 25 Oct 2017 12:11:41 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPS; Wed, 25 Oct 2017 12:11:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0oH2yvYiobsdYTLC8LBwJ5wU9z6g0sdjaV1k5BMGml0=; b=1ARPmKxGTuV0wlQWuTKtl38zPLjud7uG4U+4Hwl8Nq2qEjX//i/qicpET9+4czIl3M4pqmiSYLyC7SnF8zd1flL+lzRHBA7OMlbjpgeZucVIhJ6nmz8OBvCCdu0tXJ4NlLEGEibBVZDZMDzWTe8HlfJ3JRM52MpEkj7nvXoSxzA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Wed, 25 Oct 2017 16:11:39 +0000
Received: from ([]) by ([]) with mapi id 15.20.0156.005; Wed, 25 Oct 2017 16:11:39 +0000
From: "Ackermann, Michael" <>
To: "David A. Cooper" <>, "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Date: Wed, 25 Oct 2017 16:11:39 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1361; 20:3dZAiOPXN3aW9W1beYHCYEJQr1bhWS2eUPfKEXEQ/wzTlTXg8RgWaaNgqucjKep9wwJlNvo7lz1MsSmvfPAfKKfvrZeke4/OVPlTpHA2eq4n12f353HDhD5S+//3ycpbdaeQ9Pmy5n9NOA79EqK60JiyoaV07Dz8lgpNFlxSYWU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7a43dcf4-de66-459d-5393-08d51bc3132a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR14MB1361;
x-ms-traffictypediagnostic: BN6PR14MB1361:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR14MB1361; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR14MB1361;
x-forefront-prvs: 0471B73328
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(24454002)(13464003)(189002)(53546010)(305945005)(101416001)(8936002)(68736007)(3846002)(102836003)(6436002)(8676002)(6116002)(6246003)(7696004)(81166006)(33656002)(77096006)(229853002)(230783001)(2501003)(53936002)(80792005)(74316002)(6306002)(9686003)(966005)(55016002)(97736004)(3660700001)(5660300001)(3280700002)(14454004)(316002)(25786009)(7736002)(72206003)(86362001)(2906002)(81156014)(76176999)(6506006)(2900100001)(54356999)(50986999)(105586002)(106356001)(93886005)(189998001)(478600001)(110136005)(2950100002)(66066001)(99286003)(8656006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1361;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a43dcf4-de66-459d-5393-08d51bc3132a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 16:11:39.6125 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1361
X-VPM-MSG-ID: f689f2dd-3c8f-4834-897d-4f75ec785b03
X-VPM-GROUP-ID: ca4b5b37-7995-4a88-a02b-34ce30bbcb8a
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: Wed, 25 Oct 2017 16:11:45 -0000

" idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge."

Responding ONLY to the above sentence,  as I agree with Stephen that this has  gotten too NOISY.  

But at the end of the WG meeting in Prague,  the Chairs asked for the two sides to work together to find common ground.   We tried very hard to set up as many meetings as we could.  Very few would meet with us.   Ted Lemon was one.   As is evident,  Ted and I don't always agree,  but he went out of his way to meet with us and exchange views,  which was greatly appreciated and the type of effort it will take for two sides that do not agree, to find some form of compromise.    
The only person that gave us constructive ideas in the common ground, was Martin Thompson,  who we all greatly appreciate meeting with us as well.   Out of that meeting came the idea that having the client be aware,  could address some of the issues brought up in the WG meeting.  
My point here is that we are trying hard to find ANY common ground and want to work towards this.   The client aware feature being added is NOT something that Enterprises want or need,  but was an effort to compromise and attempt to gain mutual consensus.  
And if this is not a feature that everyone wants,  then so be it.   But at least it was an attempt by a small number of people to try to find common ground and make any form of progress.  
If we could do more of this and less of the negative, duplicative and sometimes insulting rhetoric on this list,  perhaps we can make progress.   

-----Original Message-----
From: TLS [] On Behalf Of David A. Cooper
Sent: Wednesday, October 25, 2017 10:50 AM
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that would filter traffic based on whether or not the extension is present in the ClientHello. I've already explained why I believe that scenario will never happen, and so no I do not agree that it is a "fundamental change."

The idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge. Obviously you believe that the method being proposed to address one concern introduces another concern. I do not share those concerns for the reasons that I've already stated.

I don't plan to comment on this issue any further, and doing so would just be repeating myself, thus just adding to the noise.

On 10/25/2017 10:28 AM, Salz, Rich wrote:
> ➢     Similarly, the best that TLS can offer in terms of privacy is that the
>      contents of the communication between the two endpoints is not seen by
>      anyone else *unless* at least one of the two endpoints (client or
>      server) chooses to provide the contents of the communication to some
>      other entity. draft-rhrd-tls-tls13-visibility doesn't change that.
> Yes it does.  It signals on the wire to any observer that the client and server agree to this.  TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently.
> Do you agree with that?

TLS mailing list

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.