[cabfpub] [Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT

Ryan Sleevi sleevi at google.com
Tue Jul 24 09:45:10 UTC 2018 

On Mon, Jul 23, 2018 at 3:35 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> You left out the fact that Bruce posted very similar text to the
> validation mailing list well before London.
>

As I indicated, I'd tried to find references to it. Do you have a copy of
the similar text you refer to? Sharing a link is always a great way to make
sure we're on the same page.


> This is not a new idea, and concrete proposals have been floating around
> for quite a while.  And nowhere in our Bylaws does it say that discussion
> periods can’t happen during IETF.  I think Devon and I were the only two
> relevant people there anyway.
>

I didn't suggest it did - but I did highlight it because it emphasized that
we raised concerns, we expressed concerns on the timing - and the
complexity in getting this right (and the concerns about it being rushed).
We also suggested evangelizing this change before voting, to sanity check
the approach, but you were opposed to that. While we're rehashing a
conversation, I think it's worth emphasizing that we made a good faith
effort here to highlight the concerns, and turning around in 24 hours with
a ballot that doesn't address those concerns isn't a great way to get to a
positive vote.


> It’s not a serious misrepresentation to say I was surprised, because I was
> in fact very surprised.  That’s an objective fact.  In fact I think your
> false accusation of a serious misrepresentation is a code of conduct
> violation.
>

While it's profoundly unfortunate you feel that way, there is a process to
raise such concerns, in which you can indicate which remarks you believe
are COC violations. That's Exhibit B of the Bylaws. While it's similarly
unfortunate that you did not understand the seriousness of our concerns
with TXT, and that we were expressing concrete concerns that would prevent
a positive vote, it cannot reasonably be said that we did not make a good
faith effort, both on the list and over the phone, to highlight that these
tangible concerns exist and would not be easily resolved.


> You indicated that you were going to be unavailable for follow up, and
> that if I made the changes we discussed, you guys could support it.  I
> still have the paper right here on my desk with the notes.  I told you I
> was planning on doing exactly what I did, including the fact that I was
> planning on posting a ballot before I left for IETF, so there should have
> been no surprises there as far as the timing.  The only thing that didn’t
> happen as planned was the IETF draft, which I keep poking Tomofumi about
> and should be up soon.
>

As indicated, we shared reservations about TXT, and still do. I apologize
that you misunderstood our optimism regarding CAA as a path forward, or
that you appropriately understood viable paths forward for TXT, as somehow
an unconditional support of a ballot, but that's certainly not the intent.
Quality ballots take time to write and review - and the concerns, as
substantial as they were raised on list and during the call, are not the
kind that can be quickly turned around. We even shared that with you - that
we felt these concerns would take several weeks and multiple attempts to
adequately and sufficiently resolve, and while you were optimistic about
being able to quickly turn them around the following day, we did not share
that optimism.


> Do you have concrete proposals for improvements that would allow you to
> support TXT?  Having it be phased out over time is actually something that
> has been explicitly discussed among the proposers.  And I’m not going to
> accept vague hand-waving about attacks.  If you guys have actual attack
> scenarios you want to discuss, post them for discussion and analysis.
> We’re talking about someone who has the ability to modify DNS records for
> the domain being validated, after all.
>

I've already highlighted several in this thread, and I hope you recall we
discussed this at substantive length on our call.

We discussed using CAA to opt-in to TXT.
We discussed requiring that every time TXT is used, information about the
DNS provider or software be provided, and maintained as a set of "known
exceptions" with phase out.
We discussed maintaining a public list of providers known not to support
CAA adequately.

Concretely, we discussed the attacks in which the allowance under .7 - and
under the proposed ballot - left a huge gap for being able to adequately
secure systems, by being able to audit and control the means of certificate
issuance. In this regard, we again discussed CAA, and the potential to
restrict methods of issuance as being a potential precursor ballot.
Similarly, we discussed the need for clarity as to when these methods are
used - that is, documenting in the certificate itself the validation method
used, also as a potential precursor ballot to going forward with TXT.

I hope your notes show these many suggestions offered for how to best
balance the issues introduced - which, while similar to .7, for a new
method, are areas where we would be troubled with introducing "known
insecure" things, especially if that's just because that's how we used to
do it, even if we knew they were insecure.

As you recall, we discussed the similarity with other proposals to add
additional 'blessed' mailboxes for email validation, and how those
fundamentally represent additional security risk, by introducing new
surfaces that are not audited, monitored, or maintained.


> I actually discussed the need for TXT records with several DNS experts at
> IETF.  They all agreed that it’s the only record type that actually works
> reliably, and while its ubiquity of use is undesirable, that’s the world we
> actually live in …
>

As you recall, we discussed that, much like SHA-1 exceptions that were
provided prior to 2016 (e.g. to support legacy software), the only viable
path forward to allowing something 'legacy' when something 'better' exists
is to maintain better documentation about how, when, and why these legacy
settings are used, so that we can work better to find solutions.


> I would suggest that the more reasonable root programs vote in favor of
> this perfectly reasonable ballot.
>

I'm sorry that disagreeing with DigiCert is seen as unreasonable, but it
cannot be said that we did not put substantial effort to communicate these
concerns before advancing to a ballot.


>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Monday, July 23, 2018 1:26 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>;
> servercert-wg at cabforum.org
> *Cc:* Devon O'Brien <asymmetric at google.com>; CABFPub <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Voting Begins: Ballot SC2 - version 2:
> Validating certificates via CAA CONTACT
>
>
>
> Hi Tim,
>
>
>
> The first message to the public/ list was
> https://cabforum.org/pipermail/public/2018-July/013678.html . As Ben can
> attest, there were some issues getting folks registered to the
> servercert-wg list - including all the Google representatives - but the
> first text of this ballot was proposed at
> https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html
>
>
>
> You're correct that we did have a fairly productive call on July 9, which
> lead to that improvement, but I'm having trouble finding earlier versions
> of your drafts that incorporated that feedback. As you also recall from
> these discussions, we raised concerns about supporting TXT at all, and
> indicated it would be challenging and require care. During those
> conversations, we highlighted similar concerns to what are expressed here -
> namely, that unlike special reservations like /.well-known/, TXT opens up
> new security risks that CAA expressions don't.
>
>
>
> While you mention it having been discussed for several months, the only
> mention I can find for actual, concrete text - not just the idea of
> something - is
> https://cabforum.org/pipermail/validation/2018-July/000955.html - which
> Google raised a number of concerns with, resulting in our call, since these
> concerns had also been expressed during the Validation meeting in London as
> issues that would need to be addressed.
>
>
>
> As mentioned - during London and during our phone call - this further
> normalizes a risk in which delegating the ability to create a TXT record
> effectively delegates control to issue certificates. As mentioned during
> those discussions, we acknowledge that 3.2.2.4.7 similarly suffers such a
> weakness - and that's been identified as a weakness of .7 for quite some
> time (as is the lack of the ability to specify and opt-in/opt-out of
> particular validation methods). However, introducing a new method should
> not rely on the existing weaknesses and ambiguities - we should work to do
> better.
>
>
>
> We discussed several proposals for ways you could incorporate such within
> your ballot - ranging from requiring CAA to explicitly opt-in to such a
> method to requiring having a documented process for allowing TXT, treating
> it as an exception (similar to SHA-1), as it represents a legacy system
> which should be aggressively phased out within the CA ecosystem for more
> structured, less ambiguous representations.
>
>
>
> As best I can tell,
> https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html was
> posted a day after our conversation, with no feedback or follow-up from you
> regarding these concerns shared, and promptly moved straight to vote, even
> with the acknowledged concerns about the upcoming IETF delaying responses
> and review. In that regard, I think it's a serious misrepresentation to
> suggest that this is somehow surprising. As mentioned in the feedback, we
> tried to offer productive ways forward to allow some relief for CAs who
> found themselves relying on methods that are now impaired by the ICANN-EU
> discussions around GDPR and WHOIS - such as decoupling the CAA and TXT
> ballots - but I don't think it's at all reasonable to suggest we did not
> offer many ways in which these concerns could be addressed, or spend time
> trying to highlight these concerns in advance of pursuing a vote.
>
> On Mon, Jul 23, 2018 at 11:11 AM Tim Hollebeek via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> This is very ironic, because the new “_caa_contact” label was added
> because Google requested it.
>
>
>
> The proposal has been discussed for several months now, and as you are
> well aware, I made every effort to satisfy all of Google’s requests for
> improvements to the ballot, including a long phone conversation.
>
>
>
> Please describe in detail the attacks on TXT records you envision, so that
> adequate safeguards can be added.
>
>
>
> -Tim
>
>
>
> *From:* Devon O'Brien <asymmetric at google.com>
> *Sent:* Monday, July 23, 2018 1:00 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>;
> servercert-wg at cabforum.org
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [Servercert-wg] Voting Begins: Ballot SC2 - version 2:
> Validating certificates via CAA CONTACT
>
>
>
> Google votes NO
>
>
>
> While supportive of efforts to offer CAs flexibility in light of ICANN
> policy changes, we're concerned that the amount of time to review concrete
> efforts to improve this has been limited. We do not feel confident in the
> security considerations of this method, in particular, the introduction of
> a new privileged label (_caa_contact) that does not have any pre-existing
> security advice surrounding it.
>
>
>
> These concerns are due to the support of the TXT record, something which
> is also problematic in existing validation methods, but we don't feel
> confident that it is appropriate to introduce something 'insecure' and 'fix
> it later'. If this were scoped just to CAA, we believe it appropriate to
> ratify. Separate discussions on the necessity of TXT, when and how TXT is
> used in favor of CAA by CAs, and how site operators can secure themselves
> appropriately could all be used to develop an appropriate specification.
> Customers who wish to issue certificates this method can set CAA records,
> which may require work from their DNS provider to support standards from 6
> years ago, but is still strictly an improvement over introducing
> known-insecure methods.
>
>
>
>
>
> On Thu, Jul 19, 2018 at 11:02 AM Tim Hollebeek via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>
>
> Administrivia:
>
>
>
>    1. This ballot is being cross-posted to the CABF public mailing in
>    line with the consensus from last Thursday’s call that it is important
>    everyone is aware of the ballot, and that not everyone is on the SCWG list
>    yet.
>    2. I promised an IETF independent stream draft for the same proposal,
>    so it can get feedback from those at IETF.  I still intend to do so, but I
>    am working with a colleague on setting up a github account for DigiCert
>    IETF efforts to make it easier for others to collaborate with us on IETF
>    submissions.  I anticipate we will have that set up and the draft submitted
>    some time next week.  The IETF draft will allow IETF to review the method
>    and make suggested improvements.  It should not block adoption of the
>    current proposal by CABF.  DigiCert intends to submit a ballot to adopt
>    IETF’s improvements once the IETF process is complete.
>
>
>
> Ballot SC2: CAA Contact Property and Associated Validation Methods
>
> Purpose of Ballot: Increasingly, contact information is not available in
> WHOIS due to concerns about potential GDPR violations.  This ballot
> specifies a method by which domain holders can publish their contact
> information via DNS, and how CAs can use that information for validating
> domain control.
>
> The following motion has been proposed by Tim Hollebeek of DigiCert and
> endorsed by Bruce Morton of Entrust and Doug Beattie of GlobalSign.
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.5.7:
>
> Add Section 3.2.2.4.13: Domain Owner Email published in DNS
>
> Confirm the Applicant's control over the FQDN by (i) sending an email to a
> DNS domain name holder, (ii) including a Random Value in the email, and
> (iii) receiving a confirming response utilizing the Random Value. The CA
> MUST send the email to an email address found in the CAA Contact property
> record as defined in Appendix B.
>
>
>
> Each email MAY confirm control of multiple FQDNs, provided the email
> address used is a DNS contact email address for each FQDN being confirmed.
>
>
>
> The Random Value SHALL be unique in each email. The email MAY be re-sent
> in its entirety, including the re-use of the Random Value, provided that
> its entire contents and recipient SHALL remain unchanged. The Random Value
> SHALL remain valid for use in a confirming response for no more than 30
> days from its creation. The CPS MAY specify a shorter validity period for
> Random Values.
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.
>
> Add Section 3.2.2.4.14: Domain Owner Phone published in DNS
>
>
>
> Confirm the Applicant's control over the FQDN by calling the DNS domain
> name holder phone number and obtaining a response confirming the
> Applicant's request for validation of the FQDN. The CA MUST place the call
> to a phone number identified in the CAA Contact property record as defined
> in Appendix B.
>
>
>
> Each phone call SHALL be made to a single number and MAY confirm control
> of multiple FQDNs, provided that the phone number is identified by the DNS
> contact as a valid contact method for every Base Domain Name being verified
> using the phone call.
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.
>
>
>
> Add Section 3.2.2.4.15: Domain Owner Email published in TXT record
>
>
>
> Confirm the Applicant's control over the FQDN by (i) sending an email to a
> DNS domain name holder, (ii) including a Random Value in the email, and
> (iii) receiving a confirming response utilizing the Random Value. The CA
> MUST send the email to an email address found in the DNS TXT record as
> defined in Appendix B.
>
>
>
> Each email MAY confirm control of multiple FQDNs, provided the email
> address used is a DNS contact email address for each FQDN being confirmed.
>
>
>
> The Random Value SHALL be unique in each email. The email MAY be re-sent
> in its entirety, including the re-use of the Random Value, provided that
> its entire contents and recipient SHALL remain unchanged. The Random Value
> SHALL remain valid for use in a confirming response for no more than 30
> days from its creation. The CPS MAY specify a shorter validity period for
> Random Values.
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.
>
>
>
> ##### 3.2.2.4.16 Domain Owner Phone published in TXT record
>
>
>
> Confirm the Applicant's control over the FQDN by calling the DNS domain
> name holder phone number and obtaining a response confirming the
> Applicant's request for validation of the FQDN. The CA MUST place the call
> to a phone number identified in the DNS TXT record defined in Appendix B.
>
>
>
> Each phone call SHALL be made to a single number and MAY confirm control
> of multiple FQDNs, provided that the phone number is identified by the DNS
> contact as a valid contact method for every Base Domain Name being verified
> using the phone call.
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN. This method is suitable for validating Wildcard Domain
> Names.
>
> Add Appendix B: CAA Contact Tag
>
> The syntax for the contact property is similar to the iodef property.  It
> allows domain owners to publish contact information in DNS in addition to
> WHOIS for the purpose of validating domain control.
>
> CAA contact Property
>
>
>
> contact <URL> :  The contact property entry specifies the authorized means
> of contacting the holder of the domain or another party who is authorized
> to approve issuance of certificates for the domain.
>
>
>
> The contact property specifies a means of contacting the domain holder, or
> another party that is authorized to approve issuance of certificates for
> the domain in question.
>
> The contact property takes a URL as its parameter.  The following URL
> scheme types SHOULD be implemented:
>
> mailto: An SMTP email address where the domain holder or other authorized
> party can be contacted.
>
> tel: A telephone number where the domain holder or other authorized party
> can be contacted.
>
>
>
> Schemes other than "mailto:" or "tel:" MUST NOT be used.  Telephone
> numbers MUST include the country code and be global phone numbers as
> defined by RFC 3966.
>
>
>
> The following is an example where the holder of the domain specified the
> contact property using both an email address and a phone number.
>
>
>
> $ORIGIN example.com
>
> .              CAA 0 issue “ca.example.net”
>
> .              CAA 0 contact “mailto:domainowner at example.com”
>
> .              CAA 0 contact “tel:+1-310-555-1212 <+1-310-555-1212>”
>
>
>
> ## Support for Legacy Systems
>
>
>
> Some systems still do not have sufficient support for CAA records.  To
> allow users of those systems to specify contact information, a legacy
> format using text records is allowed.  The CAA contact property SHOULD be
> used instead of TXT records, where feasible.
>
>
>
> The DNS TXT record MUST be placed on the "_caa_contact" subdomain of the
> domain being validated.  The DNS record MUST be named
> "domain-authorization-email" or "domain-authorization-phone".  The value of
> "domain-authorization-email" MUST contain a valid email address, or it
> cannot be used.  The value of "domain-authorization-phone" must be a global
> phone number, including country code, as defined in RFC 3966 or it cannot
> be used.
>
> --- MOTION ENDS ---
>
> A comparison of the changes can be found at:
> https://github.com/cabforum/documents/compare/SC2-CAA-Contact?expand=1
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 2018-07-11 10:30am EST
>
> End Time: 2018-07-19 11:00am EST
>
> Vote for approval (7 days)
>
> Start Time: 2018-07-19 11:00am EST
>
> End Time: 2018-07-26 11:00am EST
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180724/ab467325/attachment-0003.html>

More information about the Public mailing list