Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Richard Barnes <> Wed, 18 April 2018 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2746A1241F5 for <>; Wed, 18 Apr 2018 13:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Status: No, score=-2.609 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7yxIkLskvDw for <>; Wed, 18 Apr 2018 13:47:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22B30127876 for <>; Wed, 18 Apr 2018 13:47:27 -0700 (PDT)
Received: by with SMTP id x9-v6so2859337oig.7 for <>; Wed, 18 Apr 2018 13:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aotlusnJsB+xTco0RhmhLYp+I2ZOROVrZK7LQVIwMWE=; b=P+fSCnc0bmEW/wimtwYvkVGYsgIjf5vS6ejmti337fbnyZCbeL5rbZYbXJz6S6fZFx tCHBRTt/UeBBwEolWjkVsZlDzWNQWI3lmO56GRF+t5504jle1Pk+ztu3HSIv0FS8BfO/ mqPeOfl0HyAeX1ipHpaSLNGELiARjAuKrO9BymlWFHkCTSFk1naSk+scuwT9T0J5B75W BrvQZ3yqNRMWILmzVHV8fb62j8HCqDqbV2SLN4e/TVo27UjFOhv394UDCcRCEQCqfppx 1SipVf1m4UROIdbFAnfXu4ZaG2KrlHFG3XibRKJ1YFbbXacynxpWTrzyqcdfKvITQDZd 6tiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aotlusnJsB+xTco0RhmhLYp+I2ZOROVrZK7LQVIwMWE=; b=CHr+pJ5l6H6eZt/qX4lEfFdkE/2eaS0+XC/Cdntat0cKUSCNk0gWeVTdtMyc3PyXsA 65uSrKLVg1zbUaa9bpSodVD9m8JciR9tQ0bY3i7aWKi0Pn6xE53mqKdjf8XzDJDgDbYA iVreLGfwhUIUvdrQpx/g0ZIoMumFbOQ8BN5a9betPCVhzKwbqYvGoXs8wnttNnBnzlHw YX2nxWknoaWWvkyzNBmy9wuHednBl0IX1y3x+WoGj//sJe3uF98nrOWU4UiMzSsr4pBo VSz6vXlGmgpmeeHB5UQYuXhKytvBxVdxUxWX0ukYLlmQt6dw2OfxlaVKQ4tr0Klig/bS 2Byw==
X-Gm-Message-State: ALQs6tCKUM1vejkxin/Xr5lyPvgQyeaWYulRbMt2fPM7TGFzqR5NUaRw icQhbkND73q74SI6+r0H9YwGPwbgZ/tRbmnSPmIvRbtg
X-Google-Smtp-Source: AIpwx48RnQScJeRb5PpoJz6ks7Sv3iY0BsZvsCpFUBIUTuxQnlnK0moO7MVnSnLDOChWJ2k1M0mfofYrahhUoRTwB8k=
X-Received: by 2002:aca:b985:: with SMTP id j127-v6mr2017049oif.6.1524084446336; Wed, 18 Apr 2018 13:47:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Apr 2018 13:47:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Richard Barnes <>
Date: Wed, 18 Apr 2018 16:47:25 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: Joseph Salowey <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000082b56056a2590b4"
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Apr 2018 20:47:30 -0000

On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters <> wrote:

> On Wed, 18 Apr 2018, Joseph Salowey wrote:
> This is a combined response of Viktor, Nico and Paul.
>  Concerns have been raised about the trade-offs associated with pinning
>> and I
>>  do not think we currently have consensus to add
>>  pinning.  While I think it may be possible to come to consensus on
>> pinning I
>>  think it may take some time.  I believe we can
>>  quickly get consensus for the following approach:
> A slight correction here. The call that there is no consensus on pinning
> is not entirely correct. The discussion showed a majority of people in
> favour of some kind of pinning, but with most people being agreeable that
> this can be in its own document and not hold up this document further. A
> pinning document is inevitably coming.
>  1. Scope the document to the assertive use cases
> This means actually leaving out what some of us think are the most
> important use case - an alternative for webpki.

A down-scoped document can perfectly well be used as an alternative to the
Web PKI.  As noted before, clients can offer what they support, and servers
can switch.

> While we are okay
> to reduce the scope of this document, it seems logical that such
> decision comes with some guarantees to allow the other use cases.
> Which gets us back to a new document about pinning (see below)
>  2. Explicitly allow (but do not require) DoE be included
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chain. So what do you mean with item 2? Possibly
> you mean to say "if there is no TLSA record, the extension can be omited
> or the extension can be included with a DoE chain" ? That would be okay
> with us.
>  3. Remove current text about pinning
> That is fine, but one caveat below.
>  4. Re-submit the document for publication and start work on a separate
>>  extension that supports pinning
> While we agree we can move pinning to a separate document, it makes much
> less sense for this to become an additional fully independent TLS
> extension, especially since the pinning will depend on DNSSEC properties
> only delivered by the TLS-DNSSEC extension. So as we suggested before, the
> best solution therefore would be to define this two byte pin in the
> current document, and be defined as "ignore completely unless you
> implement this other RFC". That is,
>      The proposed 16-byte "extension support lifetime" field will:
>        * Have 0 as the only value defined in the present draft
>        * Servers that implement only the present draft SHALL send 0.
>        * Clients that implement only the present draft SHALL treat
>          any value received as though it were 0.
>        * A zero "extension support lifetime" field prohibits the
>          client from unilaterally mandating the extension based
>          on prior observation of its presence (pinning).
> This a win-win for both opponents and proponents of pinning. And not
> only that, it will allow us to put the pinning inside the extension
> it relates to.

I do not support adding a field to the protocol with semantics to be
defined later.  Especially a 16-byte field, which is a fair bit of cruft to
carry around.

This seems perfectly suitable for a separate extension.


> Additionally, with no pin set to 0 in the current document, and no
> mentioning of pinning since the consensus agrees to remove it that,
> client implementations will not be told to not pin, and will start doing
> something like TOFU like pinning. It would actually be better to specify
> this zero pin to prevent this from happening.
> If you take it as a given that we will write this document, then it only
> makes logical sense to already reserve these two bytes in the current
> document, even it if states "must be 0". Our document will Update:
> this document to describe the pinning in detail.
> Nico, Paul and Viktor
> _______________________________________________
> TLS mailing list