[cabfpub] Pre-Ballot 125 - CAA Records

Sun Sep 7 02:42:27 UTC 2014

On Sep 6, 2014 7:31 PM, "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com>
wrote:
>
> You are asking CAs (including Trend Micro) to add a requirement to the
BRs that all CAs must state whether or not they support CAA, and what their
policy is.  Based on your prior comments and messages, I think you strongly
believe that all CAs should refrain from issuing any certs to a customer
that has a CAA record that does not include the CAs name.  Correct me if
I’m wrong.
>

That is not what this proposal states, which is why such comments and
concerns are entirely unfounded.

>
>
> Several CAs (and at least one browser) have expressed concerns over the
past year every time CAA was raised as a possible new requirement that it
could be used improperly by some CAs in the manner I have outlined.  That
is the chief impediment to broad support for CAA.  The proponents of CAA
need to listen to the concerns of the companies it would most directly
affect, and not ignore those concerns.   It needs to be addressed now,
before the CA/Browser Forum is asked to give its imprimatur to CAA as a
mandatory requirement – even as outlined in Pre-Ballot 125.  That is simple
to do.
>

That is not what this Ballot proposes, which is precisely why such concerns
are unfounded.

>
>
> Google wants to see CAA implemented – become mandatory, probably – for
its own reasons, but you are not considering the possible adverse, and very
anticompetitive, effects on the companies that are asked to look at CA
records.  The bad behavior I have described has no defenders, so the same
ballot that gives legitimacy to CAA should also set rules of the road so
that CAs don’t use CAA in an anticompetitive way to gain market advantage.
It’s that simple, and can be done now.  No delays.
>

Kirk,

For a group composed of people with significant legal experience, I'm
surprised your counsel would recommend or endorse such a proposal.

Regardless, this behavior - which is NOT a risk imposed by Ballot 125 - can
entirely be dealt with within a CAs CPS, without requiring the Forum - a
group comprised chiefly of CAs - to interfere in the business relationships
of their competitors, which is exactly why your proposal is so clearly
unacceptable.

A CA that shares these concerns, which I certainly agree some have raised,
can fully disclaim within their CPS whether or not they respect CAA, and
under what conditions, without the potential of exposing this group and its
members to legal risk of interference.

A reasonable alternative proposal, which is demonstrably unnecessary for
this ballot, would be for the Forum that, if it should ever require CAA,
provide a series of circumstances upon which a CA is free to ignore
conflicting CAA data. This avoids any of the legal risk, while still
providing ample and meaningful defense against a behavior that itself has
seriously questionable legal standing for any CA that were to engage in it.

What is clear and unquestionable is your proposal opens a whole host of new
legal risks that, if added, would run significant risk of torpedoing the
ballot. There is no need to engage in that.

>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Saturday, September 06, 2014 7:17 PM
>
> To: Kirk Hall (RD-US)
> Cc: CABFPub
> Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records
>
>
>
>
> On Sep 6, 2014 6:26 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> >
> > Ryan, you need to moderate your words – you are becoming unnecessarily
offensive on this list.
> >
> >
> >
> > In no way is my proposal a “stalling tactic” – it’s a serious proposal,
and you should treat it as such.  If the amendment is quickly adopted,
Trend Micro and many other CAs will likely support this ballot and it will
probably pass with no delay.  If not, the ballot may fail.
> >
> >
>
> Kirk,
>
> What you continue to leave critically unaddressed is how the current
ballot makes your doomsday scenario any more likely.
>
> The critical fact is that it does not. It in no way alters the shape or
risk of this, which is why it is demonstrably unnecessary.
>
> You continue to paint the amendment as a way to address a hypothetical
concern that "some members" may have, while refraining from actually
stating or addressing if you object to the current form as written, and
why. There is absolutely no need to engage in the amendment if this ballot
would pass as is, and if the amendment is meant to address some concern,
then it would be a far better use of everyone's time to meaningfully engage
in discussion of those concerns on their merits.
>
> The scenario you have proposed - in which the CA/B Forum would be taking
an unprecedented and unthinkable step of attempting to regulate CAs
communications with their customers, an act that certainly raises very real
concerns about the nature of this group - can already be addressed clearly
and unambiguously by any CA who shares your concerns, and in the present
form.
>
> I see no reason to open this group to the legal risk, let alone the risk
of failure of the ballot precisely because of that risk, for a hypothetical
scenario that you continue to pose, yet refuse to address why it cannot be
solved in the current ballot.
>
> For the very obvious reason that such tactics of using the CA/Browser
Forum to interfere in other CAs communication with their customers is an
obvious and clear gross overstep of purpose. And because such an amendment
is demonstrably unnecessary given the ability of CAs to disclaim such
practices, if parcticed, by others within their CPS, it is wholely
unnecessary and downright negligent to support such a proposal.
>
> These are strong words precisely because your amendment is so
unquestionably a significant new approach to regulation, with seriously
negative precedent, and which would seriously jeopardize an otherwise
simple ballot that merely seeks to set out documentary practice before any
attempt at normative regulation.
>
> Surely you can recognize the significant value of making small
improvements in uncontroversial ways, and allowing the body of experience
and practice then further guide the regulatory framework. For example, your
stated concerns can easily be addressed through other means which do not
raise the verg real spectre of anticompetitive behavior that your
amendment, as written, does.
>
> >
> > This is a pre-ballot, which is *intended* to bring suggestions from
Forum members for improvements.  So that’s what my proposed amendment was.
A pre-ballot is not a steamroller.
> >
> >
> >
> > To date, no CA has objected to the amendment, or said it wants to
engage in the bad actions that my amendment would outlaw.  If we are going
to test CAA, we need acceptable “rules of the road” on CA behavior so CAA
will be a success, and will not be used as a blocking tactic (which would
probably eliminate all support for CAA in the future).
> >
> >
> >
> > And no, you never did outline your specific objections to the proposed
amendment in your prior email – you just said you didn’t want any delay.
> >
> >
> >
> > To put it directly: Do you think CAs should be able to engage in the
practices that would be prohibited by my proposed amendment?  If yes, why
would this behavior be acceptable?  If no, then you should support the
amendment.
> >
> >
> >
> > The proposed amendment again:
> >
> >
> >
> > In order to make certain that CAA is not used by CAs in an
anticompetitive manner, no CA shall (1) request or suggest that a customer
include the CA’s name in a CAA record for the domain in question if the
customer does not already have a CAA record that includes the name of one
or more other CAs but omits the CA’s name, (2) obtain authorization from
the customer to act on the customer’s behalf (directly or by request to the
customer’s DNS operator) to create a CAA record for the customer that
includes the CA’s name for the domain in question if the customer does not
already have a CAA record that includes the name of one or more other CAs
but omits the CA’s name, or (3) request or suggest that a customer include
the CA’s name in a CAA record for other domains not the subject of the
customer’s certificate order or obtain authorization from the customer to
act on the customer’s behalf (directly or by request to the customer’s DNS
operator) to create a CAA record for the customer for other domains not the
subject of the customer’s certificate order.
> >
> >
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi at google.com]
> > Sent: Friday, September 05, 2014 10:19 PM
> >
> > To: Kirk Hall (RD-US)
> > Cc: CABFPub
> > Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records
> >
> >
> >
> >
> > On Sep 5, 2014 10:07 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> > >
> > > Ryan, you haven’t explained to your objection to my suggested edits.
> > >
> > >
> > >
> > > With my edits, we may find substantial support for CAA among most
CAs.  Right now, the support is concentrated mainly with the larger CAs who
have established customer bases that CAA would protect.  With my  proposed
amendments, not only larger, established CAs, but also smaller and newer
CAs may support CAA and this ballot.  That would be a good thing, right?
> > >
> > >
> > >
> > > No CA has said it will only support the CAA ballot if CAs retain the
right to push customers to create a CAA record in their behalf, or the
right to create a CAA record for their customer – right?  So most CAs may
support my proposed amendment and pass the CAA ballot with that language
included.
> > >
> > >
> > >
> > > So my question to you is – do you yourself oppose the proposed
amendment?  If so, why?
> > >
> > >
> > >
> > > If you don’t oppose the amendment, then there’s really not a problem
and the ballot may pass with the added language.
> > >
> > >
> >
> > Kirk,
> >
> > I think my objections are pretty clear in my response. Your attempt to
further engage in this highlights precisely why such last minute proposals,
which are very clearly unnecessary and unrelated to the proposal, may be
seen as stalling tactics designed to undermine an otherwise simple proposal.
> >
> > Let's try to make some productive progress in the Forum, and focus on
the small, sustainable gains we can make by not introducing unnecessary
complexity or contentious requirements, which an attempt to regulate what a
CA can say communicate to their customers (the first of its kind in the
Forum) inherently is.
> >
> > I value your contribution, and would be happy to discuss further as a
separate ballot, but absolutely cannot support its addition to a simple
documentary ballot.
> >
> > >
> > > From: Ryan Sleevi [mailto:sleevi at google.com]
> > > Sent: Friday, September 05, 2014 5:31 PM
> > >
> > > To: Kirk Hall (RD-US)
> > > Cc: CABFPub
> > > Subject: RE: [cabfpub] Pre-Ballot 125 - CAA Records
> > >
> > >
> > >
> > >
> > > On Sep 5, 2014 5:20 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> > > >
> > > > Ryan, I just noticed your statement at the bottom of my proposal
about a separate ballot for the amendment I proposed.
> > > >
> > > >
> > > >
> > > > When the Forum has discussed CAA in the past, it was noted that in
many large enterprises (the most likely candidates for CAA), the people who
buy certificates are not the same people who manage the company’s DNS – and
in fact, they may not work on the same continent or know each other.  So it
may be very difficult for CAA records to be updated – a potential
competitive handicap for new CAs, or CAs trying to sell to an organization
that buys its certs from others.
> > > >
> > > >
> > > >
> > > > Several of us tried experiments within our organizations, and found
this was so (no communication between the two groups).  It was also noted
that many enterprises buy certs from multiple CAs, sometimes a development
team needs a cert on very short notice, etc. – CAA could greatly complicate
this with no real benefit if any CA tries to get an exclusive CAA record
for itself and use it as a competitive blocking tool.
> > > >
> > >
> > > This proposal does not concern itself with that. It is merely a
requirement to document policies.
> > >
> > > Your concerns - and certainly, they have been raised by other CAs -
about the possibility of a CA to abuse its position in a market are only
applicable when CAs are actually required to check CAA, which the Forum has
shown there is significant opposition by CAs to do.
> > >
> > > >
> > > >
> > > > I’ll tell you want I’ll do at my next CA, Voracious CA – Section
18(d)(ii) of my Subscriber Agreement will say “You hereby authorize us to
contact your DNS operator and create a CAA record with our name in it.”
Hah!  I’ve just created a potential competitive block for all my
competitors, and the customer never knew.  And I’ll have my sales team
always say “Hey, you know how you can REALLY increase your security?
Create a CAA record and put our name in it.  That prevents rogue hackers
from getting certs in your valuable domain <a totally non-target domain for
hackers>.   I’ll email you instructions containing the name and phone
number of your DNS operator – you’ll get a discount on your next cert if
you do!”  Hah – I just fooled the customer into creating a CAA record that
only contains my name.
> > > >
> > > > Or if I also offer hosting services, I’ll bundle it all, with an
automatic CAA record thrown in.
> > > >
> > > >
> > >
> > > And there are plenty of other ways to game the system that the BRs
don't deal with.
> > >
> > > Respectfully, Kirk, I would simply ask whether or not you will
support a simple ballot, without your modifications, that simply requires
CAs to document their policies.
> > >
> > > CAs that are concerned of such abusive (and, dare I say, unrealistic)
behavior have full liberty to take whatever measures you find suitable in
your CPS. This simply gets your position on record.
> > >
> > > I see no reason to stall this ballot, which would inevitably be
another 6 months of delay (we have been talking about this since the
Mozilla F2F nearly a year ago), when it makes no such requirements on any
CA.
> > >
> > > >
> > > > For CAs to impose CAA on other CAs without protective language like
what I propose presents serious competition law issues.  No one yet has
said “it’s a good idea for CAs to tell their customers to create CAA
records, or to do it for them,” so the proposed language is a way to make
the CAA ballot palatable to many CAs (especially smaller or newer CAs).
> > > >
> > >
> > > Please reread the ballot. You, and the other CAs who have repeatedly
raised this concern as a way to dismiss CAA, have been listened to, which
is why the ballot is so narrow and focused as it is.
> > >
> > > Any CA that shares your view of the unlikely situation occurring can
deal with it in their CPS. If you feel it actually is a problem, or it
would prohibit a ballot that required CAA enforcement (which, again, this
does not), then we can spend another 6 months working on this language and
hearing the same arguments we have heard for the past year+.
> > >
> > > To be clear, I'm fully sympathetic to your fear, even though I find
it extremely unlikely, but I think its entirely disconnected and orthogonal
to a simple ballot as this, which simply requires documentation of
practices.
> > >
> > > Surely you can recognize the value in both such documentation and in
the Forum occasionally reaching consensus and forward progress in real and
pressing issues, rather than be stalled by years of debate and uncertainty
while trying to boil the ocean of CA practices.
> > >
> > > I think we have two endorsers at this point, so I would be thrilled
to see this taken to a vote. If your fears prevent you from voting on such
a simple change, then we can certainly revisit this and discuss how to
assuage them, but I think if you and others who may feel the same read the
proposal, you will realize nothing unreasonable is being requested of you.
> > >
> > > >
> > > >
> > > > From: Ryan Sleevi [mailto:sleevi at google.com]
> > > > Sent: Friday, September 05, 2014 4:43 PM
> > > > To: Kirk Hall (RD-US)
> > > > Cc: CABFPub
> > > > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records
> > > >
> > > >
> > > >
> > > >
> > > > On Sep 5, 2014 4:35 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> > > > >
> > > > > Ben, I have an amendment to propose, in the form of the language
below (to be added at the end of your language in Sec. 8.2.2.  A word of
explanation:  every time CAA has come up as a topic of discussion at a CAB
Forum meeting or on a call, one or more CAs and browsers
> > > >
> > > > I have yet to hear a browser express this concern.
> > > >
> > > > > have expressed concern that CAA could be used as a "blocking"
strategy by CAs in order to add hurdles for another CA to sell certificates
to the same customer.  The main way this could happen is if a CA induces a
customer to insert its name to a CAA record when there is no CAA record at
the time for the customer (or even worse, adds its name to a blank CAA
record in the customer's name -- this could happen if the fine print of the
Subscriber Agreement authorizes the CA to insert its name in a CAA record
for the customer and the customer has no idea this is happening).  Another
potential abuse would be if a CA got its name put in blank CAA records for
other domains registered to the customer that are not even part of the
pending certificate order so that other CAs would find it more difficult to
sell certificates for those domains.
> > > > >
> > > > >
> > > > >
> > > > > There seems to be strong sentiment among CAs and browsers for
some language prohibiting this potential practice as anticompetitive.
> > > >
> > > > I have yet to hear a browser express this concern.
> > > >
> > > > > The decision of whether or not to even have a CAA record should
be solely up to the customer, not the CA.
> > > > >
> > > > >
> > > > >
> > > > > With this explanation, here is my suggestion for additional
language for this pre-ballot:
> > > > >
> > > > >
> > > > >
> > > > > In order to make certain that CAA is not used by CAs in an
anticompetitive manner, no CA shall (1) request or suggest that a customer
include the CA’s name in a CAA record for the domain in question if the
customer does not already have a CAA record that includes the name of one
or more other CAs but omits the CA’s name, (2) obtain authorization from
the customer to act on the customer’s behalf (directly or by request to the
customer’s DNS operator) to create a CAA record for the customer that
includes the CA’s name for the domain in question if the customer does not
already have a CAA record that includes the name of one or more other CAs
but omits the CA’s name, or (3) request or suggest that a customer include
the CA’s name in a CAA record for other domains not the subject of the
customer’s certificate order or obtain authorization from the customer to
act on the customer’s behalf (directly or by request to the customer’s DNS
operator) to create a CAA record for the customer for other domains not the
subject of the customer’s certificate order.
> > > > >
> > > > >
> > > > >
> > > > > What do you think?  Does this meet everyone’s stated concerns?
> > > >
> > > > If you feel strongly about this, I feel it is worth a separate
ballot. I do not support burdening this ballot with that language.
> > > > >
> > > > >
> > > > >
> > > > > [Also – typo below – “(section 4.1 for CA’s still conforming to
RFC 2527)” should be “(section 4.1 for CAs still conforming to RFC 2527)”]
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: public-bounces at cabforum.org [mailto:
public-bounces at cabforum.org] On Behalf Of Ben Wilson
> > > > > Sent: Friday, August 29, 2014 2:02 PM
> > > > > To: Sigbjørn Vik; Rick Andrews; Geoff Keating; Stephen Davidson;
Ryan Sleevi (sleevi at google.com)
> > > > > Cc: cabfpub
> > > > > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records
> > > > >
> > > > >
> > > > >
> > > > > Picking up where we left off .. attached is the redlined version
that I think is closest to where we were on this issue:
> > > > >
> > > > >
> > > > >
> > > > > 1.  In Section 4 of the Baseline Requirements, add a definition
for CAA Record as follows:
> > > > >
> > > > >
> > > > >
> > > > > CAA Record: The Certification Authority Authorization (CAA) DNS
Resource Record of RFC 6844
> > > > >
> > > > > (http:tools.ietf.org/html/rfc6844) that allows a DNS domain name
holder to specify the Certification Authorities
> > > > >
> > > > > (CAs) authorized to issue certificates for that domain.
Publication of a CAA Resource Record allows public Certification
Authorities to implement additional controls to reduce the risk of
unintended certificate mis-issue.
> > > > >
> > > > >
> > > > >
> > > > > We might want to abbreviate this definition a bit.
> > > > >
> > > > >
> > > > >
> > > > > 2.  In Section 8.2.2 (instead of editing warranties in section
7.1.2 or verification practices in section 11, as some have suggested) add
the following to the end of the paragraph on Disclosure:
> > > > >
> > > > >
> > > > >
> > > > > Effective as of [insert date that is six months from Ballot 125
adoption], section 4.2 of a CA's Certificate Policy and/or Certification
Practice Statement (section 4.1 for CA’s still conforming to RFC 2527) shall
> > > > >
> > > > > disclose: (1) whether the CA reviews CAA Records, and if so, (2)
the CA’s policy or practice on processing CAA Records and comparing them
with proposed Domain Names for the Common Name field or Subject Alternative
Name fields of certificates applications, and (3) any actions taken as
result of such comparison.
> > > > >
> > > > >
> > > > >
> > > > > Any comments or suggestions are welcome.
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > >
> > > > > From: public-bounces at cabforum.org [mailto:
public-bounces at cabforum.org] On Behalf Of Sigbjørn Vik
> > > > >
> > > > > Sent: Tuesday, July 22, 2014 12:47 AM
> > > > >
> > > > > To: Rick Andrews; Geoff Keating; Stephen Davidson
> > > > >
> > > > > Cc: cabfpub
> > > > >
> > > > > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records
> > > > >
> > > > >
> > > > >
> > > > > On 21-Jul-14 20:11, Rick Andrews wrote:
> > > > >
> > > > > > Siggy, how does the addition of a CAA record make DoS or DNS
> > > > >
> > > > > > amplification
> > > > >
> > > > > attacks more problematic?
> > > > >
> > > > >
> > > > >
> > > > > I am no DNS expert, merely relaying comments from our sysadmin.
If people with more knowledge in the field conclude that this is not an
issue, that is fine with me, but it should be considered.
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > >
> > > > > > From: Sigbjørn Vik [mailto:sigbjorn at opera.com]
> > > > >
> > > > > > Sent: Monday, July 21, 2014 12:21 AM
> > > > >
> > > > > > To: Rick Andrews; Geoff Keating; Stephen Davidson
> > > > >
> > > > > > Cc: cabfpub
> > > > >
> > > > > > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records
> > > > >
> > > > > >
> > > > >
> > > > > > On 17-Jul-14 23:51, Rick Andrews wrote:> Siggy,
> > > > >
> > > > > >>
> > > > >
> > > > > >> There are a number of Security Considerations in Section 6 of
the CAA
> > > > >
> > > > > >> RFC (_http://tools.ietf.org/html/rfc6844#page-13_) which detail
> > > > >
> > > > > >> possible abuse.
> > > > >
> > > > > >
> > > > >
> > > > > > I don't see DoS or DNS amplification listed there.
> > > > >
> > > > > >
> > > > >
> > > > > > --
> > > > >
> > > > > > Sigbjørn Vik
> > > > >
> > > > > > Opera Software
> > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Sigbjørn Vik
> > > > >
> > > > > Opera Software
> > > > >
> > > > > _______________________________________________
> > > > >
> > > > > Public mailing list
> > > > >
> > > > > Public at cabforum.org
> > > > >
> > > > > https://cabforum.org/mailman/listinfo/public
> > > > >
> > > > > TREND MICRO EMAIL NOTICE
> > > > > The information contained in this email and any attachments is
confidential
> > > > > and may be subject to copyright or other intellectual property
protection.
> > > > > If you are not the intended recipient, you are not authorized to
use or
> > > > > disclose this information, and we request that you notify us by
reply mail or
> > > > > telephone and delete the original message from your mail system.
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Public mailing list
> > > > > Public at cabforum.org
> > > > > https://cabforum.org/mailman/listinfo/public
> > > > >
> > > >
> > > > TREND MICRO EMAIL NOTICE
> > > > The information contained in this email and any attachments is
confidential
> > > > and may be subject to copyright or other intellectual property
protection.
> > > > If you are not the intended recipient, you are not authorized to
use or
> > > > disclose this information, and we request that you notify us by
reply mail or
> > > > telephone and delete the original message from your mail system.
> > >
> > > TREND MICRO EMAIL NOTICE
> > > The information contained in this email and any attachments is
confidential
> > > and may be subject to copyright or other intellectual property
protection.
> > > If you are not the intended recipient, you are not authorized to use
or
> > > disclose this information, and we request that you notify us by reply
mail or
> > > telephone and delete the original message from your mail system.
> >
> > TREND MICRO EMAIL NOTICE
> > The information contained in this email and any attachments is
confidential
> > and may be subject to copyright or other intellectual property
protection.
> > If you are not the intended recipient, you are not authorized to use or
> > disclose this information, and we request that you notify us by reply
mail or
> > telephone and delete the original message from your mail system.
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is
confidential
> and may be subject to copyright or other intellectual property
protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply
mail or
> telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140906/f4d21190/attachment-0003.html>