Re: [TLS] TLS interim meeting material

[Paul Wouters <[e-mail]>]

On Wed, 12 Sep 2018, Richard Barnes wrote:

> 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

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