[cabf_validation] Minutes from the meeting of 2 August 2018

[Wayne Thayer]

Curt,

My understanding is that many DNS providers now support the creation and
editing of CAA records, but only for properties defined in the RFC - issue,
issuewild, and iodef. The ballots discussed on today's call create new
properties that most DNS providers won't initially support.

Thanks,

Wayne

On Thu, Aug 2, 2018 at 1:19 PM Curt Spann via Validation <
validation at cabforum.org> wrote:

> I have one question about the statement regarding the lack of support of
> CAA by DNS providers and DNS tools:
> Is there evidence to support this statement? I found this page (
> https://sslmate.com/caa/support) and it shows that most of the DNS
> providers and tools support CAA.
>
> Regards,
> Curt
>
> On Aug 2, 2018, at 12:29 PM, Wayne Thayer via Validation <
> validation at cabforum.org> wrote:
>
> Minutes from the Validation Subcommittee meeting of 2 August 2018
>
>  Attendees: Tim Hollebeek, Ben Wilson, Shelley Brewer, Bruce Morton, Corey
> Bonnell, Doug Beattie, Frank Corday, Joanna Fox, Rich Smith, Robin Alden,
> Li-Chun Chen, Frank Corday
>
> 1. Continue re-direct discussion
> Wayne listed types of redirects in the Validation Summit Findings document
> [1] under method 6
> Tim: do we have a general idea of what the policy should be?
> Ben: No, we need to determine what the concerns are.
> Tim: the last two on the list (meta-refresh tag and JavaScript) are bad
> ideas because they require CAs to run a sophisticated HTML parser that adds
> complexity and risk. I don’t think CAs intentionally support these, but
> their code may incidentally support it. Is anyone against banning these two?
> Bruce: I can’t comment now
> Tim: Are people familiar enough with 300s to discuss?
> Doug: I can’t think of a good reason why we should allow any of these
> Tim: I’m particularly disturbed when a redirect points back to a site run
> by the CA. Pointing to another subdomain of the same domain seems
> reasonable. But I could also argue that it should be a new validation
> method.
> Tim: Does everyone need to give this more thought?
> Wayne: We should propose banning redirects and see who complains
> Tim: Clients like Curl automatically follow redirects, so people may not
> recognize the impact.
> Corey: Redirects from the base domain to the www subdomain are common.
> Banning this will cause some pain to Subscribers.
> Tim: Can everyone do some homework to determine what their CA’s current
> redirect behavior is?
> Wayne: In most cases CAs could check both the www and base name, but that
> won’t work if validating the subdomain and validation code is on the base
> domain.
> Tim: Redirecting to another subdomain of the same domain name might be
> okay - both are controlled by the same entity.
> Tim: the basic security property of this method is the ability to control
> the content of the website, so if www is the same site as the base domain
> then that should be okay.
>
> 2. Discuss Ballot SC2
> Tim: Mainly failed due to it being Summertime and lack of time to review.
> Also some discussion about the phone number validation method colliding
> with Doug’s method 3 ballot. Decided to split out the phone number portions
> to a separate ballot.
> Bruce: Updated the text to use ADN per comment from Wayne
> Corey: what about splitting out text record to a separate ballot?
> *Tim: most DNS tools don’t support new CAA tags, so the TXT record is
> essential and it’s a widely accepted approach in the IETF because it works.
> *
> Wayne: is the use of a specific subdomain a change?
> Tim: no, that’s how it was spec’d in ballot SC2. I realize TXT support is
> controversial, but most DNS providers don’t support new CAA tags.
>
> 3. Validation Summit Method 3 Ballot
> Doug: Changed references to domain contact’s phone number rather than
> WHOIS registrant. Added info on voicemail handling. Added validation of an
> ADN. CA can request to be transferred to the domain contact. Plan is a
> ballot to update method 3 with these clarifications, effective immediately.
> Also add method 15 for domain contact phone number in CAA and method 16 for
> domain contact phone number in DNS TXT record. There will only be a phone
> number and no name in these records because they are there specifically for
> the purpose of domain validation rather than a more general WHOIS contact
> phone number. Doug will send out an updated pre-ballot in the next few
> days.
> Tim: the question of whether you have to ask for someone specific when
> making the call is an interesting one. Have to think about that.
>
> 4. Validation Methods in CAA, ACME, and IETF
> Tim: A lot going on here. There is an ACME draft for specifying validation
> methods in CAA. We discussed in London the use of friendly names rather
> than OIDs for CAA records. Wayne, the ‘validation method in certificate”
> ballot uses OIDs, correct?
> Wayne: Correct. Concatenate the validation method number with the OID arc.
> Wayne: There should be a mapping between OIDs and names
> Tim: I prefer to run this through IETF
> Ben:  We would be dependent on IETF for adding validation methods
> Tim: It would be an IANA registry so would be relatively easy to update
> Tim: Also going to send CAA contact tags through IETF but shouldn’t hold
> up introduction of new methods
>
> 5. Validation Methods in Certificates
> Wayne: my mental model is that certificates are issued as soon as each SAN
> passes one method of domain validation, but Doug pointed out on the list
> that some CAs might validate with multiple methods. The CA can just choose
> which method to indicate in the certificate, or can indicate multiple
> methods. The concern is if one method is found to be insecure, then that
> doesn’t necessarily mean that the cert needs to be replaced. In fact, CAs
> often revalidate rather than reissuing certs when a validation
> vulnerability is found. This leads to the conclusion that the validation
> method information in a certificate can’t be used to determine that the
> certificate needs to be revoked.
> Tim: I agree. The BRs state that the CA must validate using “at least one
> of the methods below”.
> Doug: I also agree, but we don’t know what browsers will do with this
> information, so we have to assume that browsers will use it to make trust
> decisions.
> Wayne: I view this as information, not a way to enforce policies, and this
> discussion makes the case for that.
> Doug: Can the intent be part of the ballot?
> Wayne: Requirements can’t really describe intent, but I’d be happy to add
> that to the introductory language of the ballot.
> Tim: Another question is the ability to describe which sub-methods were
> used
> Wayne: the ballot expresses the current scheme of describing methods, so
> that scheme would need to change first. In the current scheme, we should
> break a method with N sub methods into N new methods.
> Tim: I agree. Another concern is with CAA, where constantly changing
> method numbers could cause problems when certificates are renewed
> Bruce: I don’t see method numbers constantly changing once we get through
> our review of all the methods. Agree that method 2 should be 3 methods.
> Doug: Method 2 could really be 9 methods. Or we could have one method for
> all flavors of phone validation, for instance. We need to decide if we want
> to make methods more granular. Not convinced it’s worth turning one method
> into 9.
> Corey: If we don’t make things more granular, there isn’t enough value in
> encoding the method into the cert. The OID for the old and new method 10
> would be the same.
> Tim: Method 10 is a problem child. It needs to be fixed.
>
> [1]
> https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit#heading=h.29h2q2aeb3nh
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
> _______________________________________________
> 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/20180802/08e0fdb1/attachment.html>