[cabfpub] CAA concerns (and potential solutions)

[Ryan Sleevi]

On Fri, Oct 28, 2016 at 9:52 AM, Peter Bowen <pzb at amzn.com> wrote:

>
> OK.  I used a machine with a locally running caching resolver.  I then did
> the following as a test:
>
> Fetch top-1m.csv.zip
> Unzip it
> head -n 200 top-1m.csv | cut -d, -f2 | sed -r -e ’s/^/www./‘ > top200.txt
> echo 'nameserver 127.0.0.1’ > resolv.conf
> 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)
>
> real 1m5.424s
> user 0m0.476s
> sys 0m0.296s
>
> Running the last line again (e.g. after warming the named cache):
>
> real 0m15.105s
> user 0m0.444s
> sys 0m0.404s
>
> 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.
>

Considering your above example is dominated by process spawning overhead,
it would suggest that your metric example is proof that you can implement
CAA inefficiently, not that CAA is itself inefficient.

For the less technical members, the overhead of invoking a new process
every time (Peter's "do drill -c ..." line) is known to be several orders
of magnitude slower than a single process to implement this.


> Also consider the offline issuance process — e.g. a CA running at a
> factory, disconnected from the Internet.  How is this to be handled?
>

This is a more useful and productive line of inquiry, and helps highlight
concrete areas where blanket CAA requirements may not be desirable. Thank
you for this, because it shows that even discussions related to caching are
insufficient for this use case, and argues very strongly for the need for
policy-based solutions, rather than technical.


> I’m sure the numbers above can be improved by reusing processes, but it
> does show there are valid concerns.
>

I have trouble reconciling these two statements. The fact that there can be
an inefficient implementation is not a proof that there is not an efficient
or reasonable one, especially in something so critical to Internet
infrastructure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161028/0a317d28/attachment.html>