[cabf_validation] Minutes from the Validation Subcommittee meeting of 20 December 2018

[Wayne Thayer]

Attendees: Tim Hollebeek, Ben Wilson, Doug Beattie, Shelley Brewer, Bruce
Morton, Frank Corday, Joanna Fox, Robin Alden, Tim Shirley, Mahmud Kahir,
Wayne Thayer

Agenda: Ballot SC5, Method 6, IP Any other method, DNS fragmentation

DNS Fragmentation Attacks:
Background:
https://groups.google.com/d/msg/mozilla.dev.security.policy/emREqhAZ3nM/lx8Rp3Q7BwAJ
(recording starts)
Tim: Let’s Encrypt’s results might not generalize to CAs that serve
different types of customers.
Wayne: Is the Validation WG right place for this discussion?
Tim: Yes
Wayne: Then let’s add it to the Trello board.
Wayne: How do we get the data needed to decide if we should require the
mitigation? Maybe we should require CAs to test it.
Tim: We’d need to specify the testing that would be required. Something
like requiring CAs to first try the DNS lookup with the mitigation and then
report the failure rate.
Wayne: We could write the ballot such that after some period of time the
requirement becomes mandatory if the failure rate is acceptable.
Robin: Someone could come up with a better method while testing the current
mitigation.
Wayne: Should I draft a ballot?
Tim: Yes

IP Any Other Method Ballot:
Wayne: I think we left this with questions about the DigiCert ‘device
validation’ method. I never saw answers to the questions about the security
properties of that method. I’m happy to move the ballot forward, but I’ll
remove that method.
Tim: I’m fine if you take that out, just want to move it forward.
Wayne: I’ll work on it.

SC5 (Phone number lookup in CAA and TXT records):
Doug: Once SC13 passes, it will be a good template and approach for
specifying the use of CAA and TXT records for retrieving phone numbers. I
plan to propose that we create two new methods and sunset the existing
methods at some future date.

Method 6
Tim: Shared the Validation Summit Findings doc at
https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit?usp=sharing
Tim: Should this be one big ballot or a series of small changes?
Doug: We should combine all the changes into a new method, rather Than
creating multiple new methods via a series of ballots.
Tim: I agree
Tim: Did we agree to server side redirects but not client side?
Wayne: I thought there was an email thread on it?
Tim: Yes, and a request for CAs to disclose current behavior. Only two
responded. I’ll try to dig up the thread.
Tim Began reviewing the method 6 risks table in the Validation Summit
document.
Tim: Underspecified location for random value - we can remove the IANA text.
Tim: “Unlike DNS, demonstrating control for example.com does not mean you
necessarily control www.example.com, so users may be able to obtain
certificates for subdomains for which they are not authorized.” - Limit
validation to ADNs. This will be controversial.
Doug: I agree. Big impact if we can’t validate for managed services using
the base domain.
Tim: We could allow opt-out via CAA.
Tim: “On shared IP address environments, the use of SNI can permit
certificate issuance for domains on the shared IP address if the Hosting
provider does not separate users” - does anyone have a suggested mitigation?
Robin - Conceptually you could restrict the methods available for shared IP
addresses.
Wayne - Does the ALPN mitigation developed for method 10 help here?
Tim - We really should replace method 10 with the new ALPN RFC draft. I
don’t think it is approved yet, but we could base a new method on a draft.
Tim: We need to require that CAs support SNI and send the correct header.
Doug: would that limit this method to HTTPS?
Tim: I don’t think it would. Setting an SNI header doesn’t require HTTPS.
Tim - Next item: “The use of query strings can be  used to …”. I don’t know
what that was.
Doug - It came up at the summit but was never captured accurately. Same for
“May be susceptible to Cross protocol attacks”
Wayne - Did Ryan bring this up? We may need his help on this one.
Tim - Next item is caching. This is a good topic. We could require the use
of a no-cache header to address this issue. Any reason not to do this? I
think the cache could only cause problems.
Doug: Does caching cause security problems?
Tim: No, the worst it could do is cause validation to fail
Doug: If we’re not solving a problem, then we shouldn’t include this.
Tim, Wayne: Agree
Tim: “HTTP response code is not a 2xx or 3xx” - I would argue this is
already required, but if not we should make it explicit. Although this is
also a solution where there is no problem. We already said that the token
can’t be in the URL
Wayne: This is easier to justify. If server is telling you that something
went wrong, why should you trust it?
Tim: Okay
Tim: (skipping down to bullets under the table) “Should the rules be more
lenient if the redirect only changes the scheme from HTTP to HTTPS”. No.
Wayne: Can’t the server just try both?
Tim: “Should there be a limit on following chains of redirects?” - We
currently do have a limit of one.
Robin: I wouldn’t have a problem with a limit of one
Tim: Should we ban redirection to some other scheme like file:// or ftp:// ?
Robin: Yes, only accept redirects to schemes we have validated.
Tim: Technically you could redirect to email.
Tim: A redirect from HTTPS to HTTP or a different port is okay.
Doug: What if it’s not an approved port?
Robin: What is the risk if the person in control of the domain wants to
redirect to a non-standard port? Do we want to prevent redirects to ports
that may not be secure?
Tim: I’d like to know how often that happens
Robin: The thing to be afraid of is someone who redirects to a higher port
without realizing that other users of the system can access them. Not sure.
Tim: yes, requires more thought.
Tim; “Should CAs be required to comply with Content Security Policy
directives such as upgrade-insecure-requests sent from the server?” Since
we don’t require HTTPS, I think the answer is ‘no’, but requires more
research.
Tim: That’s 6 things we could potentially put into a draft ballot:

1. Forbid CAs from following client-side redirects when validating
2. Specify the exact locations
   a. .well-known/pki-validation/
   b. .well-known/acme-challenge/
3. Require that the response be successful
4. Limit of 1 redirect
5. Limit redirection to ‘http:’ and ‘https:’
6. Should we allow redirects to different ports?
Tim: Anything else we should include? Does anyone want to take
responsibility for drafting a ballot?
Doug: I can give it a shot.
Tim: Next call is Jan 3rd. Good progress today.
Ben: I’ll set up a new Webex meeting so that others can be hosts and start
the meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181221/52284431/attachment.html>