Re: [TLS] Breaking into TLS to protect customers

Ryan Sleevi <ryan-ietftls@sleevi.com> Mon, 19 March 2018 16:22 UTC

Return-Path: <ryan-ietftls@sleevi.com>
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 6D5AB12E034 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com
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 ePACDvKKKKkL for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:22:50 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D617712DA73 for <tls@ietf.org>; Mon, 19 Mar 2018 09:22:50 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 5DD3130002938 for <tls@ietf.org>; Mon, 19 Mar 2018 09:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=CdrcsTcTYRtj2xvTJjr7CJAbZlk=; b= eSMdh8GKNixcY5kJHK7u3dKuIhJhZaBIKTCeqeC/n7MrA7Uv3QRC8dX/rZveH9pR O/mFPmZm1xyq/Ex7UvOGj9/QH8uKKL1SjXBfTZrIRLGTityucLLaqEhyffWdDWpf GJaNuvoh9WTRcI8iZuSTphn9GTciXW25PKkKj/2KEh4=
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 41BE230002932 for <tls@ietf.org>; Mon, 19 Mar 2018 09:22:50 -0700 (PDT)
Received: by mail-io0-f170.google.com with SMTP id d5so6932655iob.9 for <tls@ietf.org>; Mon, 19 Mar 2018 09:22:50 -0700 (PDT)
X-Gm-Message-State: AElRT7EpEtoh0DaZFsosoyZVkwbYYzO+y9ZN+TnRFoxBvS/3XRIoubo2 yl0Ds0uDZ4Imp8pCDAiQ1/hlVr4PBm2fb8kTlz8=
X-Google-Smtp-Source: AG47ELtW+Rp+W8ADmYBVAcV0pCsOptcONh8ZsHhYNiVluo6C41dF4LRNSlbF1Gvz2d8PbDREWNyAL+JQH2F/smj0nNc=
X-Received: by 10.107.152.77 with SMTP id a74mr12194744ioe.78.1521476569531; Mon, 19 Mar 2018 09:22:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.152.80 with HTTP; Mon, 19 Mar 2018 09:22:48 -0700 (PDT)
In-Reply-To: <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <6888195D-1AD6-45B1-8F77-AFA088CFF78A@gmail.com> <87y3iottae.fsf@fifthhorseman.net> <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Mon, 19 Mar 2018 12:22:48 -0400
X-Gmail-Original-Message-ID: <CAErg=HExeE0L3Lw4i2gEx3URVfci=RrODHBcVR_EF255R1FYvw@mail.gmail.com>
Message-ID: <CAErg=HExeE0L3Lw4i2gEx3URVfci=RrODHBcVR_EF255R1FYvw@mail.gmail.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11494c80760e380567c65e29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wv99Z0-4J3WOgjyFlXJLmRrl1-0>
Subject: Re: [TLS] Breaking into TLS to protect customers
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: Mon, 19 Mar 2018 16:22:57 -0000

On Mon, Mar 19, 2018 at 10:20 AM, Colm MacCárthaigh <colm@allcosts.net>;
wrote:

> 2/ clients and browsers could easily consider such sessions insecure by
> default. This would mean that adopters would have to deploy configurations
> and mechanisms to enable this functionality, similar to - but beyond - how
> private root CAs can be inserted.
>

I thought the use case was that this was not for clients and browsers, but
for server<->server interactions.


> Wouldn't those be good properties to have? Compared to servers secretly
> exporting transcripts or session keys, or just having a private root CA
> installed which breaks all sorts of certificate verification
> infrastructure?
>

A number of platforms are moving away from the ability to install private
root CAs. Platforms such as Android, ChromeOS, and iOS are three examples
of modern 'consumer' platforms that restrict or prevent such ability. On
the consumer electronics space, you have a variety of TLS-using clients
without such capability at all.

In these cases, servers secretly exporting transcripts achieves the
properties desired, but the other solutions would preclude such devices.
For the use cases described, could you clarify why this would be
undesirable?


> I think the existence of a "standard" here could also serve to encourage
> providers to do things the more transparent way, and create less likelihood
> of a mass-market of products that could also be used for more surreptitious
> tapping.
>

It's difficult to speculate here about the potential impact, but isn't
another possibility that it would legitimize a mass-market of such
products, particularly if such capabilities were introduced into clients
and browsers? You could, for example, see governments encouraging and/or
requiring the use of such protocols, which otherwise would not be
technically possible on the aforementioned platforms.