<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 2:38 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8903501892520400500WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(68,84,106)">Ryan, I don’t think it makes sense to me, but to be fair, it might be due to my limited knowledge of DNS. As for technical complexity, it seems simpler than CT ;^)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(68,84,106)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(68,84,106)">I wasn’t proposing re-implementing DNS within our validation infrastructure. As far as I know, we already have recursive resolvers in our infrastructure (I think they’re also called stub resolvers), and again, as far as I know, they implement caching according to the DNS spec. Even if we didn’t have recursive resolvers in our infrastructure, and we used, say, Google’s 8.8.8.8, isn’t that also a recursive resolver that caches? Consulting my internal recursive resolver will be a bit faster than consulting one outside of my infrastructure, but it seems to me that the net effect is the same; caching prevents clients from seeing immediate changes made at the authoritative name servers.</span></p></div></div></blockquote><div><br></div><div>I was trying to head off the suggestion, that say, within your validation database, you do an authoritative lookup, see the TTL at some large value (e.g. 48 hours), and then record that information within your validation database.</div><div><br></div><div>With respect to the distinction between stub and recursive resolver, I was specifically referring to the notion that some element of the CAs infrastructure itself would be responsible for the recursive hierarchal resolution - that is, root servers to authoritative servers, etc. The implications of the term "stub resolver" would be that, say, you might trust your ISP - or Google's 8.8.8.8 - to correctly perform that resolution, which I don't think is the desirable outcome here with respect to auditability nor the netsec requirements.</div><div><br></div><div>In either event, I think we're in agreement that DNS allows caching, and my point is that I think it's unwise to add *additional* caching.</div><div><br></div><div>An example of additional caching which was discussed in the F2F, and which is practiced by CAs today, but I think is potentially problematic, is that the CA records in their validation database that they performed the CAA check on some date (e.g. 1/1/2016), but then ignore DNS TTL and use that cached result for some indefinite period.</div><div><br></div><div>This is not specific to CAA either - we know that CAs rely on cached validation of domain ownership for up to 39 months after issuance. This is useful with respect to general DNS cases, as for some TLDs, WHOIS information simply isn't available, or isn't programatically accessible. So I can understand the argument for allowing some degree of caching of what may be a manual process. However, CAA doesn't require that manual inferrence, and every domain can express CAA records themselves, and the TTLs can be controlled by the domain administrator, so I was suggesting that such a form of a caching - admistrative rather than technical - is undesirable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8903501892520400500WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(68,84,106)">Which concerns of Jacob’s are you’re referring to? The fact that LetsEncrypt does CAA checking at validation but not issuance time because it’s too expensive?</span></p></div></div></blockquote><div><br></div><div>Jacob didn't suggest that it was too expensive - <a href="https://cabforum.org/pipermail/public/2016-October/008576.html">https://cabforum.org/pipermail/public/2016-October/008576.html</a> instead states because it's externally facing, slow, and unreliable. That may have been what you meant by expensive, but given that it's an overloaded term, I thought it best to point directly to what Jacob stated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8903501892520400500WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(68,84,106)">It sounds like your ideal case would require everyone to use DNS in a way that it wasn’t intended to be used (no caching). That makes me think that DNS isn’t the best place to keep this type of info, but I can’t think of a better place.</span></p></div></div></blockquote><div><br></div><div>Sorry I wasn't clear, because that's not at all what I was saying. I was suggesting that the ideal world is no caching *outside* of the methods of caching defined within DNS. That is, no administrative databases of "Oh yeah, we checked this via DNS a week ago, so we don't need to" - but instead, using DNS resolvers (within the CAs control and scope) to perform the lookup - and, incidentally, supporting caching as defined by DNS.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-8903501892520400500WordSection1"><div><div class="gmail-h5"><p class="MsoNormal" style="margin-left:0.5in"><u></u></p></div></div></div></div></blockquote></div><br></div></div>