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 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)?
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
