Re: [TLS] Is there a way forward after today's hum?

Tom Ritter <tom@ritter.vg> Thu, 20 July 2017 15:45 UTC

Return-Path: <tom@ritter.vg>
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 8CD9C131746 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 SiNLqhdE06tT for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361F21252BA for <tls@ietf.org>; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id 35so26257635uax.3 for <tls@ietf.org>; Thu, 20 Jul 2017 08:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6b4ebNb3Cq4Cpvyh1bH5veOhUCO76dLiEPamlHdG1Mo=; b=mi8CyFGE4OBaN8Jb+iOhNvDcaFcNpWTVjXQE+W788DQcFCccrEX7FjHbq4bj+8qa4R jv/6CR5e1yaXbnLsPnTNa8PGI1h+d1stYBCrrh6GhDwAeuB0wDi2LSo9/yFD66J0Nn4b kEy9Wr/GpbOUm7SsM5TLkzdDxty4gzxOmpl2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6b4ebNb3Cq4Cpvyh1bH5veOhUCO76dLiEPamlHdG1Mo=; b=R9ddvYnCMAZCIyT8K2ZbN8fxB0f9+dnJ4qceZgmK5G5XYgzt+AYBxbkHwRxSSuCaIl Rr43S1NIAB427uVq+T5c1AjgRPefAMsXqN75YujEjhlXx0Ftwr/ySvG9WOmPzM8jhtLv FmS9v1z0kyhjkoJLnyWMXJRatqLN9kQLmZDhv0hKXaZH4xp+O4QrC3h1TQlOSRaUcTze TStl0tq5/AFnf8TNha/Y8vJlgKWs3ZLv49eruuQBf/JsORVWVPbEv5lMhYWDIZZhzFWX D/HzqLP3az6LVxMcD3AitIUJMGJIsTGJ+DVVwdixEx3fb3ZLZkjjputvZfoKymYNXBdO qIDg==
X-Gm-Message-State: AIVw112gK35/WbZ0zEtc/20b86UlXeRkUdJdnjFEcpHPpZYm2ySkVr9b I0BmokZCz0kgkG9bmO5ecTR6ktve1FKG
X-Received: by 10.31.61.88 with SMTP id k85mr205312vka.19.1500565519122; Thu, 20 Jul 2017 08:45:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.195 with HTTP; Thu, 20 Jul 2017 08:44:58 -0700 (PDT)
In-Reply-To: <6153a25746a246f9be26350adbc58213@venafi.com>
References: <E6D7DDCD-FDE6-4784-ACE8-0F5AC8E2CEDF@vigilsec.com> <CAPt1N1ka=vuoZMB58LXfkJ_qafohf08WeoUs2y4kaCxBtCx29Q@mail.gmail.com> <EEBF938A-234C-43E3-B058-4AE443C66EF0@vigilsec.com> <EF9F84E0-2C71-4A73-989E-1EC6B86861ED@gmail.com> <CA+cU71kM-u4JxJU8_9ogK0MbnNcy=y5-y-5FzkL8TEV_JaAK8Q@mail.gmail.com> <01a201d30169$f8c68530$ea538f90$@equio.com> <CA+cU71myamTTsmWUaO7DfzS_3-L1PQzrs03PgmseNjrKwdhHbQ@mail.gmail.com> <6153a25746a246f9be26350adbc58213@venafi.com>
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 20 Jul 2017 10:44:58 -0500
Message-ID: <CA+cU71=DgvTLPEzYK-ujzvHgZ3YKiE2cdtOj=iT60A1ehcBBEQ@mail.gmail.com>
To: Paul Turner <PAUL.TURNER@venafi.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2-E3crgS5icipIPhbhSceQS1pZc>
Subject: Re: [TLS] Is there a way forward after today's hum?
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: Thu, 20 Jul 2017 15:45:21 -0000

On 20 July 2017 at 10:29, Paul Turner <PAUL.TURNER@venafi.com> wrote:
> Thanks for this clarification. I agree that anything is possible in both
> directions. Russ opened this discussion by asking about an alternative to
> static DH. In this model, I’ve assumed the client would need to explicitly
> opt-in by including an extension in its ClientHello. There are obviously
> details to work out but if it were possible to provide a method like that,
> it seems like it would thwart the second option. Would it?

Not when the target of the request is Facebook for their Messenger
App. Or Google for the Gmail app, or Hangouts. Or Skype.

What percentage of TLS protected communication takes place between a
client and server developed by the same company? All of that is
immediately at risk.

What about 360 Browser (one of the popular Chinese-made web browsers)?
Hell, they _still_ aren't validating SSL certificates!![0] The dynamic
for them (both technical and political) is quite different than for
what we tend to think of as 'browsers'.

I get the impression you're assuming that 'the' (for nebulous values
of 'the') government isn't going to ask a web browser to support the
mechanism, and they would only go to the webservers. But because it's
an offer/accept mechanism, there's an argument that goes "Hey
Browser-Maker make all of your installs _offer_ to encrypt to our
escrow key, and if the server doesn't accept it, don't." "Hey
US-Company, make all of your web servers support escrowing to our key
if the client offers to. If the client doesn't offer, don't."

The more I think about standardizing such a mechanism the more nervous
I get we will be building something that is too likely to be used,
even if not expansively, against the ideals we have espoused in 2804
and elsewhere.

-tom

[0] Yea. Really. It was this case a little bit ago for 99% of sites on
the web and I'll make you a bet it's still the case today.