[cabf_validation] Minutes from the Validation Subcommittee Meeting of 30 August 2018
Ryan Sleevi
sleevi at google.com
Fri Aug 31 06:24:15 MST 2018
On Fri, Aug 31, 2018 at 6:41 AM Doug Beattie via Validation <
validation at cabforum.org> wrote:
> 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
> <https://teams.googleplex.com/u/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.
>
For those following the minutes - some of what I was looking at on the call
was an out-of-date draft at a specific revision, hence the mistakes. For
example, the format between the TXT and CAA have been aligned and
normalized, and the seeming removal of grandchild.
Hopefully https://cabforum.org/pipermail/public/2018-August/013999.html is
the most accurate version and captures / expands on the set of concerns.
>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180831/7a617b5a/attachment-0001.html>
More information about the Validation
mailing list