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

Ralph Droms <> Tue, 24 October 2017 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70CAB139B9F for <>; Tue, 24 Oct 2017 12:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eCgcAcjAgWYH for <>; Tue, 24 Oct 2017 12:27:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 832D313B482 for <>; Tue, 24 Oct 2017 12:27:24 -0700 (PDT)
Received: by with SMTP id k123so27727484qke.3 for <>; Tue, 24 Oct 2017 12:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=34xPsj+1PTucGcfjpFRdKH9WZLNXuNUziV7KuSzjzlc=; b=J4d8DWK4bFpTWEH6UHAlKj0qxWivLzBNXDUquKU4+A1+6QFbIEx0vIE8vaincatW0R WsJQh4mrOyrxmE+NfZAqnyIqFDdXfRK3sfGXsE6JpapsY7X11QSaFK2xCp3vRLakN4sK ZfEUuF5+TrQo8ZacShNbb3Lf+Z3W1N0VUs4FGk6WPyVxl11TgBlSFj7O51PLuGRnQcxh pk8S7RoORw+ZnzvuSy34s2MU9fQnZwCITUPIfkdLwxjork8LdZSiOx5opPhjhtineR8o SXO+XVc8LiVQGfEFcJ+on9Uj6H74+34nzuIG9UHat3k6B/kHdLUKFb+KkKD66eUOGyF0 1IEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=34xPsj+1PTucGcfjpFRdKH9WZLNXuNUziV7KuSzjzlc=; b=FZspXc/PaIF8HqdsMl28+SPZr6H6NKJVnwxNO4LJfDJOH9P7BOfgJrSDRU1JSxGl29 omYSBXYOY3nFQz0/tilKWBzAhZ2Y4NOnTGgk2g2OZj60TUGdL7D9BeQPN7BOkq/xDzQw bZzGcHK5Td5wUoULAhl32t/r8AqwlFtct1b0UBrHUIZ0WChXTzK+V/ntOgvC9SXBy4kc rDJI8TItsANUtOyNcbt4c5jQ83I2ckj5kN7RVXYdcMsjwAYB+mTCTO4IyBSjzyJUv/HP HyFXshLxdhfAciPzlCHny5abqfqmbCdYyN9dOBTx1fzdeYK9L/aKjMytQvuBc2b/RI1A 7pHg==
X-Gm-Message-State: AMCzsaX0n1qxGMFgI6/hbmqAlmnmDJQ+leMZ2FPf944p2sqSQlZrpndP 14/Z5QVtnPkGTvUePZ6WdYUHATW0
X-Google-Smtp-Source: ABhQp+Q8BECkSTRNQzRYIHz8EMMSyxPBS29VvsEF7gpjh+HecJAs1UluXq3k2MXspuohufDBoe89Bg==
X-Received: by with SMTP id j18mr25980228qke.327.1508873243590; Tue, 24 Oct 2017 12:27:23 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:3db6:d45b:1b54:f2a3? ([2601:18f:801:600:3db6:d45b:1b54:f2a3]) by with ESMTPSA id l207sm653507qke.97.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:27:23 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Tue, 24 Oct 2017 15:27:22 -0400
Cc: "David A. Cooper" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Salz, Rich" <>
X-Mailer: Apple Mail (2.3273)
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 19:27:26 -0000

> On Oct 24, 2017, at 3:23 PM, Salz, Rich <>; wrote:
> I use an airplane as an example of a “captive” population, substitute any similar group you want.
> 	• Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.
> True, but that’s not the point.  The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic.  I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying.
> As for how would such clients get promulgated?  Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.”    How many people on the plane would click and download?

Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all?   That is, I don't see why this scenario is specific to the visibility extension.

> > Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.
> How do you propose to guarantee that?  As Stephen pointed out, we have no way to prevent this from “escaping” on to the public Internet, and no way to prevent captive audiences from being forced to comply.
> _______________________________________________
> TLS mailing list