Re: [TLS] Precluding bilateral opt-in for downgrade protection.

Shumon Huque <shuque@gmail.com> Sat, 28 April 2018 20:11 UTC

Return-Path: <shuque@gmail.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 21040127863 for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 13:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vjqOM8JfcoCh for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 13:11:46 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 28A2412778D for <tls@ietf.org>; Sat, 28 Apr 2018 13:11:46 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id c3-v6so5631277itj.4 for <tls@ietf.org>; Sat, 28 Apr 2018 13:11:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/oVTrOVmx8+0HD5Ff+knx6tU2kUgke48CdGshxXnRWU=; b=ubfhy1776d1vvpsCcnYEKyGuvlDVbk7sh+8zN78UxO1qPoxixghHi3zTn5UhEuuYSf +twVFwCbyXJt3vEkD+hCngcRvDhiDLsK4xMiumEkRJVrJQ5SEJdJZjmkmQriWML4QhWa RaK57EwIvT49kOIGbUwhoN9yLaC16cN1h5jY2eBb5KgmrFOs57YvBin1XFsxckESw9rY Zo8+u9QBVHqAcMid9u/WghdfmGvUrbkjghKwYiqDZqpOcupFWWWm6CK8km5tV2vlWxX6 Y89G60m7ywUteew0+SDkXUSuxYy87z73j7sTRJC0NpaAYtPCSYG3F7dJA5Ch3WRXqWCJ YJ/w==
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; bh=/oVTrOVmx8+0HD5Ff+knx6tU2kUgke48CdGshxXnRWU=; b=dQ63V5tRIJ6wDfTAasK44ZSXq19z01ruOMyP+0HHHiMK+F3f3VVRooXZIasuOb9LjB J49Ia6p6UYmHcW3Oo1wU1mc4RHLlslymsD7Rb01pXWOd/mK2KfrR5peibGA9rRP1GgKE 0r0PKyM800FOjAOxah0ix1uGBZuN+AVuC2E4pYCkGGiWxvZStwNr0TSWQwFrra/Z3ygL eObtXBP4eEO53rTjgnAIaYXaOl0uNyA3aNwHwE7Dy6fdO1qidibzdHHSZtIAqABVFftP 8gkuh1B8X0/W1Wt4yLrSG32UPUGWmpgDznDdDTUZw4yU8DPNdm4INweqWzZgeCnElVCy aXIQ==
X-Gm-Message-State: ALQs6tB+1CWtoFidvePAjgcGqH2wAazYqN8ovSwj5DwZIuH4zmlZcW4U VXDPW8TCWqWcaTKxaOlJSeVyzPNnILQwGkZg1I8=
X-Google-Smtp-Source: AB8JxZqUgsGcx753OsHWLzlddvIKzUB/oc7Zj3XyaAneh9S9JN8FFLS8GntG2DYRQ6X7a3AlEgVK0ZML83COxQtXFJU=
X-Received: by 2002:a24:5151:: with SMTP id s78-v6mr6662639ita.103.1524946305566; Sat, 28 Apr 2018 13:11:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 13:11:44 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.21.1804281435500.11560@bofh.nohats.ca>
References: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org> <CAHPuVdV+qhC=jS-JEoS6ig6ofRXV__VLOmSL=6c=3_vJK-zCpQ@mail.gmail.com> <alpine.LRH.2.21.1804281435500.11560@bofh.nohats.ca>
From: Shumon Huque <shuque@gmail.com>
Date: Sat, 28 Apr 2018 16:11:44 -0400
Message-ID: <CAHPuVdX3jT4ge2fJRcQ1ee_uvvkH_PAngihr8PSww-eKSW5Mnw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8504d056aee3a0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sw8YWiDngYBNtbHiap_pKI8dFII>
Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection.
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: Sat, 28 Apr 2018 20:11:48 -0000

On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters <paul@nohats.ca> wrote:

> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> This can be clearly seen from various comments on
>> list and at IETF/London, such as the point made many times that
>> the original purpose of this draft was to add DANE as an additional
>> possible authentication mechanism in TLS, not to position it as a
>> mechanism that if available unconditionally trumps PKIX authentication..
>>
>
> This is actually upsetting. I can assure you that since the late 90's,
> people were working on DNSSEC as an alternative for the webpki. I wrote
> RFC 7901 as a building block for doing so, and that RFC is now the basis
> of the format of the data in this document. It is an explicit goal of
> _some_ people at IETF and has been for decades. What the motivation is
> of the individual document editor is not relevant. Once the document
> was adopted by the WG it became a document that needs to represent WG
> consensus, not original author intent.
>

This is a case where clarifying the scope and limitations of the protocol
from the outset would have been helpful.

Many DNSSEC people I know who have followed this draft and
participated in the much earlier discussions around DNSSEC stapling
in certificates were acutely aware of lack of authenticated denial and
its obvious implication that there was no downgrade resistance against
PKIX. So I always assumed there was at least an implicit understanding
of the scope.

What greatly surprised me was that Viktor (and you) did not come to
this realization until a few months ago (I believe that was shortly after I
asked Viktor in private email to read the entire draft and I assume he
came upon the text that described the issue, and the possibility of
extending the protocol to include DoE later). We probably should have
put this text in much earlier versions of the draft.

Shumon