> 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.
--
Viktor.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
