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

Joseph Salowey <> Fri, 20 April 2018 04:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BB8E12D874 for <>; Thu, 19 Apr 2018 21:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 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, SPF_PASS=-0.001, 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 pCdpWv-6q0rX for <>; Thu, 19 Apr 2018 21:09:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AB58127871 for <>; Thu, 19 Apr 2018 21:09:21 -0700 (PDT)
Received: by with SMTP id b131so3377951qkg.2 for <>; Thu, 19 Apr 2018 21:09:21 -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=ICANo1AEaDgmmdb6lcC9ONhgBeDSeo83Mep2RotDdAs=; b=s1+9uCIUuIL+vnSvl+C61Rf6eICIJHqQPAwXP/kR4PCEVOvHHq2PjRhKcC5UC2vUgf lZkApvRgX6xgmfl0JxtHy5OATVZsgh6gk+xAPWkL7c0Xx9hunb+o3e1+rn3ugOXCG3Ie ab33+dA8Ors1n+/Ej3FJ9Rjv5M1zT1GDWoF/o7HH75AfWT7gGACkUc0lgwo1V3gxuWww 5ss6a9O3MkS3SepeWxEp6Dk3rahOQJp6eEEK59HQt6zrk4Msfx2AGa2COkmu7Z31YH4e L5db00nUkR0iGQxFIpvdjho3iSIjs89HfisM56TGzhEXwWQVpxsIGOmlVz79PNB1zXd1 TCHQ==
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=ICANo1AEaDgmmdb6lcC9ONhgBeDSeo83Mep2RotDdAs=; b=deiaqwlIoO5h6tsnwj794a8+W2lCsYcFJN7RN8jz0+GI5RUiu1ypn0QH7BuF5Rsfm1 Ne4nJkCTE1z8BwdH3ckrZMXZGiSNv7yZonpj6Wr+9iSwUhpSZN7icSHUVnK2r6uRatXc MuwwxZ2AXoRHrVfu07F14AtA8xpX54RXm6ajGnB6BeeSAa+YCNBUw66hEEzBa0ilbTaV 9Dm7iJxv0I4bpyXotaUP7zWVmcx+LH4XIqYRV4+Z6NRmTssuyHeBOm1z1MpxmTZOr7mu yRL6Xlld/lA736YyWUYSMFkCJ7R9DuqADKh/mSW02mdYIdI0c1NlyERyhSs66b2vLrHg zq0A==
X-Gm-Message-State: ALQs6tC9KCRMZs8IOSMd1eMEZvnHcOXvB6jtOCxRfLFEdfFPFjPT4b0I /AnwBFQ02EqRQ49OBh1WXl0pQNjCSOyYm+6MT5Mvjw==
X-Google-Smtp-Source: AB8JxZrOhUR2PDMdy+ST+fIJO/WTUX11zWdBz32w1Jv6uU5AMrVP4OA0NLo/VD4A9WkVU8G0hnYFvJ8e58/KgZFNfAQ=
X-Received: by with SMTP id g126mr8554170qkd.108.1524197360867; Thu, 19 Apr 2018 21:09:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Apr 2018 21:09:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Joseph Salowey <>
Date: Thu, 19 Apr 2018 21:09:00 -0700
Message-ID: <>
To: Paul Wouters <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="94eb2c0779a2432df7056a3fda76"
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: Fri, 20 Apr 2018 04:09:24 -0000

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

>  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.
> 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.
[Joe] This can also be done with a new extension code point that defines a
replacement extension that adds the pinning policy.  This seems like viable
possibility, we are not running short on extension code points.

> Nico, Paul and Viktor