Op 01-03-18 om 22:50 schreef Viktor Dukhovni: > > >> On Mar 1, 2018, at 2:13 PM, Shumon Huque <shu...@gmail.com> wrote: >> >>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <n...@cryptonector.com> >>> wrote: >>> IF there's an objection to modifying the extension in order to add a >>> pin-to-DANE TTL field, I would propose the following instead: >>> >>> Make the pin-to-DANE be "forever" but make it so it can easily be >>> cleared if DANE is undeployed for the service. >> >> This option is already covered in the draft. It doesn't use the term pinning, >> but does mention caching the existence of DANE on first contact and >> requiring it subsequently (if clients want to do so). >> >> I do not know if the draft authors and/or WG have an appetite to do the much >> more major change suggested by Viktor (i.e in-protocol pinning TTL commitment >> and requiring subsequent denial of existence proof if DANE is removed). > > Avoiding an explicit TTL, and clients unilaterally assuming the DANE extension > will always be available is not IMHO a good idea.> > Websites that initially implement the extension should be able to eventually > stop using it, if for some reason they decide that they no longer want to do > so. While the server can clear the caches of clients that see a denial of > existence of the TLSA records, or proof an unsigned delegation from a parent > domain, without a max TTL there are always clients that have not yet connected > since the policy change, and will be broken indefinitely if the extension is > no > longer delivered. > > Therefore, any long-term caching of a destination's support for the extension > should require server opt-in, and must have a maximum duration.
How do you (all) feel about using the expiry date on the RRSIG for the TLSA to be used for this purpose? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
