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

Shumon Huque <> Tue, 10 April 2018 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A484F12D877 for <>; Tue, 10 Apr 2018 11:43:07 -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 A1symcUXNiAa for <>; Tue, 10 Apr 2018 11:43:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B4FF12D777 for <>; Tue, 10 Apr 2018 11:43:05 -0700 (PDT)
Received: by with SMTP id 142-v6so17255568itl.5 for <>; Tue, 10 Apr 2018 11:43:05 -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 :cc; bh=/IR7GBUV4UukmmycyCK8aD3RAxD4WtkeXNJkk65/7jA=; b=l/kiQaDcb7tcWMFDiUJIrr6kDcSbPvpHCnHqN3k1+ZgHAqU8AqOOl0WitG+W/Mih4n cEYQDgElL9e3FfM0aFzUedjyq5SMjy6VNCjAm/PSI+PAfv5mWXW2+weyYI9roh6jp0f3 jvTwYyoNXTKNhYZQFs+tqhDyN/mWOuZrdNcBl+ClOf81bO6Tsyp6IkrD9euSRXUX1Ger pKlpg92mTblVABNdiOAQMka46xonVlQVUB0n8pK94HeEEKE7Ln/j/dhF8sfe8YUpPyAo 1g6QfNKsjVuPyltIxZfPjN3MDb73o+foDGQIG6A2RFP90Ca35Rh+/x5sBmiAMwfFEq2z UrIQ==
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=/IR7GBUV4UukmmycyCK8aD3RAxD4WtkeXNJkk65/7jA=; b=iJQ6EhB8+T+ls9q5hBttZAejLtxS8+EPqEE3MbhAtX00Df5/4NFt+dFuHRrPBDTAjH XvQpLyM0jPYATAfxzZTOzakAxgb2yQrU9INMoS/VXhVO6zPSFPw620wUmqU6z0Rkssrz bnm7aQbkzK7FfWRox85PuUnscirG3Tk0ahOr4TDj2Cp/VmNwoxPYZPoofc/JqqzBKF6A TVdK8Ncxl6+cl44HfJ/x0vf5cfOFzakenbIzdx/wHCNoBZI8rq0q1L0B5E47GqA5k8O0 zZfboTD6yzQZ6cKF/o/iCQQ5A69Z4UwZ0dfr4KyiGfb/G9gig9tzzb60KEUNpOtU6fNI sAig==
X-Gm-Message-State: ALQs6tBcK45KlWkk34TwPV1nSC+fyiscSGOR/nNKgvG0HH+Jd2XGmJvq lXt+Uz8F4e0NvgeigiWxDo8PlC05JO9vo3GwChHDQA==
X-Google-Smtp-Source: AIpwx4+nGu8r8XYDCoX5ziLz500I6ntApsqbFStSVmAhjKXAjj1aXxW1His/iPn0U9seZIpNXNslhNI0Y4WVN2NJLHM=
X-Received: by 2002:a24:209:: with SMTP id 9-v6mr670730itu.93.1523385784615; Tue, 10 Apr 2018 11:43:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Apr 2018 11:43:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Shumon Huque <>
Date: Tue, 10 Apr 2018 14:43:03 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: Willem Toorop <>, "<>" <>
Content-Type: multipart/alternative; boundary="0000000000008c4833056982e41e"
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: Tue, 10 Apr 2018 18:43:08 -0000

On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters <> wrote:

> On Tue, 10 Apr 2018, Willem Toorop wrote:
> I just want to clarify one misconception in Willem's statement. See my
> previous emails to thist list for my full arguments on this issue.
> The chain extension already contains verification of Denial Of Existence
>> proofs, because that is needed for verifying wildcard expansions.
> This might confuse people. I am talking about denial of existence of any
> TLSA record. You are talking about proof of non-existance of other TLSA
> records besides the one you are returning. These are completely
> different issues. I just want to ensure people realise when I said we
> need proof of non-existence, that people do not read your line "already
> contains this" as me being wrong.
> It does not explicitly mention the fallback to non-PKIX with a Denial of
>> Existence proof or insecurity proof for the TLSA record, because it is
>> (currently) irrelevant when the extension could simply be left out too.
> So that's not one bug, but two bugs. Defining them out of scope is not
> what we should do. For instance, the document could already assume that
> the proof of TLS extension (pinning) is going to be solved elsewhere,
> and therefor a full denial of existence proof in this document would be
> valuable.
> The document does not specify what to do when it does not find a TLSA
> record to include. It does state:
>     If the server is configured for DANE
>    authentication, then it performs the appropriate DNS queries, builds
>    the authentication chain, and returns it to the client.
> So if the server is configured for DANE, and it only finds denial of
> existence proofs of its own TLSA record, what is the expected behaviour?
> This hints at returning the proof of non-existence, but clearly even the
> authors are now saying they did not mean this and a server is not
> required to do this. Clearly the text needs clarification, and if it
> then leaves out denial of existence, it needs a justification for that
> as well.

Personally, I would be okay with relaxing/clarifying the language in the
draft a bit so that it does not rule out the possibility that a DNSSEC
(NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be

I wonder if that, together with a new extension that can convey DANE
pinning information is a way forward ..

Shumon Huque