> On Oct 16, 2018, at 9:07 PM, John Levine <jo...@taugh.com> wrote:
>
> Something like "require DANE certs until time N" should be plenty.
>
> Remember that you can also unpin by publishing a signed NXDOMAIN or
> NODATA. Since you need to have DNSSEC working to get the pin in the
> first place, that doesn't seem unduly onerous.
To be clear the "require DANE certs" above only holds so long as the
TLSA records remain published. Since providing proof of non-existence
clears the pin, what's really pinned is the extension (and even then,
many clients will be able to recover by making independent DNS lookups).
So there's no discord here between "require DANE certs" and "just
pin the extension", the two are equivalent, because the former
really means "require the extension and if signed TLSA records are
present require DANE, else, with valid denial of existence, clear
the pin".
So regardless of how we frame it, the behaviour after first contact is
the same, that is:
* Apply DANE in a downgrade-resistant manner when published
* Drop pins and revert to default behaviour given valid denial of
existence.
So far, no substantive issues have been noted with the proposed pinning
approach to downgrade resistance (which bears no resemblance to HPKP).
All that remains is agreement on a maximum time limit (by setting the time
unit to max_time/2^16), and perhaps some sort of gradual scaling up of
that limit (if concerns about hijacking before the extension is widely
available in server software are deemed sufficiently compelling).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
