On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote: > The security considerations of security policy mechanisms are all > about not shooting yourself in the foot.
No, they aren't. They're also about mitigating the worst that an "attacker" could do. > That is why I propose to not consider the record valid for any longer than its DNS time to live. And now your TTL and the client caching policy of that TTL becomes part of your security considerations. > 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. All I see are negatives here compared with "the status quo". > > 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. Agreed. And so how are you going to bootstrap security over an insecure connection, without dealing with all of the threat scenarios explicitly and implicitly addressed by the documents you're trying to supplant/augment? I would encourage you to consider the exercise of "What is the worst that an attacker could do with this policy", as well as "What's the strongest level of security I could achieve", and hopefully in both cases you'll see that the flaws are somewhat fundamental if delivered over an insecure transport. And if you had a secure transport (which you don't, but we'll assume the IETF will fix all this in good time), then you *could* use DANE, and the only issue becomes one of syntax. Which is not an intrinsicly good argument - and in fact, generally a bad one (syntax can be hidden by tools, but specs - and bad specs - live forever) _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
