<div dir="ltr">Hi Tim,<div><br></div><div>The first message to the public/ list was <a href="https://cabforum.org/pipermail/public/2018-July/013678.html">https://cabforum.org/pipermail/public/2018-July/013678.html</a> . 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 <a href="https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html">https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html</a></div><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://cabforum.org/pipermail/validation/2018-July/000955.html">https://cabforum.org/pipermail/validation/2018-July/000955.html</a> - 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As best I can tell, <a href="https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html">https://cabforum.org/pipermail/servercert-wg/2018-July/000003.html</a> 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.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 23, 2018 at 11:11 AM Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-4875983915924147447WordSection1"><p class="MsoNormal">This is very ironic, because the new “_caa_contact” label was added because Google requested it.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Please describe in detail the attacks on TXT records you envision, so that adequate safeguards can be added.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">-Tim<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt"><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Devon O'Brien <<a href="mailto:asymmetric@google.com" target="_blank">asymmetric@google.com</a>> <br><b>Sent:</b> Monday, July 23, 2018 1:00 AM<br><b>To:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; <a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><span style="font-size:12pt">Google votes NO<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:12pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:12pt">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.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:12pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:12pt">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.<u></u><u></u></span></p></div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Jul 19, 2018 at 11:02 AM Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Administrivia:<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><ol start="1" type="1"><li class="gmail-m_-4875983915924147447m-2075566997801754312msolistparagraph">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.<u></u><u></u></li><li class="gmail-m_-4875983915924147447m-2075566997801754312msolistparagraph">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.<u></u><u></u></li></ol><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Ballot SC2: CAA Contact Property and Associated Validation Methods<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed by Bruce Morton of Entrust and Doug Beattie of GlobalSign.<u></u><u></u></p><p class="MsoNormal">--- MOTION BEGINS ---<u></u><u></u></p><p class="MsoNormal">This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.5.7:<u></u><u></u></p><p class="MsoNormal">Add Section 3.2.2.4.13: Domain Owner Email published in DNS<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Each email MAY confirm control of multiple FQDNs, provided the email address used is a DNS contact email address for each FQDN being confirmed. <u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">Add Section 3.2.2.4.14: Domain Owner Phone published in DNS<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Add Section 3.2.2.4.15: Domain Owner Email published in TXT record<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Each email MAY confirm control of multiple FQDNs, provided the email address used is a DNS contact email address for each FQDN being confirmed. <u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">##### 3.2.2.4.16 Domain Owner Phone published in TXT record<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">Add Appendix B: CAA Contact Tag<u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">CAA contact Property<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">The contact property takes a URL as its parameter.  The following URL scheme types SHOULD be implemented:<u></u><u></u></p><p class="MsoNormal">mailto: An SMTP email address where the domain holder or other authorized party can be contacted.<u></u><u></u></p><p class="MsoNormal">tel: A telephone number where the domain holder or other authorized party can be contacted.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">The following is an example where the holder of the domain specified the contact property using both an email address and a phone number.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">$ORIGIN <a href="http://example.com" target="_blank">example.com</a><u></u><u></u></p><p class="MsoNormal">.              CAA 0 issue “<a href="http://ca.example.net" target="_blank">ca.example.net</a>”<u></u><u></u></p><p class="MsoNormal">.              CAA 0 contact “mailto:<a href="mailto:domainowner@example.com" target="_blank">domainowner@example.com</a>”<u></u><u></u></p><p class="MsoNormal">.              CAA 0 contact “<a href="tel:+1-310-555-1212" target="_blank">tel:+1-310-555-1212</a>”<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">## Support for Legacy Systems<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal">               <u></u><u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal">--- MOTION ENDS ---<u></u><u></u></p><p class="MsoNormal">A comparison of the changes can be found at: <a href="https://github.com/cabforum/documents/compare/SC2-CAA-Contact?expand=1" target="_blank">https://github.com/cabforum/documents/compare/SC2-CAA-Contact?expand=1</a><u></u><u></u></p><p class="MsoNormal">The procedure for approval of this ballot is as follows:<u></u><u></u></p><p class="MsoNormal">Discussion (7+ days)<u></u><u></u></p><p class="MsoNormal">Start Time: 2018-07-11 10:30am EST<u></u><u></u></p><p class="MsoNormal">End Time: 2018-07-19 11:00am EST<u></u><u></u></p><p class="MsoNormal">Vote for approval (7 days)<u></u><u></u></p><p class="MsoNormal">Start Time: 2018-07-19 11:00am EST<u></u><u></u></p><p class="MsoNormal">End Time: 2018-07-26 11:00am EST<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div><p class="MsoNormal">_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="http://cabforum.org/mailman/listinfo/servercert-wg" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></p></blockquote></div></div></div></div>_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="http://cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">http://cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div></div>