SC45: Wildcard Domain Validation

[sleevi]

Purpose of Ballot

This Ballot addresses security issues with the use of methods 3.2.2.4.6, 3.2.2.4.18, and 3.2.2.4.19 of the Baseline Requirements to authenticate an entire domain namespace. These methods rely on an HTTP based demonstration of control, which only demonstrates control over a particular host and service, rather than the entire Domain Namespace.

Effective 2021-12-01, these methods MUST NOT be used to issue Wildcard Certificates and MUST NOT be used as Authorization Domain Names for subordinate FQDNs of the validated FQDN.

The following motion has been proposed by Ryan Sleevi of Google and endorsed by Jos Purvis of Cisco and Dimitris Zacharopoulos of HARICA.

[sleevi]

@castillar @dzacharo Could you review this draft ballot and text to confirm before voting?

From the off-list discussion with Dimitris, there was some concern about permitting wildcard .onion domain names. I've flagged this as TBD, because we identified that the issues affecting these methods for subdomains equally affect .onion domains, and unlike DNS, Tor Hidden Service operators do not have the ability to use mechanisms like CAA to further restrict or prevent accidental authorization. If we decide to keep .onion consistent with DNS, which does make a degree of sense, then there are slight modifications to Appendix B to be made.

The choice to placing this exception within Appendix B is that Section 3.2.2.4 explicitly "branches" to Appendix B for validation, since .onion does not use DNS at all. Attempting to shoehorn these into .6, .18, and .19 felt more awkward.

[sleevi]

See also #270 . I'm not sure if we want to tackle that in this, since it's "new", and I prefer to keep things more narrowly scoped. This is why I only tackled #241 but not #242 or #240, as those seem more appropriate for an overall .onion cleanup. I mention it here, however, in case it's dispositive towards the TBD I'm flagging here.

[sleevi]

Oh, and CC'ing @CBonnell since he expressed interest in seeing the draft language and proposal on the 2021-04-22 Validation WG call.

[dzacharo]

While reading the introduction of the ballot, I had to read the part related to "validation for domains" several times to understand what the intention was.

That's because "validation of a domain" in the current version of 3.2.2.4.18, say foo.bar.example.com, with the use of ADNs, can be performed by choosing an ADN foo.bar.example.com, bar.example.com or example.com. Now that we plan to remove wildcards for these methods, the notion of ADN does not seem to apply anymore. These methods will only be able to validate the requested FQDNs to be included in the Certificates. The only exception where the notion of ADN is applicable, is for .onion domains, where one can use the hidden service Domain Name (two labels) as an ADN to validate any FQDN that ends with all the labels of the hidden service Domain Name.

Suggest replacing: "Authorization Domain Name" with "FQDN" in 3.2.2.4.18.

I also suggest a small change in the introduction reusing the "subordinate FQDNs" language, clarifying the ADN/FQDN language a bit, and pointing to the Appendix 2b validation method:

"One exception to this prohibition is the issuance of .onion certificates, as specified by Appendix B. For .onion domains, provided that the validated ADN and FQDN is the exact hidden service (i.e. two domain labels), this method MAY be used to validate a Wildcard Domain Name and MAY be used to authorize subsequent domain names. However, validation for domains such as foo.<hidden service>.onion MUST NOT be used to validate domains such as bar.foo.<hidden service>.onion unless the validation demonstrates authorization by the Tor Hidden Service's long term master key having signed a CSR."

with

"One exception to this prohibition is the issuance of .onion certificates, as specified by Appendix B. For .onion domains, if the validated FQDN is the exact Hidden Service (i.e. two domain labels), this method MAY be used to validate a Wildcard Domain Name and MAY be used to authorize subordinate FQDNs. However, validation for domains such as foo.<hidden service>.onion MUST NOT be used to validate domains such as bar.foo.<hidden service>.onion unless the Applicant uses the validation process described in Appendix B - paragraph 2b, that demonstrates authorization by the Tor Hidden Service's long term master key having signed a CSR."

I also don't see a reason not to address #240 which seems uncontroversial.

Finally, since method 6 is deprecated since 2020-06-03, it seems weird to add a Note with a restriction date for "things issued after 2021-12-01". I guess it doesn't hurt to add for consistency but it still remains weird :)

I'm sorry these didn't come up earlier, I didn't have time to do a good review in the past weeks. I hope these are helpful.

[sleevi]

Now that we plan to remove wildcards for these methods, the notion of ADN does not seem to apply anymore.

Sorry, I should have explained more context that I considered this, and rejected it, as part of developing this ballot. The issue here is that because we allow reuse, I wanted to minimize the changes to this method as much as possible, to avoid the need to introduce a new method and sunset the old. Further, with the fact that there’s a date transition, there is not a natural way to make the change you propose until *after* the effective date. I agree that it’s a potential for the future, but I do not believe there is a clean way of making that change before December, which is why I opted for this path. Changing to FQDN now would make it effective immediately, which we know is not the goal. I also suggest a small change in the introduction reusing the "subordinate

FQDNs" language, clarifying the ADN/FQDN language a bit, and pointing to the Appendix 2b validation method:

As I mentioned privately over email, I’m still fairly uncomfortable allowing this for .onion, because there is not a solid security reason to justify allowing it. I think it may make sense to hold off on this language until you can clarify if keeping wildcard for onion for these methods is absolutely essential for your support, given that it doesn’t really provide the same assurance. That’s why this is still flagged TBD: both to provide an opportunity for you to reconsider, and provide transparency for others to consider the asymmetry here (and perhaps convince you we can drop the Appendix B bits 🙂) We’re still discussing internally here whether to keep it, or whether to remove it and potentially seek another endorser if that is a deal breaker for you. But the best first step is providing fully drafted language to discuss and explore how it would work, while we and others consider if it should in the first place :) Finally, since method 6 is deprecated since 2020-06-03, it seems weird to

add a Note with a restriction date for "things issued after 2021-12-01". I guess it doesn't hurt to add for consistency but it still remains weird :)

This was drafted before SC42v2 was finished voting. If SC42 fails/failed, then the reuse period would have been 825 days from 2020-06-03, and that’s what this addressed. My plan is to include this language as part of the considerations of other ballots (I.e. there are two versions of this ballot, one with this language in case SC42v2 fails IP review, one without this language if it succeeds), since I hope to get this voted on before IP Review is completed for that.

[dzacharo]

As I mentioned privately over email, I’m still fairly uncomfortable allowing this for .onion, because there is not a solid security reason to justify allowing it. I think it may make sense to hold off on this language until you can clarify if keeping wildcard for onion for these methods is absolutely essential for your support, given that it doesn’t really provide the same assurance. That’s why this is still flagged TBD: both to provide an opportunity for you to reconsider, and provide transparency for others to consider the asymmetry here (and perhaps convince you we can drop the Appendix B bits 🙂) We’re still discussing internally here whether to keep it, or whether to remove it and potentially seek another endorser if that is a deal breaker for you. But the best first step is providing fully drafted language to discuss and explore how it would work, while we and others consider if it should in the first place :)

I was under the impression we agreed privately on the intent for wildcard validation using methods 18/19, and the introduction of the ballot suggests that validating the hidden service domain name exactly (two labels, <hidden service>.onion) with methods 18/19 would be sufficient to validate wildcards and subdomains. Did I misread?

To recap:

• If you're validating exactly label.onion, wildcards and subdomains are OK
• If you're validating foo.label.onion, wildcards and subdomains are NOT OK
• If you're validating via Tor Hidden Service CSR (Appendix B - 2b), wildcards and subdomains are OK

HARICA supports these expectations as reasonably secure for validating onion domains. Do you consider that the current proposal defines these expectations adequately or do we need more language tweaking? We would still like to endorse this ballot and had the impression we are in agreement about the intent of the introduced language for onion domains.

I also agree with your rationale why we should not change the ADN/FQDN language of 3.2.2.4.18 and Appendix B. Same thing with the effective dates, it wasn't a strong objection anyway. The clarification I suggested was for the introduction of the ballot which added a pointer to the proper section of the BRs (Appendix B - 2b) in addition to the "authorization by the Tor Hidden Service's long term master key having signed a CSR" which sounds "intimidating" for those reviewing the ballot who are unfamiliar with this terminology :-)

[dzacharo]

I forgot to add that we would still endorse even if we only allowed wildcard .onion domain validation using the Appendix B - 2b method.

[sleevi]

I was under the impression we agreed privately on the intent for wildcard validation using methods 18/19, and the introduction of the ballot suggests that validating the hidden service domain name exactly (two labels, <hidden service>.onion) with methods 18/19 would be sufficient to validate wildcards and subdomains. Did I misread?

To recap:

• If you're validating exactly label.onion, wildcards and subdomains are OK
• If you're validating foo.label.onion, wildcards and subdomains are NOT OK
• If you're validating via Tor Hidden Service CSR (Appendix B - 2b), wildcards and subdomains are OK

Right, I thought we'd agreed that validating foo.label.onion and issuing subdomains was NOT OK, but that you were still in favor of validating label.onion and subdomains being OK, while we at Google were still working through it.

If you're ok with label.onion being NOT OK; that is, relying only on 2.b for wildcards, treating the CSR method as effectively the same level of control over the entire DNS namespace, then we can remove the TBD and simplify this further :)

I also agree with your rationale why we should not change the ADN/FQDN language of 3.2.2.4.18 and Appendix B. Same thing with the effective dates, it wasn't a strong objection anyway. The clarification I suggested was for the introduction of the ballot which added a pointer to the proper section of the BRs (Appendix B - 2b) in addition to the "authorization by the Tor Hidden Service's long term master key having signed a CSR" which sounds "intimidating" for those reviewing the ballot who are unfamiliar with this terminology :-)

Gotcha. If I'm sure I'm not misunderstanding, and can simplify, then yeah, I can reword the introduction to tie those concepts together better, and reference the existing language.

[robstradling]

"that FQDN" seems to read as though it refers to "the validated FQDN", which doesn't make sense.

Suggestion: s/a separate validation for that FQDN using an authorized method/separate validations for each of those other FQDNs using authorized methods/

[sleevi]

So, this is for better or worse the existing language (3.2.2.4.8, 3.2.2.4.20), so I think it might be better to keep symmetry/consistency here, and perhaps clarify this language as follow-up. Do you want to file an issue for that so we can sweep it up in a spring cleanup?

[robstradling]

Makes sense. I've filed Issue #272 for this.

[Hecim1984]

🚀🎉💯

[CBonnell]

Do we need to update this method at all? SC42 passed, so it will not be possible to reuse any method 6 validations starting October 1st, which is before the effective date of this ballot (SC45).

[sleevi]

Technically SC42 hasn't passed the IP review period.

It's a little tricky to do the "two versions", but my approach with other ballots has been to "include the language as if it fails" as one commit, and then put another comment "and here's the language if it succeeds", and use two different commit ranges for the ballot.

So yeah, if SC42 succeeds, I think the updated version (and I need to double check the math, but I'm sure you're right) would simply be to "must not be used" this portion because of the SC42 interaction (i.e. we could have done it in SC42 itself, but doing it now will at least ensure there's no ambiguity about wildcards from folks who don't implement/notice SC42)

[sleevi]

@dzacharo @castillar Could you take another look and see if you're happy endorsing.

This gets rid of the asymmetry (as discussed on list) addresses the feedback from @CBonnell about capitalization.

[castillar]

Looks good to me!