[cabf_validation] Random Value Reuse

[Wayne Thayer]

The challenge with new definitions is that the secret is also a nonce and the nonce can be reused, so IMO it’s not really a nonce. Creating new terms without wrapping all the rules into the definitions results in something like this:

Random Value: A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy.
Nonce: A Random Value that is not intended to be kept secret and may not be reused except as specifically permitted.
Secret Random Value: A Random Value that may only be shared with specific recipients and should not be published on a website or in DNS.

What do others think? New definitions, or simply a restriction on mixing the random value from methods 2 and 4 with methods 6, 7, and 10?

Thanks,

Wayne

From: Tim Hollebeek <THollebeek at trustwave.com>
Date: Friday, October 20, 2017 at 6:40 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>, Wayne Thayer <wthayer at godaddy.com>
Subject: RE: Random Value Reuse

So, the problem is that it is very confusing to use the same term for two completely different things.  While that may be perfectly fine for non-technical people who aren’t interested in understanding the security properties of the methods, it is very confusing for those of us who are interested.

There are some cases where we are using random values as secrets, and it is vitally important that they remain secret, and there are some cases where we are using random values solely because they cannot be known before they are generated, so they can guarantee freshness (e.g. reject stale data left in place from a previous validation) and avoid replay situations.  That’s a classic example of a nonce.

Maintaining the security properties of these methods as they change over time is going to be a challenge.  I don’t want to have to constantly remember which uses of the term “random value” means what.

-Tim

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Kirk Hall via Validation
Sent: Thursday, October 19, 2017 6:48 PM
To: Wayne Thayer <wthayer at godaddy.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Random Value Reuse

Wayne, I very much like (prefer) an approach that puts the rule in each of the validation methods that uses Random Value (like you have drafted below), which is much better than creating a new definition that’s hidden away on the Definitions page (such as “Nonce”) and then using that for some of the methods instead of Random Value.  Much clearer and simpler.  So I think we support this.

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Wayne Thayer via Validation
Sent: Thursday, October 19, 2017 1:38 PM
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [EXTERNAL][cabf_validation] Random Value Reuse

On this morning’s call, I volunteered to make a proposal to clarify when reuse of Random Values across validation methods is permitted.

I believe the goals of this change are:

  1.  Forbid the use of a Random Value that is meant to be published somewhere (methods 6 (website), 7 (DNS), or 10 (TLS)) to approve a request under methods 2 (whois contact) or 4 (constructed email).
  2.  Permit the use of the same Random Value across methods 2 and 4, and across methods 6, 7, and 10

Am I missing anything?

I believe it was at the last F2F where someone pointed out that the Random Value in methods 2 and 4 is a secret, while the random value in methods 6, 7, and 10 is a nonce. I started to approach this change by adding definitions for ‘secret random value’ and ‘nonce’. I’m still willing to take that approach, but after some thought I’m not convinced what we’re talking about is strictly a nonce, and I think there’s an easier way to fix this.

My proposal is to add the following sentence to methods 2 and 4:

The Random Value MUST NOT be re-used by any other validation method.

The existing language for method 2 already forbids combining methods 2 and 4:

The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.

The existing language allows the Random Value from methods 6, 7, or 10 to be reused for different validation methods within the same request.

Does this simple change solve the problem? If so, then I think we can roll it into a ballot containing other 3.2.2.4 fixes.

Thanks,

Wayne



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171020/e14137d2/attachment-0001.html>