[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