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

[Martin Thomson <[e-mail]>]

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 <[e-mail]> wrote:
>
>
>> On Apr 4, 2018, at 1:50 PM, Joseph Salowey <[e-mail]> 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:
>
>   https://service.networking4all.com/hc/en-us/articles/115001319589-Wat-is-DANE-en-DNSSEC-
>
> 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:
>
> COSTS:
>
>   * 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
>
> BENEFITS:
>
>   * 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls