Subject: [Trans] draft-ietf-trans-rfc6962-bis-18.txt - Redaction limitation

From: "Manger, James" <[email-masked]>
Date: Thu, 28 Jul 2016 16:35:35 +1000

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-masked]] On Behalf Of Eran Messeri
Sent: Wednesday, 27 July 2016 11:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Rob Stradling <[email-masked]>
Date: Thu, 28 Jul 2016 15:05:38 +0100

On 28/07/16 07:35, Manger, James wrote:
> 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 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)?

I think it's the best we want to do.

There was a discussion about redaction on the Chrome ct-policy list a 
few months ago.  The Chrome team decided that they would not support the 
redaction mechanism specified in 6962-bis-14, but indicated that they'd 
be willing to reconsider this if/when the various concerns expressed in 
[2] have been addressed.

Since then, as you noted, we've changed the redaction mechanism to allow 
the domain owner to do a dictionary attack if they see an unexpected 
precertificate.  This was in response to this concern...
   "As I indicated, we haven't really found a viable policy here that
    might allow for the 'un'redaction of certificates, short of
    observing them in the wild. This definitely leaves significant risks
    in the ecosystem, both for current and future domain holders, and
    makes it challenging to support redaction." [2]

> 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”.

Good idea.  I think §14.1 (Privacy Considerations -> Ensuring Effective 
Redaction) would be the appropriate place to add this detail.

> 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].

There seems little point in defining a redaction mechanism in 6962-bis 
that the Chrome team are unlikely to ever accept.  ISTM that they'd 
never accept HASH(salt + label), because it doesn't address the 
'un'redaction concern.

That said, if anyone has any alternative proposals for 'un'redaction, 
I'd love to hear them.

[1] 
https://groups.google.com/a/chromium.org/d/msg/ct-policy/fCt4Bm03GsI/jBbqE_QWBQAJ

[2] 
https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online