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

[Warren Kumari <[e-mail]>]

On May 15, 2012, at 4:24 PM, Eric Rescorla wrote:

> 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 web sec.


Agreed, and if folk would like to object further, I'd suggest:
1: *reading* the docs and discussions in web sec and then, if you still have a beef, 
2: taking the discussion to web sec…

W

> 
> -Ekr
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>