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

Willem Toorop <> Thu, 12 April 2018 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3F1F129C6C for <>; Thu, 12 Apr 2018 11:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WZ7WY1m8npvM for <>; Thu, 12 Apr 2018 11:20:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE0CA126DED for <>; Thu, 12 Apr 2018 11:20:24 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id E11C88AA7; Thu, 12 Apr 2018 20:20:22 +0200 (CEST)
Authentication-Results:; dmarc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1523557222; bh=9afQagqi9OoSAIxmNvayZXrVSblrwhHD08Zsg+JnxbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PeeTnteop7rapGUbL5dYQr9GvPK3ieMAqwhQpP8Q7KKl3lt/FxBZgF1NdJq1aHyVz l7r7kVyiydqGQ17cj1ej8QdmSs3R56qgIC+//Furiqw3Ninzwb+oHT2bvCm05BhjJT rF39+HyjsMvPT944SyXuDAPros/z+0+AlJ9sjHi0=
To: Paul Wouters <>
Cc: "<>" <>
References: <> <> <>
From: Willem Toorop <>
Message-ID: <>
Date: Thu, 12 Apr 2018 20:20:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 18:20:27 -0000

Sorry for being confusing.  I meant to say full Denial of Existing is in
the draft implicitly already (because of the reference to DANE
authentication according to RFC6698 and RFC7671 (which do mention it) in
Section 6).

I do like the idea of STS for this extension (and augment it with the
more restrictive DANE use cases), but I'm unsure about the security of a
built-in version.

I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
[draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
conveyed in a ServerHello message secure when it would be just for SSL?

I can see this might be different for the DANE use case because of the
signed statements that come alongside the TTL, but for example...
In case of built-in STS with the extension, what does a 0 TTL mean?

  - When 0 has been the only value seen ever, it is clear to me that the
    mechanism is equivalent with what we have in the draft now, but..

  - When another value has been seen before, is a value of 0 then enough
    to clear the pin?  Or would a DoE proof (or insecurity proof)
    alongside it be necessary?

    In case of the latter, what does that mean for sites that do have
    DANE records, but no servers that support the extension?  Can they
    be hampered (for an indefinite period) by a MiTM?  That would be
    really bad for DANE deployment.

Op 10-04-18 om 17:22 schreef Paul Wouters:
> 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.
> Paul