Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Ryan Sleevi <ryan-ietftls@sleevi.com> Fri, 24 March 2017 18:17 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 46C5812985A for <tls@ietfa.amsl.com>; Fri, 24 Mar 2017 11:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no
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 Wou_FTRooIxw for <tls@ietfa.amsl.com>; Fri, 24 Mar 2017 11:17:35 -0700 (PDT)
Received: from homiemail-a74.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 2F4591294AF for <tls@ietf.org>; Fri, 24 Mar 2017 11:17:35 -0700 (PDT)
Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id C33CAA00491D for <tls@ietf.org>; Fri, 24 Mar 2017 11:17:34 -0700 (PDT)
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 8DC6CA00491B for <tls@ietf.org>; Fri, 24 Mar 2017 11:17:34 -0700 (PDT)
Received: by mail-lf0-f48.google.com with SMTP id h125so4305479lfe.0 for <tls@ietf.org>; Fri, 24 Mar 2017 11:17:34 -0700 (PDT)
X-Gm-Message-State: AFeK/H22qOQeiZO/LclINrK0z0O9BliSqp4eR0Hqy4XMUiQ6RfXToJyUnacBi+F6X2UVj1VrqYItz2RRn4LkHg==
X-Received: by 10.25.157.65 with SMTP id g62mr5284662lfe.29.1490379452868; Fri, 24 Mar 2017 11:17:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.193.197 with HTTP; Fri, 24 Mar 2017 11:17:32 -0700 (PDT)
In-Reply-To: <20170324171045.DD8051A65C@ld9781.wdf.sap.corp>
References: <CAErg=HEzxHttSOk5Kx=-0qsd3_XWfkVzf_UHZ=YVC6EBctVErQ@mail.gmail.com> <20170324171045.DD8051A65C@ld9781.wdf.sap.corp>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Fri, 24 Mar 2017 14:17:32 -0400
X-Gmail-Original-Message-ID: <CAErg=HFoK2-DeFzn_dYwLPj+0MMw6MxVKZL1Bek2UzAoacDhDg@mail.gmail.com>
Message-ID: <CAErg=HFoK2-DeFzn_dYwLPj+0MMw6MxVKZL1Bek2UzAoacDhDg@mail.gmail.com>
To: mrex@sap.com
Cc: Ryan Sleevi <ryan-ietftls@sleevi.com>, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11411ca2de7429054b7e019a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/02_0kn-uNtQKIzNBx_aTMdqtzeM>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
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: Fri, 24 Mar 2017 18:17:37 -0000

On Fri, Mar 24, 2017 at 1:10 PM, Martin Rex <mrex@sap.com> wrote:

> If Chrome really does AIA-fetching (*shudder*), how can it be disabled?
>

I can understand and appreciate your viewpoint, although we disagree. I'll
save the rest of the list from rehashing that discussion, since the topic
at hand was the question of whether there can be multiple valid paths with
different hash algorithms. I attempted to demonstrate the various ways this
practically happens and how it can be measured.

Given that this is an intentional design decision and a disagreement on
core security principles, it may be appropriate for you to consider a
browser that aligns with your security perspectives, given that despite the
explanations and shared perspectives, I have been unable to convince you in
the past as to our disagreement.

But I do hope we can agree on the topic at hand - that servers routinely
have multiple certificate chains that combine a variety of digest
algorithms, both with a single leaf certificate (CA variations) or multiple
leaf certificates (e.g. Cloudflare, Facebook)