Subject: [TLS] Update from side meeting on TLS DNSSEC

From: Joseph Salowey <[email-masked]>
Date: Wed, 18 Jul 2018 18:28:39 -0400

A group met this afternoon to discuss the TLS DNSSEC document.  I
want to thank the participants as I think it was a productive meeting.
Here
is chairs' summary of some of the important points of the discussion from
notes from the meeting.  The second section outlines some behavior that
we need to clarify in the draft.

THE NON-TLS BEHAVIOR
Consider the following TLSA record:

    - domain example.com
    - record for key K1
    - TTL of 3600s

If I retrieved this record over DNS and then connected to example.com
over TLS and it gave me key K2, which is WebPKI certified, but is
different from K1 [0], then I would be required to terminate the
connection per RFC6698 S 2.1.1. Similarly, if I later went to connect
to example.com and it displayed K2, then assuming I still had the
records in my cache, I would be required to terminate the connection.

INTERACTION BETWEEN DNS TTLs AND THIS EXTENSION
The current document is a bit unclear on the question of the behavior
when these records are delivered via TLS as in this draft as-is, i.e.,
without
pinning to the extension. Assume that my client is not configured to
require this extension.

It seems clear that if during the connection, the server
negotiates the extension and provides this record but also key K2, I
need to terminate the connection. It's not clear how this would happen
other than misconfiguration; it wouldn't benefit an attacker.  Now,
consider what happens if I make an initial connection to the server
and it provides K1, but immediately thereafter, I make a separate
connection to the server and this time it does *not* negotiate the
extension, and displays K2.

What happens then? It seems to me that there are two answers:

1. Accept K2 (because it's WebPKI certified).
2. Reject K2 (because it doesn't match the TLSA record).

Given that these have exactly the opposite effect, it seems like
the first thing we need to do is clarify what the expected behavior.
It seems like there are three things we could do:

1. Forbid clients from applying TLSA records received in one TLS
   connection to another TLS connection. This would seem to violate
   the spirit of "this is just another way to deliver DNS records".

2. Require/encourage (for some 2119 level) that clients apply TLSA
   records for as long as tehy remain valid.

3. Say nothing.

We don't think (3) is acceptable. It's not OK for the servers not to
have any idea how clients behave as it can break things. Specifically,
if clients aren't forbidden to do this, some clients might which means
servers have to expect it.  We should start by addressing this issue.
Moreover, it's pretty unobvious that things might behave this way. We
need to decide on the behavior here.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Jul 2018 20:12:49 -0400

On Wed, Jul 18, 2018 at 06:28:39PM -0400, Joseph Salowey wrote:

> THE NON-TLSA BEHAVIOR

TLSA record rollover requirements (and some suggested strategies)
to effect non-disruptive key rollover are described in RFC7671
Section 8.  The short version is that a correctly operated service
will deploy dual TLSA records *ahead* of the introduction of a new
certificate with K2.  For example:

    _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K1)...>
    _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K2)...>

the actual introduction of (K2) happens *after* any cached TLSA
RRsets matching just K1 have expired.  Such "caching" includes any
delays in updating secondary nameservers + TTL of potentially stale
data delivered by secondary servers.  There are various ways of
handling this.  For example the TLSA RRset could include both a "3
1 1" record for the server key (KS) and a "2 1 1" for the issuer
key (KI):

    _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KS)...>
    _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KI)...>

If the server key KS is updated to KS' from the *same* issuer CA,
then the same TLSA RRset will still validate KS' via the shared
issuer key KI.  The hash matching KS can be replaced with the hash
matching KS' during the key rollover without worrying about DNS
caching delays.

When the issuing CA switches keys from KI to KI', the server operator
should obtain a new certificate for the *same* key KS, signed with
KI'.  And deploy that chain.  This time it continues to be valid
by matching KS.  Again DNS caching can be ignored and the TLSA
record update to match KI' concurrently with the issuer key rollover.

It may be useful to write a new DANE operational RFC, covering some
of the insights gained since the publication of 7671 section 8.

> It seems clear that if during the connection, the server negotiates the
> extension and provides this record but also key K2, I need to terminate
> the connection.

Yes.

> Now, consider what happens if I make an initial connection to the server
> and it provides K1, but immediately thereafter, I make a separate connection
> to the server and this time it does *not* negotiate the extension, and
> displays K2.

[ The subtext here is that the client is doing local DNS caching
  (normal DNS no pinning) based on the DNS TTL.  So it already knows
  the TLSA records, and does not even need to ask for the extension. ]

If the TTL on the previously provided TLSA RRs has not expired, the
client is free to apply those TLSA records, exactly as it would had
it (and it is free to try) obtained them via DNS rather than via the
extension.

> 1. Accept K2 (because it's WebPKI certified).

There's little point in doing that.  The client could perhaps proceed
after a user dialogue, or an audit event, on the grounds that some
attackers would hesitate at tamper-evident malfeasance, but that's
rather minimal benefit for the cost of doing DANE.  So the client
could continue as a matter of local policy, but generally should
not.

> 2. Reject K2 (because it doesn't match the TLSA record).

This is the expected behaviour with unexpired TLSA records matching
only K1.

>    the spirit of "this is just another way to deliver DNS records".

Yes, the violation of expectations is quite clear.  The client must
be at liberty to cache.  The TLSA record publisher gets to choose
suitably short TTLs, which the TLS server could further reduce at
its discretion (TTLs are of course not DNSSEC signed, only an uppper
bound on the TTL is covered by the RRSIG).

>    records for as long as tehy remain valid.

The client may of course, at its discretion, cap the TTL it obtains
from DNS at a maximum value lower than provided by the server.  A
client that does not cache TLSA records at all, effectively caps
the TTL at 0.  Clients are not obligated to cache, but may do so.
Caching amortizes the overhead of receiving and processing the
extension data on an initial connection over multiple subsequent
connections.  So caching should be encouraged, but is not required.

> if clients aren't forbidden to do this, some clients might, which means

Since clients are in any case free to obtain the TLSA records via
DNS, the behaviour of clients when records are obtained via the
extension needs to as much as possible match the behaviour of clients
that manage to obtaint the same records directly via DNS.  The only
difference (already noted in the draft) is that delivery via the
extension guards against UKS attacks.

This should be clear upon reflection, and I don't see that there's
anything to be decided.  But to the extent that what's clear upon
relfection is not always clear to the casual reader, some text to
make the unavoidable consequences also obvious may be appropriate.

In summary, clients are free to cache DNS data (received via any
suitable transport) up to the received TTL.  They can act on cached
data as though it were just freshly received.

-- 
	Viktor.