On Wed, Apr 8, 2015 at 6:35 PM, Ryan Sleevi <[email protected]> wrote: > On Wed, April 8, 2015 3:00 pm, Phillip Hallam-Baker wrote: >> http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> It is a pretty straightforward proposal: >> >> * Use the CAA record with either the hsts or hpkp tag >> * Put the same text you would have put into the CAA record value field >> >> There are a few differences in interpretation. All we are trying to do >> here is to help people to close the 'secure after first use' hole, not >> replace. >> >> Given that we have quite a bit of use of HSTS headers, providing a >> mechanism for publishing this in the DNS looks like being the obvious >> approach. > > I believe it was so obvious that the IETF has already beat you to the > punch - RFC 6698. > > If it is, as you claim, to close the "secure after first use" hole - which > is the first time I've heard it called that, versus the "trust on first > use hole", since "secure after first use" isn't so much a "hole" as a > "nice thing to have" - then it requires secure DNS, which is back to the > DNSSEC problem, and if you have DNSSEC and the ability to query arbitrary > records on the client, well, you might as well just use DANE.
Who said anything about DNSSEC being required? DANE has totally different syntax and semantics. Adding this mechanism is very straightforward, just post the same parameters that would be presented in the HTTP headers in DNS. The mechanism can even work both ways, a server can use this for discovery. People in WebSec and DANE decided on different approaches. I see no reason to foist the inability of the two groups to agree on one approach onto users of the specs and certainly no reason to hobble WebSec which is now widely used to make space for an experimental protocol that has failed. > Of course, you might mean this as a "How do I discover support" (e.g. for > building preloaded lists), in which case, that problem already has a > myriad of solutions. Having more than one solution for a problem is usually a good reason to pick one. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
