> On Apr 25, 2018, at 10:02 AM, Willem Toorop <wil...@nlnetlabs.nl> wrote:
>
> We're actually working on
>
> https://github.com/tlswg/dnssec-chain-extension
>
>
>> if there's interest in me doing that. Below I list OLD/NEW text
>> chunks with the name of the section in which they fit.
>
> If you do, could you please make separate pull requests for denial of
> existence and another one for the lifetime field.
I'll try to get that done. Thanks for the right repository pointer.
> Are you sure 16 bits is enough? Other STS specs appear to use seconds
> for the max-age directive.
Yes, I'm sure that 16-bits is enough. This is because an extension support
lifetime measured in seconds makes little sense, once this gets below an
hour it is commensurate with and often smaller than the TTL of the TLSA RRset.
There's no point in "pinning" the extension for a shorter time, the client
can just cache the TLSA records instead. The point of the extension support
lifetime is for ongoing downgrade resistance *beyond* the DNS TTL of the TLSA
records. 16 bits of hours is sufficient for a commitment between 1 hour and
7.5 years.
> They are also extensible with new directives
> (which have been introduced too, to overcome initial unforeseen
> limitations (i.e. preloading)).
Here I'm proposing a simple and general mechanism broadly applicable to
all TLS applications. It would cover, for example, downgrade protection
for SUBMIT, POP, IMAP and XMPP clients. There is deliberately no support
for including sub-domains as that would likely drag in the public suffix
list as a co-requisite and complicate deployment.
Preloading is rather browser-specific, and can be handled at the HTTPS
layer if desired. Preloading only scales to the extent that it is not
too popular.
> Why do you require the SOA? It is not needed for the denial of
> existence (or insecurity) proof. NSEC ttls tell how long to cache the
> non-existence so it is not needed for the minimum field either.
You're probably right about that, the NSEC or NSEC3 records are required
to carry the same negative TTL (also limited by the RRSIG original TTL
and RRSIG expiration). So probably the SOA can be omitted, with the NSEC
or NSEC3 records first after the relevant DNAME/CNAME chain.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
