Re: [Dance] CRLs/OCSP and DANE at RIPE84

[Michael Richardson <[e-mail]>]

Geoff Huston <[e-mail]> wrote:
    > With no ability for revocation to take effect immediately (as there is
    > no revocation per se) then surely it is in the client’s interest to
    > have the server credentials to be checked frequently to ensure that
    > compromised credentials are quickly timed out. That would suggest to me
    > there is a tradeoff between cache lifetimes and the potential
    > cache-bound afterlife of compromised credentials that have been erased
    > from the server.

I would claim that there is no *security* benefit to setting the TTL bigger or
smaller on the EE TLSA records.   The interesting TTLs and timeouts are on
the DNSSIG, NS, DS DNSKEY records that lead to the end record.

I think that an interesting aspect of this is that we can vary the TTLs up
and down over the lifespan of a zone.

For a typical MP2P (device to cloud) IoT deployment, the question of how
often the A/AAAA record of the service is updated is the upper limit.
If you change IP addresses (for load balancing, make-then-break upgrades,
...) of the server then devices have to re-connect, and the server can easily
make a new determination about the client certificates.  It can even have a
deny-list (essentially, a CRL...)
Also, servers tend not to receive connections from clients who have no
Internet. (As huge swaths of Ottawa have been since a record setting storm
last Saturday afternoon)

For the deployments of P2P IoT, which this works aims to support,  we want
TTLs to be as high as possible so that a local cache will have the records we
want.  Ideally, the local cache survives the storm on batteries :-)

DNS servers do not, (AFAIK) go out to refresh records before they expire.
It's always demand driven: not just the TLSA lookup, but all the NS and
DNSSEC tracking that goes to validate the record.  Of course, that's local
behaviour, which could be changed.   A recursive server could be taught to go
seek fresh DNSSIG RRs at the half-way point before they expire.

Are there operational reasons why a DNSSIG record might have a TTL that was
bigger than the duration of validity?  I would think typically it would be
less, often much less.  Like 1 day TTLs vs 30 day signatures.
Of course, TTLs are relative and DNS signatures are absolute times.

I have often thought of DNS updates as rippling through the Internet
according to some "lightcone" diagram where c is determined by TTL.
Then TLS or IKEv2 connections look like wormholes that pierce space and
connect two histories together.   This is what I was thinking about when
RFC4025 and RFC4322 were being written, and the great Type Code Rollover was
occuring.  But, I recall my explanation was poorly communicated by me at the
time.



--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide