Re: [TLS] Enforcing Protocol Invariants

Eric Mill <eric@konklone.com> Fri, 09 November 2018 20:40 UTC

Return-Path: <eric@konklone.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 8151F130E0F for <tls@ietfa.amsl.com>; Fri, 9 Nov 2018 12:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=WTfXrFso; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=EHlFnUS0
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 IUFAx49hXiia for <tls@ietfa.amsl.com>; Fri, 9 Nov 2018 12:40:11 -0800 (PST)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DF31293FB for <tls@ietf.org>; Fri, 9 Nov 2018 12:40:10 -0800 (PST)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EB6F2117C7A for <tls@ietf.org>; Fri, 9 Nov 2018 15:40:05 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=nU2xY3x7dbygEBzHnDB9BPWZ7j8=; b=WTfXrF so4Zhoc8d7biL/AJaUHGZkORUMGaN0CB5AFTSkm6D+msgRFGKy/9+NJ4nalq/yvf E2/d66t8gtlfzQMYz0G9bJXi2Th+qPs3eIFXQ6fVK0CVlmtrfKTamg9O2CAIiHwO pYUko87FYAkOAbUYUTO8G8cAZ20iI/XBD3LqE=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DE1C0117C78 for <tls@ietf.org>; Fri, 9 Nov 2018 15:40:05 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=konklone.com; h=mime-version:references:in-reply-to:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=V0mDXnwKCEUcUJjOqmcrtV0J04QEOcifeS55Sm+UgXc=; b=EHlFnUS0NXzCJH95xdjyx2s3OuSiVIOtGPq4SrQmXTY4Ok3xrQiaaEyi6uDMrkCr1hER+FAPF1g0InaUKRnYaFMRshM+Wep/+Zb4/UcFlHWluhUqNYHjNfK4LvUcc01h0bpSw3P8ubIHfCd0QTJUyA1jzNiKahvGaWgq2WhaQAU=
Received: from mail-it1-f176.google.com (unknown [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 9CDCE117C6D for <tls@ietf.org>; Fri, 9 Nov 2018 15:40:03 -0500 (EST)
Received: by mail-it1-f176.google.com with SMTP id j79-v6so5278828itb.2 for <tls@ietf.org>; Fri, 09 Nov 2018 12:40:03 -0800 (PST)
X-Gm-Message-State: AGRZ1gKBiDyjUrv9LqDJHROSabxX36FNpxWmyWC1MauvqpO3PfxXKKBI A2uZPaFjwCURjJwuZ2hAPS3vE9rZp8BlE4GWurk=
X-Google-Smtp-Source: AJdET5dgdTdrTHWL0K92lWX6dbYd5VbjMGaYzXQOfsJQlZilRgg9w2jBifbEFhYULFpq5DF3V23bUFtsBezOzrpCCLM=
X-Received: by 2002:a02:3b54:: with SMTP id i20-v6mr9683029jaf.17.1541796002125; Fri, 09 Nov 2018 12:40:02 -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 Mill <eric@konklone.com>
Date: Fri, 9 Nov 2018 15:39:25 -0500
X-Gmail-Original-Message-ID: <CANBOYLX+SsT32VpW541e4CexwthRd-XUDkCArRG2DPpy8TWxcQ@mail.gmail.com>
Message-ID: <CANBOYLX+SsT32VpW541e4CexwthRd-XUDkCArRG2DPpy8TWxcQ@mail.gmail.com>
To: Ryan Carboni <ryacko@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005e105057a415b7b"
X-Pobox-Relay-ID: A2A521A4-E45F-11E8-98F4-BFB3E64BB12D-82875391!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r47jWu1y9Wr447MYNKtgXN_m7qA>
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 20:40:13 -0000

On Thu, Nov 8, 2018 at 9: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.
>

This misunderstands the utility and deployability of SRI. SRI is based on
hashing data exactly, and so sites can only practically use it for files
that do not change (e.g. jQuery x.y.z) and not services that do change
(e.g. an analytics service, or really any live service). Encryption in
transit for public files, between services operated by separate entities,
is a practical necessity to preserve integrity.