Re: [TLS] Enforcing Protocol Invariants

Eric Rescorla <ekr@rtfm.com> Fri, 09 November 2018 02:52 UTC

Return-Path: <ekr@rtfm.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 7C87E130DC1 for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 18:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 CPHMPN_YEdy0 for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 18:52:29 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 385601277BB for <tls@ietf.org>; Thu, 8 Nov 2018 18:52:29 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id p86so263711lfg.5 for <tls@ietf.org>; Thu, 08 Nov 2018 18:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xn7Smq305soewKT4AVMp8AZoexUfEg43d1T8SMfr3qE=; b=Colxbq1nxuUjaHyEiGeffeVC3ATUKtl3U2vX+WcNPiKz2RJyXxs6fKtWkHfp+KR4nU 5Blu/L33H8tJd/YHLlrTaJi8omdlRFgTkoQMUQXV37MUDgPwoAeb5/wRX5yCK5rF0WP5 G7YTfMQ1OU1N4Ofq5qDKLZ1r7ATsKKPSi4xSqdxwCRVTMfn49pKgXGHAZb5+Hm/eT6nU e+RAUvZSn9UuNKW1p+J728giMrRm/ECyND5msbE9KlJ2pHaW+2ORRI1ehXpAw+5584ei NJJLaPtyezOTIxePKgaIxfXZk3w7csJCHIo50mlp8ihtsYzkldbroQ5zMAifPsn7d/Jv 6piw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xn7Smq305soewKT4AVMp8AZoexUfEg43d1T8SMfr3qE=; b=cHMkyXF2jIs0ZOW45mkg4mDg7wSjc9De/qgaLhMWpIBkMlI/uc7I4aDDroLaTcOaca DkJM4YC5PguiSrWC5/uGkQv9M19SFvghglaUdQYt0xo4PLUhe+yzX553QsxIxlCapA57 zaRptp1cOAaxtMg/jYBckHqg0ZnxL780i08BPZtKisr2d41ysYx0YGo74o8+9EBFANQ9 zdMejLphg6PsZ2QrUgslBnbS0MynwYCcV2K8HBX35JQ03RW3a+8x5tbBU8EEOhog/GXu xCQY4JobpRMiROnB660RTqzulb/UVTtE6n0AZ9qyvAZtG3p2XWSBUmWwDs4wXQjCTYdN GwPQ==
X-Gm-Message-State: AGRZ1gKA9GLJa3d9eh0kktTJiwYWByxHR88xfEk25SniXjrn88qj16tj 9VPYQAlW+XjRW/QgsAQnlKgAbRdwYQUoXjhPs3Qlhg==
X-Google-Smtp-Source: AJdET5dCZKGCUYuAOD392OITn5FXnDu4P5mdOboente71KaE8k6B4ldlb0yowefj+yqQRL35jNcMY10Y/dF/NKhEFX0=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr3940707lfj.126.1541731947151; Thu, 08 Nov 2018 18:52:27 -0800 (PST)
MIME-Version: 1.0
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CABcZeBPb2aPE3eXsqD5-qvWO88W=iMRxZ9YgCXZiTSGAPBDMxQ@mail.gmail.com> <CAO7N=i2L9mY1kdZNhgSV90e5FN64VBh0miApQv_9ws9fCdaGVg@mail.gmail.com>
In-Reply-To: <CAO7N=i2L9mY1kdZNhgSV90e5FN64VBh0miApQv_9ws9fCdaGVg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 8 Nov 2018 18:51:49 -0800
Message-ID: <CABcZeBNMVcidMGAE2XeSqpYRriUke_wmXvc6m5WVto7j6eM8vA@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c9ff2057a3271f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w0_BdVFMfT5f23L-vP7Dd292gYo>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Nov 2018 02:52:32 -0000

On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni <ryacko@gmail.com> wrote:

> On Thursday, November 8, 2018, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>  It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>>
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third party, the value of encryption is less than zero.
>

I believe you are misunderstanding me. The issue is not about
confidentiality of the records but about correctness.

Consider the case where example.com which is hosted on two CDNs, X and Y. X
and Y have different private keys (for the reasons you indicate) as well as
different crypto configurations. The client does an A/AAAA lookup for
example.com and gets an A for X and then does a TXT lookup for example.com
and gets the TXT for Y. This creates failures. We've spent quite a while
working on this problem for ESNI and there aren't a lot of great answers
right now. It seems like your proposal would suffer from the same issue.


In any case, Eric, you inadvertently contradict yourself. The whole point
> of WebPKI is to certify trust, and has been an issue over the years. But
> CDNs act as a intermediary between the creator of the content and the end
> user. CDNs do not have as strict requirements as do CAs in terms of
> auditing, and have their own issues outside the scope of this conversation.
>

Well, I agree that this is out of scope, but the guarantees that the WebPKI
claims to enforce (at least for DV) is effective control of the domain
name, and a CDN acts as the origin server for a given domain and hence
effectively controls it. I appreciate that many people don't like this, but
it's essentially the only design that's consistent with having the CDN act
for the origin, which is at present basically essential for good
performance.


In any case, TLS 1.3 won’t reach widespread adoption for another few years,
>

I don't know what you consider "widespread", but presently both Chrome and
Firefox support TLS 1.3, and our data shows that about 5% of Firefox
connections use TLS 1.3. Chrome's numbers are similar and the numbers from
the server side perspective are higher (last time I checked, Facebook was
reporting > 50% TLS 1.3).

-Ekr