Re: [dane] Behavior in the face of no answer?

[Eric Rescorla <[e-mail]>]

On Tue, May 15, 2012 at 1:08 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> On Tue, May 15, 2012 at 10:04 AM, Martin Rex <[e-mail]> wrote:
>> > Eric Rescorla wrote:
>> >>
>> >> On Tue, May 15, 2012 at 9:52 AM, Martin Rex <[e-mail]> wrote:
>> >> > And as a fallback, browsers could use a TLSA & server-cert lock, i.e.
>> >> > memorizing information from the last visit of a site and using that
>> >> > to perform server endpoint identification in case that DNSSEC lookups
>> >> > fail when roaming.
>> >>
>> >> At which point it's hard to understand how this is better than cert pinning
>> >> via HSTS.
>> >
>> > Such a TLSA & server-cert lock is supposed to be transient substitute for
>> > the lack of DNSSEC connectivity.  That memorized information will need
>> > to be updated whenever full DNSSEC connectivity is available.
>>
>> And the HSTS information can be updated whenever you go to the server.
>
> But the HSTS has a clear hen-and-edd problem:  You can _only_ get updates
> when the verification based on the previous information is still possible,
> otherwise your browser will not establish the communication channel that
> is a pre-requisite to obtain the updated information.
>
> To me it looks like it will be pretty easy to lock yourself out, since
> you have no influence about how frequently the client accesses a site.

1. The pins expire, so you advertise both old and new pins (but continue
to use the old key) until all old pins have expired.
2. There are techniques for breaking the pin.

I'm not suggesting that this draft is perfect, but really these are
fairly obvious
objections that have been discussed extensively in websec.

-Ekr