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

Martin Thomson <> Thu, 05 April 2018 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC92A127076 for <>; Wed, 4 Apr 2018 19:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4yQB3ZhmEA5j for <>; Wed, 4 Apr 2018 19:07:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1B85126B72 for <>; Wed, 4 Apr 2018 19:07:58 -0700 (PDT)
Received: by with SMTP id i28-v6so25581753otf.8 for <>; Wed, 04 Apr 2018 19:07:58 -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=nSha1E6bphe0AnjFR4dApS/xI/WbSOdqlWCOz1E2XME=; b=bRSyiSuN8fUEOA30XjCFcbDhDv2qBvvT1a0dJ/D4nC6J0pbdHLp6VquUdBB833iVCl ed8dq3tkkGHQ3cCYUCpWh2LoVx19vXXV0ce0n3y0dNmXjBViPZNNpdbWQjh42W8QlCx9 j9iDB4hr3zUcc4ZpNAv4pKXm0+yEF1h9ziJ2apobjYTPBOwGOWyDfvXImWa4OYnKuzvC k3R3jcrmtdYdqcBOcXYmd7UPXhlJVxuRzyvOQXtapUJINw4U7J2uEfwWvyLAsgXX44cs 2UIcM/sfiIIaWrMCK1gwoPPrdyHJPWtFwbQGi2SFUiy0N1P20eEupezrxSkO1IDkoTjz DpWg==
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=nSha1E6bphe0AnjFR4dApS/xI/WbSOdqlWCOz1E2XME=; b=dYdLiBVGtS1D0gXOMhDJ4X+mVaSibXdsisYv3hFY/JuP3vnVjDNxYf/eeOeG+iwEoP XfFuvoY4tMyI9C7PBPBfH7tDO2Nq2IAcjRR38Z24/bIJkEPcQSVtnjtrUchzVpmO6GwD ZIP/jeSlxwjACR6AnLBk4E21mO20jpkkrHsuBdjtJZ1E2wrQLpE+zBbhFv+KeMl/bARG 1Od/uU4gi+93y9GR2S9x2JSKz70ZJN+8weNb5vaRjbLRCyuPmaEHNdvC+G7TBcN61Jfn WupGlIdGEDso7pLx/WIf1vVFeCm61op3wPVtQqCgrpyqy2xPDYU7ELBPAx6EnUq00QzQ k3jg==
X-Gm-Message-State: ALQs6tAElkjua6NQ3WpNkHjlZLHEsLOtR50tyOCHDcE+nKEk8xJzMFzS TWFRe4rW/m5yv17iJnMTYvJvAwD1TUrPEh4dVxfWqA==
X-Google-Smtp-Source: AIpwx4/bIZNGCSTU484DkqRR/No0OgFQAnmHx6y1WjJcZP83ZcU38Ce4ptxRhJx5MCb6B03sPu9HR/A+D5YMCZBr66E=
X-Received: by 2002:a9d:2150:: with SMTP id l16-v6mr5994278otd.394.1522894077562; Wed, 04 Apr 2018 19:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 4 Apr 2018 19:07:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Thu, 05 Apr 2018 12:07:57 +1000
Message-ID: <>
To: TLS WG <>
Content-Type: text/plain; charset="UTF-8"
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, 05 Apr 2018 02:08:02 -0000

Given what we've learned about pinning (it is being removed from
browsers), this seems like a bad plan to me.

Your cost benefit analysis seems about right though.

On Thu, Apr 5, 2018 at 9:27 AM, Viktor Dukhovni <> wrote:
>> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <> wrote:
>> - Recommendation of adding denial of existence proofs in the chain provided by the extension
>> - Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> These are indeed the immediate proposed fixes, and ultimately the consensus call will be about
> whether the fixes should be formalized and integrated or the document advanced as-is, but before
> we consider them in a vacuum, I'd like to explain in some detail *why* they are needed.  This
> requires firstly an examination of why the extension is needed in the first place, and what
> use-cases it should address.  This will be detailed below, but first:
>> This is a consensus call on how to progress this document.  Please answer the following questions:
>> 1) Do you support publication of the document as is, leaving these two issues to potentially be addressed in follow-up work?
>> If the answer to 1) is no then please indicate if you think the working group should work on the document to include
>> A) Recommendation of adding denial of existence proofs in the chain provided by the extension
>> B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
>> C) Both
> For the record, (C) both.  And now to explain why:
> The first thing to understand is why this extension is needed in the first place.  A partial
> answer can bee seen in the introduction to the draft. Please pardon burying the lede, below
> I quote from the text of the introduction in order of presentation, but the main point is closer
> to the end:
>   -----------------
>   This draft describes a new TLS [RFC5246] [TLS13] extension for
>   transport of a DNS record set serialized with the DNSSEC signatures
>   [RFC4034] needed to authenticate that record set.
>   -----------------
> We should note that an empty record set (NXDOMAIN or NODATA) is still
> a record set, and DNSSEC *authenticates* denial of existence, and it
> is necessary to also support denial of existence, in order to support
> downgrade-resistance against "TLSA-stripping".  The reason is that this
> extension is not being introduced into brand new internet in which the
> CA/B forum WebPKI does not exist and DANE will be the *only* way for
> TLS clients to authenticate servers.  For this extension to coexist
> with the WebPKI clients will need to be able to *some* servers via
> DANE and others (those that don't have DANE TLSA records) via the
> existing WebPKI.
> Suppose that, in the absence of authenticated denial of existence,
> and clients being able to rely on continued support for the extension:
>    * As will be the cast for most existing applications, the client
>      is willing to use the WebPKI when DANE TLSA records don't appear
>      to be availble.
>    * An attacker is able to obtain a fraudulent WebPKI certificate.
> Then the attacker can impersonate the target server by leaving out
> the extension and presenting just the fraudulent WebPKI certificate,
> and the client will have to accept this even when the real server
> previously employed the extension and provided TLSA records.
> What the above establishes is that in mixed environments, i.e.
> almost all use-cases for this specification, TLSA records provide
> no additional protection, if WebPKI fails, security is compromised
> even with DANE.
> Some have argued that this is OK, that even though the above
> "restrictive" use-case is unavailable we still get an "additive"
> use case, where servers can be authenticated with DANE when
> that happens to be present and otherwise WebPKI.  Sadly, that
> use-case is largely a mirage.  Firstly, given the existing
> dominant client base that only supports WebPKI, any server
> would in any case still need WebPKI certificates (say from
> Let's Encrypt), and that will suffice for all clients both
> those that support DANE and those that don't.  Thus enabling
> DANE on the server, only makes it possible to impersonate
> the server if DANE is compromised, but does not defend against
> WebPKI compromise.  So the server gets more complexity, and
> reduced security, and maybe even increased risk of failure
> if the TLSA records are managed carelessly and fail to match.
> No rational server operator will employ the "additive" mode.
> Some DANE idealists might do it to signal their support for
> the technology, but this will be futile, they'll get no real
> benefit from doing so.
> Continuing on with the introduction:
>   -----------------
>   The intent of this
>   proposal is to allow TLS clients to perform DANE Authentication
>   [RFC6698] [RFC7671] of a TLS server without performing additional DNS
>   record lookups and incurring the associated latency penalty.  It also
>   provides the ability to avoid potential problems with TLS clients
>   being unable to look up DANE records because of an interfering or
>   broken middlebox on the path between the client and a DNS server
>   [HAMPERING].  And lastly, it allows a TLS client to validate the
>   server's DANE (TLSA) records itself without needing access to a
>   validating DNS resolver to which it has a secure connection.
>   -----------------
> Here we see the promise of being able to get by without having
> access to a validating resolver, but validating resolvers deliver
> both signed data when present and signed proof of non-existence when
> the requested records are absent.  But most importantly:
>   -----------------
>   This mechanism is useful for TLS applications that need to address
>   the problems described above, typically web browsers or SIP/VoIP
>   [RFC3261] and XMPP [RFC7590].
>   -----------------
> This plainly shows that browser HTTPS was a motivating use-case
> for the extension.  Indeed earlier mention of latency concerts is
> also based on the reasons why browsers don't (want to) do DANE even
> when direct DNSSEC lookups are possible.
> Not just browsers, no existing application can adopt specification
> incrementally.  Even if the extension is required in the application,
> it is unrealistic to expect that all server domains will rapidly
> adopt DNSSEC.  At the moment there are ~6 million DNSSEC-signed
> domains, substantially concentrated in northern Europe, with
> fairly thin adoption generally (only ~800K domains out of ~120
> million in .com).  An application that expects the extension
> should expect to not find TLSA records for many servers it
> connects to, indeed many server domains will be unsigned, and
> the server would only be able to present denial of existence
> for the DS records of a parent domain, proving its domain
> "insecure" (in DNSSEC terms).
> The modifications in (A) and (B) are most similar to STS (not HPKP)
> and harden DANE-authenticated HTTPS against downgrade to just DV,
> and make going to all the trouble of supporting the extension at
> the server a tangible security benefit.  Absent such a benefit,
> no reasonable server operator will implement the extension. Just
> deploying a WebPKI certificate, which is necessary in any case,
> provides the same protection with less effort.
> The pin-time in (B) also allows servers to signal a zero pin time,
> and thus indicate an incomplete deployment, reducing breakage when
> clients find the extension partially deployed, but decide to expect
> it anyway for security reasons.
> The pin (pinning just the boolean presence of the extension, like
> STS pins availability of TLS) would not pin any of the TLSA data,
> that's subject to the normal, and typically short, DNS TTLs should
> the client choose to cache the presented DNS records.  Its lifetime
> would be measured in hours (not seconds) and I'd go with a 16-bit
> value that represent any time from 0 hours (partial deployment)
> to 65535 hours which is close to 7.5 years.
> The pin is set (or reset to a new value) when the server performs
> a handshake in which the extension is present with a non-zero TTL,
> and either provides matching TLSA records or a valid denial of
> existence (and is authenticated via WebPKI).
> For browser HTTPS, (in a separate specification) in might make
> sense to limit DANE support to just the "restrictive" case,
> PKIX-TA(0) and PKIX-EE(1).  There are many in the TLS and
> browser communities who don't trust the security of DNSSEC,
> and would be reluctant to authenticate sensitive browser
> connections based on DANE alone.  That's fine.  Just as
> DANE for SMTP limits the scope to DANE-TA(2) and DANE-EE(3)
> for reasons explained in section 1.3 of RFC7672, the converse
> can reasonably be argued for browsers.  This suggests even
> more strongly that DANE stripping matters (if "restrictive"
> turns out to be the main purpose of DANE in that space) and
> that this specification needs to harden DANE against downgrades.
> I should also mention that there is a user community that expects
> the IETF to make DANE support work in browsers and which would be
> once again left frustrated with the specification failing to meet
> their expectations.  For a published example:
> but I've certainly been party to various conversations with users
> where want DANE to work for their Web servers and browsers, the
> finer points to be worked out by this WG and browser/web server
> developers.
> And yet, as it stands, the deployment cost-benefit analysis for this
> extension in existing applications plays out as follows:
>   * You still manage WebPKI certificates to support the majority of existing clients.
>   * If the WebPKI is compromised, you're compromised.
>   * If DNSSEC is compromised, you're compromised
>   * You pay the complexity cost of also supporting the extension
>   * You might present incorrect TLSA records and the connection might fail even when
>     it would otherwise succeed with WebPKI
>   * Nothing other than bragging rights that you're cool enough to deploy a shiny new technology
> I think that users deserve better than that, and that the extension should have tangible
> security benefits not only in greenfield applications where DANE is the mandatory authentication
> mechanism, but also in legacy applications where deployment would necessarily be incremental and
> initially slow.
> Yes, there is not today an immediate backlog of implementations waiting to adopt the
> specification into legacy spaces.  The same was true for DANE in RFC6698 when the
> specification was completed in Aug 2012.  The first substantive implementation work
> did not begin until Feb/Mar of 2013 and its later adoption was substantially driven
> by the unanticipated news in June of that year.
> We don't know what the future will bring, the WebPKI is certainly looking much more
> fragile lately than it did in the past with multiple failures at various CAs, and
> the health of the ecosystem threatened by a new economic reality.  It is prudent
> to have alternatives "in the wings", even if there is not an immediate rush to
> adopt.
> This specification should be sufficiently robust to support not only the immediate
> narrow DPRIV use-case, but also other use-cases.  What's more adding support for
> (A) and (B) in no way burdens the immediate adopters, all they suffer is a short
> delay in the publication of the final document.  They can ignore the pin TTL,
> and given mandatory TLSA records are certainly not compelled to generate denial
> of existence given that they're planning to have TLSA records.  It may however
> turn out that even there a capability to vend denial of existence could prove
> useful.
> In summary, the present specification fails to address its motivating use-cases,
> provides no incremental adoption path, and is only narrowly fit for purpose with
> some new applications, but provides no alternative security mechanisms in the
> existing application spaces where direct use DNSSEC by the client (bypassing
> this extension) is not an option.
> This is why my "hum" is for both (A) and (B), i.e. (C).
> --
>         Viktor.
> _______________________________________________
> TLS mailing list