Subject: [TLS] TLS interim meeting material

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Sep 2018 17:40:05 -0400 (EDT)

Hi,

We have made available what we believe is a good starting point for
further discussion regarding tls-dnssec-chain draft.

While I thought we had reached some additional consensus in a side
meeting at IETF 102 that every use case was per definition restrictive,
and that thus downgrade protection was mandatory for this document,
not everyone then present still seems to agree with that.

Nevertheless, we included the text we believe should go into the document.

We can further discuss the preventing of downgrade attacks at the
meeting if people have better ideas or _specific_ concerns about our
current approach.

Paul, Viktor and Nico

Repository https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim

Diff Commits:
https://github.com/tlswg/dnssec-chain-extension/compare/0664d5a608bc2cd82967370160fd4b837dba8fab...vdukhovni:for-interim

The following changes were drafted

* Mandatory Denial of Existence (DoE) or TLSA data (no empty extension data)
   This prevents a downgrade attack and gives a method to "clear pinning")

* Add two byte SupportLifetime to the extension and define the behaviour
   of TLS client and TLS server with respect to this extension. This
   prevents downgrade attacks.

* Explain that receiving validated DoE data implies setting SupportLifetime to 0
   (AKA it "clears the pin")

* Describe how to phase out using the TLS extension without causing problems

* Mandate use of SNI

* Added port information to the extension_data to support TLS servers
   behind NAPT that cannot determine the original port of the origin
   based on the received packet.

* Do not mandate DNS record ordering, it is complicated with CNAME/DNAME
   (the reverse order would actually make more sense for implementors)

* Describe behaviour when a TLS server receives an SNI it does not expect
   (and has no extension data for)

* Describe that TLS clients can obtain TLSA data directly from DNS or
   via this extension and that TLS clients can omit the extension
   completely if they have a non-expired cached TLSA RRset already.

* Clarify TLS servers don't need to do DNS queries themselves, but can
   depend on an external process to get fresh DNS data for populating
   the extension.

Still to do:

* Describe the interaction of TLSA records with CNAME and DNAME as a
   TLSA record can have a CNAME/DNAME at the beginning of the chain or
   at the end. (RFC7671 CNAME chasing does not work well)

* Provisioning TLSA chains with virtual hosting and cname constraints
   (eg domain owner points to Hoster's webfarm via CNAME)

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2018 18:13:57 -0400

I may have a conflict with the call, so I've gone ahead and put some
opinion inline below...

> not everyone then present still seems to agree with that.

Speaking as one of the attendees, I do not agree with that conclusion.

What came to light in that meeting is that the assertive cases of DANE
require that the certificate verification in question use the provided cert
/ trust anchor.  That does not imply any semantic beyond a single TLS
connection; there is no inherent need for pinning.

Please stop using the phrase "downgrade attack".  It's deceptive.  It is
not a downgrade attack in the normal sense, i.e., an attack that causes a
TLS session between a legitimate client and a legitimate server to use
lower security (since the bogus server has to terminate the session).  The
"downgrade" here is simply that the client accepts a certificate from a
trust anchor it trusts.

> Nevertheless, we included the text we believe should go into the document.

Thank you for the explicit text, and thanks for mostly not using the word
"downgrade".  I agree that the first four paragraphs of the "Issues with
Incremental Deployment" accurately characterize the issue here.

I do not agree that we should include the SupportLifetime element.  TBH,
I'm kind of puzzled that it's in here.  It is no different from what has
been proposed in the past.  No attempt has been made to address the issues
that were raised by EKR, me, and others.  And there is clearly no consensus
for it.

It would be more productive for the group to consider a PR without that
addition, that is focused on clarifying that clients should not cache the
information they get in this way and clarifying the relationship between
this extension and record fetching via the DNS protocol.

--Richard

> Repository
> https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim
>
> Diff Commits:
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Sep 2018 20:56:03 -0400 (EDT)

On Wed, 12 Sep 2018, Richard Barnes wrote:

> What came to light in that meeting is that the assertive cases of DANE require that the certificate

That is not what came to light. What came to light was that the
assertive use case does not exist because all TLSA selectors restrict
and that restriction is bypassed when you can force a client not to see
it. Unfortunately, there is no recording and no minutes, so we will redo
that discussion on Friday for the record.

> verification in question use the provided cert / trust anchor.  That does not imply any semantic beyond a
> single TLS connection; there is no inherent need for pinning.

DNS records have semantics beyond a single connection. You cannot tell
whether the TLSA records were obtained via direct DNS queries or the TLS
extension. So you can never make a decision based on purely requesting
the exention and not getting the extension in an answer. The
authoritative source is the DNS. This TLS extension is for those clients
who cannot get native DNSSEC and/or want to reduce round trips. What you
don't want is an attacker to be able to filter the TLS extension out,
thereby removing the TLSA Usage Selectors that restrict the CA, the
EEcert or the public key. That is a classic downgrade attack.

> The "downgrade" here is simply that the client accepts a certificate from a trust anchor it trusts.

A zone owner published a TLSA record. They configure their TLS server to
transport this information. It pins the certificate or root certificate.
Someone managed to undo the TLS server extension. The added TLSA security
is removed by the attacker, while the TLSA data remains active in the
DNS zone. The zone owner's security has been downgraded to "as if no
TLSA record was published". It removed the TLSA restrictions. It's a
downgrade attack.

> I do not agree that we should include the SupportLifetime element.  TBH, I'm kind of puzzled that it's in
> here.

Because I know of only 2 people objecting, and both people have not
articulated their concerns beyond handwaving, claiming they explained it
and refuse to point out where in the TLS list of TLS meeting minutes they
conveyed this information. I don't know where to get this information so
I cannot evaluate it. It would be helpful if you can provide it. Either
a link to previous explanations or a newly written summary would work
for me. What does not work is stating "it is kind of similar to HKPK
and that didn't work, so this wont work either".

> It is no different from what has been proposed in the past.  No attempt has been made to address the
> issues that were raised by EKR, me, and others.  And there is clearly no consensus for it.

Please provide a link to the "issues raised" by you or ekr or the others
that convey why this simple two byte value won't do. Please refrain
from comparision to other vaguely similar protocols and state clearly
the problem with this suggested protocol change, taking into account
that the pinning is for the extension support, and not for pinning any
data whatsoever as the live DNS is the only authoritative data for TLSA
records. We added text that describes how to remove the extension
pinning if you want to do that and describe clearly that you at any
point in time without waiting on anyone or anything else, can remove the
TLSA record from your DNS zone without breaking anything.

> It would be more productive for the group to consider a PR without that addition, that is focused on
> clarifying that clients should not cache the information they get in this way

Any client that obtains DNS data with a valid TTL is allowed to cache
and re-use it as long as the TTL allows it. Irrespective of whether this
is part of TLS or Aviation Carriers. Therefore your statement that the
client should not cache DNS data is fundamentally wrong and would go
against normal operation of the DNS protocol.

> and clarifying the
> relationship between this extension and record fetching via the DNS protocol.

I thought we clarified it? The TLS client works from its DNS cache. It
can decide how to query for TLSA records. It can use regular DNS or this
TLS extension. Or Tor. Or blockchain. When it receives the data and
validates it, it can use the information and put the data in its cache
for the remaining TTL time. For new TLS connections to the same origin,
it can re-use the DNS data from cache and choose to omit the TLS
extension completely while _still_ using TLSA record information to
require a pinned CA or EE cert, thus protecting against a WebPKI
compromise.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2018 22:40:31 -0400

Your responses here reveal a lot of the assumptions that you're reading in
here that are not actually true, e.g., those noted below.

On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters <[email-masked]> wrote:

> require that the certificate
>
> DNS records have semantics beyond a single connection.

DNS records have caching semantics.  Those are only relevant for DNS
resolution.  This is the TLS WG, not the DNS.

> You cannot tell
> A zone owner published a TLSA record.

A zone owner sent a TLSA record in a TLS handshake.  This document says
nothing about what is "published" through any other channel.

> They configure their TLS server to
> I'm kind of puzzled that it's in
> > here.
>

I don't seem to recall you having rebutted that point, though.

> the problem with this suggested protocol change,

The similarity isn't vague; the problems are identical.  Let's look at the
Chrome intent to remove HPKP

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn

They cite, for example:

"""
-

There is a risk of rendering a site unusable.
-

There is a risk of hostile pinning, should an attacker obtain a misissued
certificate. While there are no confirmed or rumored cases of this having
happened, the risk is present even for sites that don’t use PKP.
"""

Both of which are also problems with your pinning proposal.

> taking into account
> addition, that is focused on
> is part of TLS or Aviation Carriers.

The client may do that.  That doesn't mean the server is entitled to expect
the client to do that.  And if the server doesn't expect the client to
cache, then there's no downgrade at all.

> Therefore your statement that the

---

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Sep 2018 00:29:40 -0400 (EDT)

On Wed, 12 Sep 2018, Richard Barnes wrote:

> DNS records have caching semantics.  Those are only relevant for DNS resolution.  This is the TLS WG, not the DNS.

You are resolving a TLSA record via a TLS transport.

> A zone owner sent a TLSA record in a TLS handshake.  This document says nothing about what is "published" through any other channel.

DNS does not publish in "channels". TLSA data either exists or do not exist.

> I don't seem to recall you having rebutted that point, though.

I just did it again but was requested explicitely to do so off-list,
which I grudgingly did and where you were CC:ed by the requester so
you have a copy of my answer. The requester has my permission to forward
it to the public list.

> The similarity isn't vague; the problems are identical.  Let's look at the Chrome intent to remove HPKP

You are still treating this extension as a new independent path to a
(private?) DNS store. As otherwise any comparison with HPKP does not
apply. TLSA records are published in DNS. Clients can obtain them via
a variety of transports. One such transport cannot change the meaning
of the transported DNS data.

> There is a risk of rendering a site unusable.

That is unqualified here so I cannot say anything meaningful about it.

> There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this
> having happened, the risk is present even for sites that don’t use PKP.

We explained _many_ times that this does not apply to _extension pinning_.

It is explained in the draft. Whoever controls the DNS controls what
goes into the tls-dnssec-chain data. So the only way this can contain
rogue data is if the zone's DNSSEC is compromised.

If only the web server is compromised, an attacker can put in whatever
they want, it does not matter. As long as they don't also have the
DNSSEC keys of the domain or any of its parents, it cannot put anything
malicious into the extension that will pass DNSSEC validation on the TLS
client. The attacker can also stop publishing the extension completely.
Regardless, the TLS client detects both as a downgrade attack and will
terminate the connection. It will NOT ACCEPT any extension pinning timer
that the hacker put in place because the tls-dnssec-chain extension
either did not validate or contained only meaningless data. This is a
feature, not a bug. We just prevented you from connecting to a
compromised TLS server.

If the attacker ONLY changed the pin value to 7.5 years (the maximum) with
the existing valid TLSA records, then during the time the server sends
this, clients will believe this. But as soon as they reconnect and get a
fresh TLSA record and/or DoE proof, whatever the extension pin setting is
_then_ will be the new pin setting. So the 7.5 years value will be undone
immediately. So as soon as the legitimate TLS server owner takes control
back of the compromised machine and kicks the hacker out, they can put
back the real (old or new) TLSA record in the tls-dnssec-chain extension
or the real Denial of Existence data if the zone owner decided to also
stop publishing TLSA records. This updates anything the client might
have seen in the past because it is authenticated with DNSESC. There is
nothing the hacker could have sent to clients in the past that would stop
the clients from immediately picking up this new tls-dnssec-chain data.

The only exceptional use case would be a TLS client that believed the
7.5 year pin, didn't connect for a long time, and the TLS server admin
deciding to forgo the tls-dnssec-chain extension completely. The admin
followed the draft advise on how to phase out the extension properly,
which includes running with a zero valus for the previous value's time
(weeks or months). And the admin would do this based on their own value
and not the briefly used rogue value. TLS client could interpret that
as a downgrade attack but it would be very obviously something rogue.
This could be mitigated by the TLS client by either doing DNS lookups
via another transport that provides DoE information, such as DoH or
DoT or even plain DNS, or they could prompt the user when encountering
clearly very long pin times in addition with revisiting a server after
an extremely long time. But remember, it is not entirely a bad thing that
this client is finding out it talked to a compromised server in the past,
and he might want to do some remediation before connecting to the real
server again before the banking trojan previously received steals all
their money.

> Both of which are also problems with your pinning proposal.

You cannot say both. You only mentioned one thing. I cannot refute
"There is a risk of rendering a site unusable."  as it does not specify
any specific kind of risk, problem or attack. As opposed to our very
clearly specified and real downgrade attack.

> The client may do that.  That doesn't mean the server is entitled to expect the client to do that.  And if the server doesn't expect the client
> to cache, then there's no downgrade at all.

If the bouncer at the bar is not expecting fake ID's, there is no downgrade attack
by using fake driver's licenses at all.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Sep 2018 10:59:07 -0400

> resolution.  This is the TLS WG, not the DNS.

It's odd you should say that, in draft -07, which you coauthored,
I see the below rather reasonable text:

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6

   Clients MAY cache the server's validated TLSA RRset or other
   validated portions of the chain as an optimization to save signature
   verification work for future connections.  The period of such caching
   MUST NOT exceed the TTL associated with those records.  A client that
   possesses a validated and unexpired TLSA RRset or the full chain in
   its cache does not need to send the dnssec_chain extension for
   subsequent connections to the same TLS server.  It can use the cached
   information to perform DANE authentication.

> A zone owner sent a TLSA record in a TLS handshake.

No that's the TLS server application, the TLSA record is in fact
published as part of the DNS zone independently of what the TLS
application might later do.  The data is signed at the origin and
can be transmitted over any number of channels and verified at the
destination.

> This document says nothing about what is "published" through any
> other channel.

Because DNSSEC handles both data authentication, and authenticated
denial of existence, the same facts are conveyed about any requested
RRset, regardless of channel.  Unlike other contexts, alternative
facts are detected as "bogus".

> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn

But HPKP is vastly different.  It pins keys, which if never possessed
or lost by the legitimate site operator, preclude the operator from
restoring communication with the client.

Indeed though the issue is typically described as a risk of DoS by
a malicious adversary, the *real* and far more common problem with
HPKP is self-inflicted damage after loss of keys through operational
errors or hardware failure.

Here, all that would be "pinned" is a capability to support the
extension, which anyone could enable at their pleasure, and the
self-inflicted damage is entirely out of the picture, just bring
the service back online and it continues to work!  Delivery of fresh
TLSA records or denial of existence updates or clears any previous
pin with friction.

Furthermore, a client that sees a server violating its pin, rather
than failing, can then choose to pay the latency cost and obtain
valid DNSSEC signed TLSA RRs from 1.1.1.1 or similar DNSpriv servers
(where the extension would be unconditionally supported, as part
of DANE support in DNS over TLS or DNS over HTTP).  If the TLSA
records are proved to not exist, the client can clear the pin.  If
the TLSA records exist and match the server's certificate chain,
the client can continue the connection.

> There is a risk of rendering a site unusable.

This risk is vastly lower for this protocol, and tamper-evidence
that shows that past connections were to a rogue server is frankly
a feature more than a bug.  The user is now informed that he was
previously, or is now, communicating with the wrong server, and
that some action may be required to secure his data.

> certificate.

This is the dramatic strawman version of the risk.  The real problem
is irrecoverable loss of keys.

> While there are no confirmed or rumored cases of this having
> happened,

Precisely, because the real problem is loss of keys, which surely
did happen.

> the risk is present even for sites that don’t use PKP.

This is the strawman risk that sells the deprecation, the real
reason is much more mundane.

> the client to do that.

Nobody is saying the client has to cache, and indeed the server
cannot expect the client to be stateful.

> And if the server doesn't expect the client to

The above is a failure of deductive reasoning.

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 14 Sep 2018 10:18:51 -0500

One other bit of context here: DANE itself doesn't prevent these
"downgrade" attacks in its native form, to say nothing of TLS.

Recall that caching is optional for DNS clients, and the usage of DNSSEC
validation results is up to the application.

Suppose you had an application with the following logic when connecting to
a server:

- Attempt to fetch validated DANE records for the server
- If that succeeds, apply the DANE records on the connection. Do not cache
them.
- If resolution fails, either because of a DNS failure or a validation
failure, fall back to the normal PKI

Such a client has the same security profile as a client using the current
DANE-TLS mechanism. And AFAICT, there is nothing in the current DANE spec
set that forbids this behavior.

The fault, dear Brutus, is not in the TLS transport, but in DANE itself.
Servers simply cannot expect that clients will persist DANE information.

Now, you could argue that we should do better in the TLS transport.  But
now you're in the realm of feature requests, not security vulnerabilities,
and feature gaps should not be blocking on a document that already had WG
consensus.

--Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Sep 2018 11:33:54 -0400

I'm afraid the below is a strawman hypothetical.  Please stop.

DNSSEC lookups either return the truth or explicitly
*FAIL*, they don't just return "neutral" results.

As, for example, explained in RFC7672, when TLSA lookups fail the
mail delivery is deferred, and may ultimately bounce if the condition
persists beyond the message queue lifetime.

The same is repeated in RFC7673:

   https://tools.ietf.org/html/rfc7673#section-3.4

   o  If the TLSA response is "bogus" or "indeterminate" (or the lookup
      fails for reasons other than no records), then the client MUST NOT
      connect to the target server (the client can still use other SRV
      targets).

Indeed in RFC6698 (base DANE specification) the state machine in Appendix B.2
is:

  https://tools.ietf.org/html/rfc6698#appendix-B.2

   (TLSArecords, ValState) = DNSSECValidatedLookup(
     domainname=_[port]._[transport].[name], RRtype=TLSA)

   // check for states that would change processing
   if (ValState == BOGUS) {
     Finish(ABORT_TLS)
   }
   if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
     Finish(NO_TLSA)
   }
   // if here, ValState must be SECURE

   ...

> On Sep 14, 2018, at 11:18 AM, Richard Barnes <[email-masked]> wrote:
> 
> One other bit of context here: DANE itself doesn't prevent these "downgrade" attacks in its native form, to say nothing of TLS.

This is simply false.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Sep 2018 09:09:07 -0700

> *FAIL*, they don't just return "neutral" results.

In theory perhaps, but as a practical matter, no browser client, at least,
can do DNSSEC hard fail, because the rate of organic DNSSEC interference is
too high. Indeed, this is the primary reason why DANE over TLS is
interesting.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 Sep 2018 16:13:02 +0000

*   In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC hard fail, because the rate of organic DNSSEC interference is too high. Indeed, this is the primary reason why DANE over TLS is interesting.

But that doesn’t make Viktor’s statement wrong, does it?  Browsers are ignoring the FAIL state; they’re not getting a “neutral” result, are they?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Sep 2018 12:16:55 -0400

> On Sep 14, 2018, at 12:09 PM, Eric Rescorla <[email-masked]> wrote:
> 
> In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC hard fail, because the rate of organic DNSSEC interference is too high. Indeed, this is the primary reason why DANE over TLS is interesting.

Yes, of course, no disagreement there.

But the result is not lots of browsers with half-baked implementations
of DANE that ignore DNS lookup failures and accept the downgrade risk,
but rather no implementation of DANE in browsers via direct DNS lookups,
which makes sense given the current state of the Internet "edge".

And so here we are evaluating an alternative approach, that might also
address latency concerns, support raw keys while addressing UKS attacks,
...  And, to the extent possible, should be downgrade resistant.  Unfortunately,
only after contact, but we'll have a chance to hash that out at the meeting soon
enough...

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Sep 2018 12:23:25 -0400 (EDT)

On Fri, 14 Sep 2018, Eric Rescorla wrote:

> In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC
> hard fail, because the rate of organic DNSSEC interference is too high. Indeed, this is
> the primary reason why DANE over TLS is interesting.

Right, the goal is hard fail on DNS manipulation. So it makes no sense
that the extension we are writing to accomplish that, would not mandate
it. There is always local policy overrides, whether for testing or
otherwise.

Paul