TXT-record to configure multi-VA

Feature Requests
1

I have a suggestion to create the possibility for domain owners to configure how multi-VA should be treated for their domain.

And that is a TXT-record. This special TXT record is fetched from all network locations, and this TXT-record MUST be consistent. This TXT record then decides what happens next.

Note that since this TXT record is fetched from ALL locations, and this record must then be consistent in label and content across all 4 requests, its not possible for an attacker to in any way cheat with this record.

could be like:
_letsencrypt-config.domain.tld IN TXT “v=1; vs=(main, [NUMBER], random, all); vc=(single, all, majority); vr=(valid, consistent, strict, very-strict); onerror=(ignore, fail, fail-label, fail-all);”

Now to specification:
v = Version number. 1 for this time.

vs = Validation strategy. - Decides how LE will push out queries.
“main” means it will only validate from main server
[NUMBER] means that the DNS-server will receive [NUMBER] requests for each record from [NUMBER] random different locations. [NUMBER] cannot of course be higher than the number of server locations LE have.
“random” means that the DNS-server will receive a random number of requests from a random number of different locations, for each record.
“all” means that it will always receive 4 requests, one from each location, for each item.

vc = Validation count - Decides how results are intepreted.
“single” = Only a single validation attempt need to validate. This means a more insecure approach since a attacker only needs to compromise one of the 4 network paths to succeed. But this could be desirable for some domain owners which have buggy/weird DNS server setups which are inconsistent, and they want to succeed at first hit on a “good” response.
If different CAA policies are stumbled upon, the most “generous” policy will be applied.
“all” = All validation attempts must validate.
If different CAA policies are stumbled upon, then a policy that fulfills all CAA policies combined, will be applied.
“majority” = A majority of the validation attempts must validate. Rounded upwards, so a tie is considered a success if the success contains multiple records. If the tie consist of single records only, then fail.
if different CAA policies are stumbled upon, only policies that are present in a majority of the requests are used to build the “combined” policy.

vr = Validation requirement - Decides how strict it should be when comparing records
“valid” = They just need to be valid, basically be as valid as if a single server hitted. (the config TXT still needs to be consistent)
“consistent” = The content and label of the DNS record must match.
“strict” = More stricter consistency check - TTL must also match.
“very-strict” = strictest. This also means serial and SOA must also match completely, thus all requests must respond identically in all regards.

onerror = Decides what should happen on an error.
“ignore” = Ignore the error completely, as if the request never happened. Note that if all 4 requests result in a ignore, it would obviously fail, but otherwise, in configurations where for example all is specified, and a single authorative server is down or has DNSSEC sheniningans, then “all” would skip that server. This means that a attacker, by attacking a single authorative server (DDoS) or breaking one of the network links, could get one or more validation paths (but not all) ignored, but if that is the domain owner’s wish, respect him.
“fail” = Fail this request only, like if NXDOMAIN/404 was received for this challenge.
“fail-label” = Fail all requests associated with this label. (meaning a majority config will fail if a SERVERR is received instead of a single server returning a inconsistent or non-validating record)
“fail-all” = Fail all outstanding requests for this domain (all outstanding authorizations for this domain will fail)

default (today’s policy) would be “v=1; vs=all; vc=all; vr=consistent; onerror=fail-label;”

By adding such a configuration record possibility, the domain/account whitelist could be dropped, and those that have buggy/weird configs, needs to use a config record.

2

I would agree with you, but I think the whitelist is only intended for temporary use in order for those people to prepare for the change. It's not intended to stay in the system.

3

yeah I know, my idea is more to give the domain owner more control on how multi-VA is used.
Even stricter config than the “default” can be specified.

4

Hi @sebastiannielsen

my personal position: I think this is a bad idea.

Why? Multi-Validation is a great new feature that hardens creating certificates.

There shouldn’t be options to make that new system weaker.

With the result: Some Letsencrypt certificates are “hard”, some are “weak”. But it’s not visible - certificate = certificate.

I would prefer an opposite option:

If http validation is used and if the domain name has ipv6 and ipv4 addresses, Letsencrypt prefers ipv6.

So the ipv4 isn’t checked.

I would like an option:

If http validation is used, check ipv6 and ipv4. Both must have the correct value.

4 Likes
5

Yes, Let’s Encrypt has described this added security feature as a benefit to overall security of the PKI and so site operators won’t be able to permanently opt out of it.

3 Likes
6

Hi @sebastiannielsen! Thanks for the proposal. It sounds like there are two components:

  • Use a DNS mechanism to ask for exceptions to the multi-perspective validation, for at least as long as our exceptions period lasts.

This would potentially reduce our overhead in managing exception requests, but it would also require an extra DNS request, and processing of a new record type. I think that would add unnecessary complexity for a temporary feature.

  • Use a DNS mechanism to allow site owners to opt into a stricter validation policy (i.e. require all viewpoints to return successfully).

I think this would not be effective. If an attacker can cause 3 of 4 validation viewpoints to succeed (including the primary location), that attacker could also send a different version of the validation strategy response that you are proposing, thus convincing the CA to act as if the stricter validation policy hadn’t been applied.

4 Likes
7

My idea was that site operators that have weird load balancing or caching setups on his HTTP/HTTPS endpoint, or strict rate-limits or low quotas (limited number of DNS requests before it start billing, for some free DNS providers) on his DNS-server, should be able to opt out of the multi-perspective validation, for as long as the site owner wants, but also be able to ask for stricter checks.

Remember also that I suggested that the multi-validation DNS record will always be bound of the multi-validation steps regardless of what the record says:
“This special TXT record is fetched from all network locations, and this TXT-record MUST be consistent.”

Note that lessening security for one site operator with his approval shouldn’t matter, since any misuse of the weakened security, will only affect that particular site operator.

Thus it should be possible for a site operator to basically opt-out or opt-in of most security features not required by CAB forum (in the same way a site operator can turn on/off stapling in his certificate) provided that this opt-in/opt-out indication can be read in such a secure fashion that it does not defeat the purpose or threat-model of the security feature itself.

Since I proposed that multi-VA should always be used for fetching the multi-VA policy record, a site owner could easily specify that each record should only be checked from 1 random location only, and then he would only receive 4 requests for the multi-VA record, and then a single request for each other record that is related to letsencrypt.

Thus saving on site owner’s rate limits, quotas and such, and allowing the site owner full control of the security level, without hurting the security for those that want the high security.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.