On Wed, Apr 8, 2015 at 8:41 PM, Ryan Sleevi <[email protected]> wrote: > On Wed, April 8, 2015 4:40 pm, Phillip Hallam-Baker wrote: >> Who said anything about DNSSEC being required? > > If it isn't, then it's not equivalent. > > HSTS requires an error free connection - in part to ensure the policy is > securely delivered.
No it is required to know that the policy is consistent. Which you certainly want to do if a security policy is going to be cached for 6 months. The security considerations of security policy mechanisms are all about not shooting yourself in the foot. That is why I propose to not consider the record valid for any longer than its DNS time to live. > HPKP requires an error free connection that is consistent with the policy > expressed - in part to ensure the policy is securely delivered and > correctly formed. > > If you don't require secure delivery of that, then you're not developing a > secure solution. I am not delivering a perfectly secure solution but neither is DANE. All I am looking to do is to improve on the status quo with as little extra work as possible. If DNSSEC is ever deployed AND it becomes visible to clients then it could be relevant to this spec. But right now DNSSEC is not a viable mechanism for authenticating DNS RRs at the client. There are other mechanisms that work just fine for the client-resolver link, including our own proprietary protocols and the proposal we have made to DPRIV. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
