The redaction mechanism in draft-ietf-trans-rfc6962-bis-18 hides a DNS label by replacing it with HASH( key-id + label) in a logged pre-certificate. The key-id appears in the pre-certificate so anyone can do a dictionary attack: see a precertificate in a log, then try possible labels until the hash matches. If you wanted to redact, say, 8-digit customer ids used as DNS labels it would only take seconds for anyone to undo a redaction by calculating a 100 million hashes.
Is this the best we can do? Is this the best we want to do (eg so a domain owner can do the dictionary attack with all the labels the domain uses if they see an unexpected pre-certificate)? If this is so, I think this limitation needs to be stated clearly in §4 “Private Domain Name Labels”, and §13 “Security Considerations”. Perhaps: “Redaction can obfuscate a domain name label, but if it is feasible to enumerate all possible labels (because they don’t have sufficient entropy) then the redacted label can be recovered”. If this is not so, using HASH(salt + label) for redaction should work; where the salt is conveyed in a certificate extension that is removed when constructing the pre-certificate [as someone else suggested]. -- James Manger From: Trans [mailto:[email protected]] On Behalf Of Eran Messeri Sent: Wednesday, 27 July 2016 11:59 PM To: [email protected] Cc: [email protected]; [email protected] Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-18.txt Updates in the draft 18: - Fixing the specification of the REDACT function - it was incorrectly calling for the use of length-prefixed concatenation everywhere, but that is only necessary for the values that are concatenated for hashing. - Indicate that only DNS-ID labels can be redacted using the specified redaction mechanism (end of section 4.2.2.<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-18#section-4.2.2>) - Certificates with other types of fields of the subjectAltName extension that should not appear in public log should be logged under a name-constrained intermediate CA cert described in section 4.3<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-18#section-4.3>. On Wed, Jul 27, 2016 at 2:39 PM, <[email protected]<mailto:[email protected]>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-18.txt Pages : 55 Date : 2016-07-27 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Trans mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
