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

Joseph Salowey <joe@salowey.net> Fri, 20 April 2018 04:09 UTC

Return-Path: <joe@salowey.net>
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 3BB8E12D874 for <tls@ietfa.amsl.com>; Thu, 19 Apr 2018 21:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 pCdpWv-6q0rX for <tls@ietfa.amsl.com>; Thu, 19 Apr 2018 21:09:22 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 0AB58127871 for <tls@ietf.org>; Thu, 19 Apr 2018 21:09:21 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id b131so3377951qkg.2 for <tls@ietf.org>; Thu, 19 Apr 2018 21:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.55.132.132 with SMTP id g126mr8554170qkd.108.1524197360867; Thu, 19 Apr 2018 21:09:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.112.198 with HTTP; Thu, 19 Apr 2018 21:09:00 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.21.1804181640480.29344@bofh.nohats.ca>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAOgPGoCbHzuAZra5+i647gtLbR9ZV0-nEE+A7K6e8cUMNjNYtA@mail.gmail.com> <alpine.LRH.2.21.1804181640480.29344@bofh.nohats.ca>
From: Joseph Salowey <joe@salowey.net>
Date: Thu, 19 Apr 2018 21:09:00 -0700
Message-ID: <CAOgPGoBr0-sHyXuu0X5KG_3u_S7sgNFb8NWHPDRKiqn-Ngk1RA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0779a2432df7056a3fda76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xB9wQd6kbyrCQyc-037lw3VA6-s>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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, 20 Apr 2018 04:09:24 -0000

On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters <paul@nohats.ca> wrote:

<snip>
>
>
>  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
>
>