[cabf_validation] Minutes from the Validation Subcommittee Meeting of 30 August 2018

[Doug Beattie]

Minutes from the Validation Subcommittee Meeting of 30 August 2018

Notetaker:  Doug Beattie

Attendees: Ben Wilson, Shelley Brewer, Bruce Morton, Corey Bonnell, Doug Beattie, Frank Corday, Joanna Fox, Li-Chun Chen, Patrick Tronnier, Tim Shirley, Wayne Thayer, Ryan Sleevi

 

1. Remove IP “any other method” ballot [1]

Tim and Doug provided some comments, and Bruce said he didn’t have any comments.  Wayne made some editorial updates and said the ballot should be good to go.

The conversation shifted to effective dates and what that means.  Currently, the ballot says June 31, 2019, but Ryan asked if the deadline could be shortened.   We need to be explicit about dates when it comes to re-use of data and when the new methods need to be used for new validations. 

GlobalSign and Entrust said they are not using “any other method” for new validations.  DigiCert said they were OK with the proposed dates.  Ryan ran a report and showed that for certificates issued in 2018, there were 1818 certificates containing 1359 unique IP addresses.

After some further discussion, the recommendation is:

-          CAs must stop using current methods by April 1, 2019 (must use only new methods starting this date for all new IP address validations)

-          CAs must not issue certificates containing IP addresses validated using current methods by June 30, 2019

-          Issued certificates may continue to be used until they expire

 

2. Revocation timeline extension ballot (Wayne)

Version 2 was published. It has received feedback from Bruce, which will be incorporated.  Per the current bylaws, we’ll need to publish a v3 and have a 7-day comment period followed by voting.  There was no push-back on the current ballot, so it will likely proceed.  Ryan will send comments if he has any after the call.

A note about the current bylaws:   Apparently during the bylaws update, ballot 216 was not included, so if a new version is created it must re-set the 7-day comment period.  Wayne will need to publish version 3 of the ballot for revocation timelines with a defined discussion period, and then move forward.  If anyone wants to re-submit ballot 216 and update the bylaws, please do so (or else Wayne will get to it at some point).  All individuals submitting ballots should take note.

 

3. CAA CONTACT Ballot  

There are some remaining comments to be incorporated. Corey and Ryan had provided comments to Tim, but Tim hasn’t yet updated the ballot with them.  Tim has the action to address them.

The general approach for CAA is agreed to as documented in the ballot, but the approach for TXT records received much discussion during the call.

Ryan recommends splitting out CAA and TXT, and proceeding with CAA approaches for both Email and Phone since those seem to be well defined and accepted by all; whereas TXT has some challenges and concerns.

Ryan said there are basically two approaches for TXT records:

1.       Make the TXT record look like the CAA record (same format), or

2.       Define a distinct format for the TXT record (Tim took this approach).  Currently, the Email address will be encoded differently.  Corey is looking into un-ambiguous encoding of email addresses.

 

Ryan said this is the first method to permit the use of Grandchild domains to approve.

-          CAA uses ADN

-          Method 7 uses just the ADN

-          Now we are permitting child and grandchild domains to be used, of the form: _caa‑contact.something else.ADN

This is a non-trivial change, and challenging.  Providers let you register subdomains, so this impacts lots of hosting providers.  We know there are hosting providers that treat child and grandchild domains differently.

A bit later Wayne asked Ryan how this was different from Method 7, and we confirmed that the risks are about the same:

-          Method 7 permits child domains beginning with “_” followed by an ADN

-          This ballot proposes the use of a DNS record located at a specific, well defined node: _caa_contact.ADN

 

Ryan pointed out that the use of non-approved constructed email addresses (admin@ and administrator@) resulted in unintended issuance because an email service didn’t realize they needed to block certain mailboxes.   The same can happen with domain validation if the proper control of domain name prefixes are not enforced.  The nominal approach is that DNS providers don’t let you set A records that begin with an underscore.  This doesn’t help with wildcard CNAME records, which could be a risk.  

Question: Do we introduce new methods with the same new risks?  Some schools say yes, others say fix them across the board later.

Wayne: It helps to talk about this and recognize that this is the same risk.  The validation WG notes identified that the only risk was that we needed to define the exact prefix for method 7 and not allow any value to be used. 

Those are the risks, and we may accept the risks, or we may want to take a more conservative approach, but we want to assess those risks.

Next, Ryan asked if we should be requiring DNS providers that support CAA to use CAA records and prohibit TXT records?

Ryan suggested the following:

-          CAs can use TXT only when the domain’s DNS provider does not support CAA

-          When a customer wants to use TXT because their DNS provider does not support CAA, the CA would ask them who/what they use for DNS and then have the CA disclose this to the public so it can be tracked.  The intent is to track and then someone can encourage all DNS providers to support CAA.  Once that is complete, we could phase out the use of TXT records in about 2 years.

-          Ideal goal: If we had widespread support for CAA, we could do lots of good things (restricting validation methods), so we want to push CAA adoption and move away from TXT, and this approach will help us do that.

 

Wayne concluded saying we have some good information for Tim and it would help if Ryan sent a follow-up email to Tim documenting some of this discussion.

 

4. Method 3 Ballot, SC5

Doug sent out a draft on Friday, August 17th and there have not been any posted comments.  Wayne said he reviewed it and had no issues.  Doug said that the ballot will wait for resolution on Email TXT record usage and then follow the lead with this ballot.  Members are reminded to review the proposed ballot and provide comments. 

 

5. BGP Attacks on Validation

Another paper has been published about this.  We haven’t discussed in detail or come up with a recommended approach. 

Ryan said this was the same paper but just recently re-presented. 

Tim is planning to have the researchers attend our next meeting to discuss this topic.

 

6. Any other business

6.1) Ballot to include validation method into certificates (Wayne):  Waiting until IP address validation ballot is done and we have section numbers to reference (on hold for now).  Will use bit string.  There is nothing holding this up at this point.

6.2) Ryan reminded us of the DefCon presentation on re-use domain validation on expired domains, as this relates to take-over attacks.  The PBP paper discussed mitigations people can take (looking at freshness of information). We need to be careful of how we re-use domain information.

 

Wrap-up

Wayne wrapped up by saying we covered everything on Trello board and we’ll let the current suite of ballots work their way through before we start on some new ones

 

·  [1]  <https://github.com/cabforum/documents/compare/master...Ballot-SC7---IP-any-other-method> https://github.com/cabforum/documents/compare/master...Ballot-SC7---IP-any-other-method

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180831/65b7340e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180831/65b7340e/attachment-0001.p7s>