[cabf_validation] Threat vectors for domain validation methods

[Rick Andrews]

Kirk,

 

This suggests to me that Robin’s proposal to add a public key to the Request Token is more than sufficient; in fact, the public key alone is sufficient and the Request Token is superfluous. 

 

-Rick

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Saturday, December 05, 2015 10:10 PM
To: validation at cabforum.org
Subject: [cabf_validation] Threat vectors for domain validation methods

 

There has been discussion in the Validation Working Group about the need to identify relevant threat vectors when adding limitations to domain validation methods, such as a requirement that a Random Value, Request Token, or Test Certificate not be re-used.  

 

Some agree that we must first identify the threat vectors before imposing limitations, some disagree and think we should build in security even against threat vectors that are not presently known or identified.  (I am in the latter camp.)

 

I noticed one potential threat vector that was encountered and addressed for Let’s Encrypt – see links and excerpts below.  There is a clear danger from re-use of credentials that a hacker can reproduce and replay.  Let’s keep this in mind as we continue to work on the domain validation ballot.

 

 

https://www.agwa.name/blog/post/duplicate_signature_key_selection_attack_in_lets_encrypt

 

*** As we saw above, such a scheme is vulnerable to a duplicate signature key selection attack. A digital signature does not uniquely identify a key or a message. So if Mallory wants to obtain a certificate for Bob's domain, she doesn't need to alter Bob's DNS records if Bob has already published his own signature in the DNS. Mallory just needs to choose her ACME account key so that her validation object has the same signature as Bob's. When Mallory sends her validation object to the ACME server, the server will query Bob's TXT record, see that Bob's signature matches the signature of Mallory's validation object, and conclude incorrectly that Mallory put the signature in Bob's DNS, and is therefore authorized to obtain certificates for Bob's domain. ***

 

https://www.ietf.org/mail-archive/web/acme/current/msg00484.html

 

*** The real problem is that ACME makes false assumptions about signatures.  It assumes that a signature uniquely identifies a (public key, message) tuple, which RSA does not guarantee.  To fix this, I propose simply publishing the authorized account public key (or a hash of it) in the TXT record (for DNS challenges), in the TLS certificate (for DVSNI), or in the file (for Simple HTTP).  Checking that the account public key is present in a place that only the domain administrator controls should be sufficient to establish that the domain authorizes that account public key to issue DV certificates for it.  There is no need for signatures, nor do I see any need for tokens. ***

 



 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20151208/0d4ee62a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20151208/0d4ee62a/attachment.bin