Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Willem Toorop <[e-mail]>]

Op 01-03-18 om 22:50 schreef Viktor Dukhovni:
> 
> 
>> On Mar 1, 2018, at 2:13 PM, Shumon Huque <[e-mail]> wrote:
>>
>>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <[e-mail]> 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?