<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 9, 2017 at 4:04 PM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>I don’t think any of these apply at the IETF level; I’m sure the IETF is not going to specify a ‘what if you only wanted a little bit of DNSSEC’ configuration</div></div></blockquote><div><br></div><div>Why not? If DNSSEC is not deployable in practice by CAs, that's something the IETF needs to reckon with and include in its specs. We can't allow DNSSEC deployment problems to become an elephant in the room that nobody wants to bring to the IETF because there are hard-liners there.</div><div><br></div><div> > I think the IETF RFC should specify fail-closed because that’s the only fully secure approach</div><div><br></div><div>I agree, and I pushed for this when adopting the CAA ballot at CA/Browser Forum. This is what Let's Encrypt currently implements. However, during voting on the CAA ballot, some CAs expressed that they couldn't deploy that, which is why we have an exception for retried failures. This is exactly why we need those CAs to participate at LAMPS. If deploying fail-closed CAA is impractical, IETF should acknowledge that and write it into the next RFC. But that can't happen without LAMPS participation from CAs that fail open.</div></div></div></div>