[cabfpub] Pre-Ballot 125 - CAA Records

[Rick Andrews]

Stephen, IMO the intent of the ballot has always been (a). If anyone
disagrees, please speak up.

 

-Rick

 

From: Stephen Davidson [mailto:S.Davidson at quovadisglobal.com] 
Sent: Tuesday, July 15, 2014 12:31 PM
To: Rick Andrews; Geoff Keating
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

 

Thanks guys.  I think it still needs to be resolved which approach the
ballot will take: a) CAs needing to state their CAA approach, or b) CAs
needing to implement auditable CAA checks and state their policies for
handling the info.

 

Regards, Stephen

 

 

From: Rick Andrews [mailto:Rick_Andrews at symantec.com] 
Sent: Tuesday, July 15, 2014 4:05 PM
To: Geoff Keating; Stephen Davidson
Cc: cabfpub
Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records

 

I agree with Geoff. CAs will typically issue a DNS query for just CAA
records, not ANY. And if you’re worried about the impact to the client
that’s looking up the address for www.example.com in DNS, they also will not
be affected by the addition of CAA records because they’ll be asking for A
or AAAA records, not ANY.

 

I believe there’s no technical size concern here. I think the original
comment came from Sigbjørn at Opera. If you’re still on the list, Siggy,
would you please comment? Or perhaps someone else from Opera can comment?

 

I know of no other issues, so perhaps we can proceed with balloting this?

 

-Rick

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Geoff Keating
Sent: Monday, June 30, 2014 10:18 AM
To: Stephen Davidson
Cc: cabfpub
Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records

 

 

On 30 Jun 2014, at 8:17 am, Stephen Davidson <S.Davidson at quovadisglobal.com>
wrote:

 

During the CABF discussion about CAA in June 2013, a browser representative
pointed out that companies may hit against size constraints when using CAA:

 

Adding the records increased our authoritative nameserver's DNS response
from an already juicy 458 bytes to supreme juicyness of 506 bytes (512 bytes
is still somewhat of the limit, at the very least resource usage will
increase when topping that).

And besides, we've seen that before of course, and our TXT SPF record is the
main offender here, but 506 byte responses is probably on the "winning" side
when it comes to selecting authoritative DNS servers for DNS amplification
attacks. Or spoken more generally: Maybe the CABForum should discuss how
eager the community is to add a potential massive load of additional records
to the root element of a zone/"domain".

If you use more than one CA for signing "https" certs, this can quickly
explode in size all on itself, without the help of SPF entries in the zone.
I'd guess this needs to be discussed.

 

The technical discussion dropped off at this point.  I believe it bears
further analysis.

 

I presume here we're talking about an ANY query, since a CAA response itself
is usually small by itself.  In that case it should be considered that an
ANY query for icann.org is 5278 bytes, and even TLDs like com. or us. are
1555 bytes and 538 bytes respectively.

 

In actual use there should be no problem since real queries (as opposed to
those intended for DoS) will not ask for the CAA record and so won't get it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140715/6009c00f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6073 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140715/6009c00f/attachment-0001.p7s>