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

Shumon Huque <> Thu, 12 April 2018 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F303127876 for <>; Thu, 12 Apr 2018 15:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n8mYiMDdVgn4 for <>; Thu, 12 Apr 2018 15:34:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D881C12422F for <>; Thu, 12 Apr 2018 15:34:03 -0700 (PDT)
Received: by with SMTP id 142-v6so896578itl.5 for <>; Thu, 12 Apr 2018 15:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=H0C5aThvI/CnqF4EmWl9s51/KqcnfSPxB5w9JCNoHxQ=; b=dxlYrWQP9Nxkho+Qlzc3HX49GCuLApqz2EMw4egNpP7zXEFhLTrnf69r3ac2CZgs0d faWQ3rEsEBH2QuZ5kJdX7Y+HkDphABc1QtR2VabBuvkfAOUt7PLJH3AHb9An2i7tNYCJ QPkKZbAxAMefpZvuhz5KoA5se54CO76Iw+xNgjGHEp7bOk6lokWdE7TBNifKBVcSk0Ob OsWhbcR9rgYwGoaTs8bzL/VVJmgcLjPwWFcf8iF29ve5Z+gbr1xiUWE+j5hbfXXkAl3T HVrZiQao6bCiKcBIo+WvIgaIpqFcDnu79CzqRK8368L1k/6u2V6gKZKCbiJ7rloKoV7q /SnA==
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; bh=H0C5aThvI/CnqF4EmWl9s51/KqcnfSPxB5w9JCNoHxQ=; b=q9Ng3J/l6pJUZZqkp4UyzE9ICRC7ciTzDlPFGYDakNPPZR4SWmWOLiKQbthGU2hcWf hZ8eiw+a1Pen0M/hvQWLcaPpdaMYwmTxCN+oe6xD0DoJy7RFgjoR+Y8+SxaU+HFEVuWu jgbIVUHXDhMGeDA+75Qak3ZRHMwdzTKQNd5weHcKfhyR1hDuA9Uut8XQH9U8138SX2bN 4VEGxyI1jV/BpkKU99PclJoLjAgrHiqc/0H7av29lKGw9kFspCsArNYmhc8C0CiBMEF2 g+P4DVU7w/kDBPdjlgX2MTeNq+9+x9547ksygjmcV0f5C7aKQiTuU2N8wveJOSEzZlRC Ny5g==
X-Gm-Message-State: ALQs6tB5q2sHR5UFx3LXpSOwsja+BNsMOuSj5WvhOqJZIFRHBowf/kq9 r9V0fbIc2s1t/nyShMf4GE39T1RCSjE1t/eBj5h3ug==
X-Google-Smtp-Source: AIpwx4/SqQeJ1Uje02Kj/L9O0CyKQEsk8uB5dqwBNktb/I+z6xCCaFnev/R4PCXVtntjIZVmwvlN0z3gjpXLV7H7fPU=
X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr2751840itg.61.1523572442785; Thu, 12 Apr 2018 15:34:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 Apr 2018 15:34:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <20180410235321.GR25259@localhost> <> <> <> <> <> <> <> <>
From: Shumon Huque <>
Date: Thu, 12 Apr 2018 18:34:02 -0400
Message-ID: <>
To: TLS WG <>
Content-Type: multipart/alternative; boundary="0000000000003deea20569ae5a33"
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: Thu, 12 Apr 2018 22:34:15 -0000

On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni <>

> > On Apr 12, 2018, at 5:47 PM, Martin Thomson <>
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes they wish to see?
> Why publish a crippled specification that needs immediate amendments that
> would
> require a second parallel extension to be defined and used by clients and
> servers
> to fix the issues in the current specification?  And the time to get that
> second
> extension would effectively delay the publication of a usable protocol.
> The protocol as described prohibits denial of existence responses.  Willem
> acknowledged (thus far in an off-list message) that that's an oversight
> that
> should be corrected, and such a correction is the substance of option (A).

As I said in a previous message, I'll support relaxing the language in the
to permit delivery of authenticated denial chains for future applications
of the
protocol - I think that's just adding or modifying a couple of lines to the
and no wire changes.

Someone actually argued to me in person that the draft could be read as
not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but
if we want to allow it, I think it's best to be crystal clear.

If we can get consensus on that, then you could write a separate extension
to convey the pinning information and describe the additional behavior.
in combination with the existing draft would satisfy your use case. That
would in
fact be an incremental addition, and not a whole new parallel protocol.

Implementers that are opposed to pinning would then just ignore this second
draft (and not bother with the authenticated denial part of the first
draft). Since it
seems pretty clear you're not going to consensus on adding pinning to the
draft, I think you should pursue this approach. And then you can try to
implementers and deployers, now or in the future, that they need to use both
extensions in combination.

Shumon Huque