<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 28, 2016, at 9:41 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 27, 2016 at 8:33 PM, Peter Bowen via Public <span dir="ltr" class=""><<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I propose that this be mitigated by adoption a two prong rule for CAA:<br class=""></div><div class="">1) By default CAs must treat the presence of CAA records which do not include them as “hard fail” and not issue</div><div class="">2) However, if the CA has issued an Enterprise EV RA certificate containing a valid authorization domain, logged it in at least <n> public CT logs, the CA may treat CAA for those FQDNs and Wildcard DNs matching the authorization domain as “soft fail” and issue even if the CAA record specifies otherwise.</div><div class="">The CA must internally log any certs that are issued after a “soft fail” and report such via any iodef in the CAA record. </div></div></blockquote><div class=""><br class=""></div><div class="">Your last sentence regarding iodef suggests you believe this isn't already required.</div></div></div></div></div></blockquote><div><br class=""></div><div>It is not required today, as CAs are not required to check for CAA records.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">The second concern is around issuance latency. If a certificate has dozens of subject alternative names or a CA is issuing massive number of certificates the full CAA checking algorithm can be slow,</div></div></blockquote><div class=""><br class=""></div><div class="">I'm sorry, but I'm going to specifically object to this statement. It's not been shown to be slow - merely, some members have postulated that it "might" be slow, without showing concrete evidence or data to the contrary, and in the face of experience otherwise.</div><div class=""><br class=""></div><div class="">If members want to support this line of inquiry, data needs to be provided.</div></div></div></div></div></blockquote><div><br class=""></div><div>OK. I used a machine with a locally running caching resolver. I then did the following as a test:</div><div><br class=""></div><div>Fetch top-1m.csv.zip</div><div>Unzip it</div><div>head -n 200 top-1m.csv | cut -d, -f2 | sed -r -e ’s/^/www./‘ > top200.txt</div><div>echo 'nameserver 127.0.0.1’ > resolv.conf</div><div>time (ruby -e 'IO.foreach("top200.txt"){|l| l.strip!; loop {|x|puts l + "."; l=l.split(".")[1..-1].join("."); break if l.empty?}}' | while read N; do drill -c resolv.conf "$N" IN TXT; done)</div><div><br class=""></div><div><div>real<span class="Apple-tab-span" style="white-space:pre"> </span>1m5.424s</div><div>user<span class="Apple-tab-span" style="white-space:pre"> </span>0m0.476s</div><div>sys<span class="Apple-tab-span" style="white-space:pre"> </span>0m0.296s</div></div><div><br class=""></div><div>Running the last line again (e.g. after warming the named cache):</div><div><br class=""></div><div><div>real<span class="Apple-tab-span" style="white-space:pre"> </span>0m15.105s</div><div>user<span class="Apple-tab-span" style="white-space:pre"> </span>0m0.444s</div><div>sys<span class="Apple-tab-span" style="white-space:pre"> </span>0m0.404s</div><div><br class=""></div><div>One CA on the call said they have an active contract that requires them to support issuance rates of 6M per hour (approximately 1670 per second). Even if you reduce this by orders of magnitude, CAA doesn’t make sense.</div><div><br class=""></div><div>Also consider the offline issuance process — e.g. a CA running at a factory, disconnected from the Internet. How is this to be handled?</div></div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><font size="2" class="">This should allow customers who have a need for massive issuance rates of unique hostnames to enter a CAA record at the common suffix label allowing the CA to have a near 100% cache hit rate on DNS look ups.</font></div></div></blockquote><div class=""><br class=""></div><div class="">This seems a premature optimization based on unfounded concerns from those without implementation experience. As such, I have trouble weighting this request at all as reasonable.</div></div></div></div>
</blockquote><br class=""></div><div>I’m sure the numbers above can be improved by reusing processes, but it does show there are valid concerns.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><br class=""></body></html>