[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Update from side meeting on TLS DNSSEC
From:       Viktor Dukhovni <ietf-dane () dukhovni ! org>
Date:       2018-07-19 0:12:49
Message-ID: 20180719001248.GD33554 () straasha ! imrryr ! org
[Download RAW message or body]

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

> THE NON-TLSA 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.

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.

> What happens then? It seems to me that there are two answers:
> 
> 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.

> 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".

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).

> 2. Require/encourage (for some 2119 level) that clients apply TLSA
>    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.

> 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.

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.


[prev in list] [next in list] [prev in thread] [next in thread]