Re: [Trans] White out (was Re: Reviving Redaction)

[Jeremy Rowley <[e-mail]>]

I highly doubt there would be a court order. However, I think linking to the 
applicable cease and desist, take down request, privacy issue, etc. is 
reasonable.



From: Ben Laurie [mailto:[e-mail]]
Sent: Tuesday, March 7, 2017 10:44 AM
To: Rob Stradling <[e-mail]>
Cc: Jeremy Rowley <[e-mail]>; [e-mail]; Peter Bowen 
<[e-mail]>
Subject: Re: White out (was Re: [Trans] Reviving Redaction)







On 6 March 2017 at 23:30, Rob Stradling <[e-mail] 
<mailto:[e-mail]> > wrote:

I think the "white out" proposal that was discussed at the CT Policy Days is 
likely to be far more controversial than the various redaction proposals.

"White out" proposes a mechanism for removing or omitting entire certificates 
from logs whilst still "proving" that those certificates are "included". 
Relying parties have to trust the log to only "white out" certs for good 
reasons.  ISTM that this defeats most of the purpose of CT!

>From https://tools.ietf.org/html/rfc6962#section-1...
  "Certificate transparency aims to mitigate the problem of misissued
   certificates by providing publicly auditable, append-only, untrusted
   logs of all issued certificates."

ISTM that supporting "white out" would turn that sentence into this...
  "Certificate transparency aims to mitigate the problem of misissued
   certificates by providing publicly auditable, modifiable, trusted
   logs of some issued certificates."

That sounds not too dissimilar to the WebPKI minus CT!



I think if this kind of thing is going to work, you have to also log the 
reason for removing the cert (e.g. link to court order :-).




On 06/03/17 22:26, Jeremy Rowley wrote:

On the CT days, there was an emphasis on a distinction between white washing
a cert (removing it from CT) and redaction. Is the white washing in scope
for the Trans list and this discussion or should it be separate?

I ask because two of the main arguments cited for redaction tend to be:
1) Network/New project mapping reveals
2) Inclusion if PII in logged certs

If white washing address the second concern, a specification around that
process could eliminate a good deal of the push for redaction.


-----Original Message-----
From: Trans [mailto:[e-mail] <mailto:[e-mail]> ] 
On Behalf Of Rob Stradling
Sent: Monday, March 6, 2017 2:39 PM
To: Ben Laurie <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> ; Peter Bowen <[e-mail] 
<mailto:[e-mail]> >
Subject: Re: [Trans] Reviving Redaction

On 06/03/17 21:22, Ben Laurie wrote:

I think you can waste a lot of brainpower on redaction, but really the
answer is: if you don't want to publish your names, then don't use a
mechanism that requires you to.


I agree that that's the ideal answer, but as we've seen, there is resistance
to that answer from various participants in the CT ecosystem.

There are alternatives: name-constrained sub-CAs.


We removed that option from 6962-bis.  It's now in
draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're
unlikely to ever support it (at least in its current form).

Private CAs. You can even have private CT to go along with them.


Private CAs don't suit every use case, AFAIK.

Why mess up a protocol whose intent is to show everything?


Because Security and Useability aren't always in perfect harmony?

Much as I'd love to stop wasting brainpower on redaction, I think it's a
conversation that needs to continue for now (although not indefinitely!)

On 6 March 2017 at 21:16, Rob Stradling wrote:

    On 06/03/17 06:06, Peter Bowen wrote:
    <snip>

        8) The only way to get the content of a full certificate is to
        have a
        full certificate.

        Rationale: An alternative option is to have some sort of escrow

key

        that can "unlock" a precertificate.


    In previous iterations of 6962-bis, we proposed a redaction
    mechanism that envisaged replacing domains labels with ?s in
    precertificates. That mechanism was deemed problematic by the Chrome
    team precisely because "The only way to get the content of a full
    certificate is to have a full certificate".
    What recourse does a domain owner have when they discover a
    precertificate for their domain space that they don't recognize?
    How do they figure out whether the (pre)cert was misissued or
    whether it was legitimately requested by a different team within
    their organization?

    The redaction mechanism that's documented in
    https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3

<https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3>

    attempted to find a solution to this problem of recourse by swapping
    ?s for a hash of the unredacted domain.  However, this mechanism has
    also been deemed problematic, because it could be trivial to
    determine unredacted labels via dictionary attacks.

    I think a "sort of escrow key" may be the only viable way to
    construct a redaction mechanism that is deemed non-problematic by
    everyone.

        This quickly turns into 'where do we keep the escrow key?' and
        'who gets
        to access the escrow key?'.  If there is no such thing, then these
        questions don't exist.


    I think these questions will need to be both asked and answered,
    although I'd be delighted to be proved wrong.

        Do others agree that these are true and can be used as givens for
        reviewing any proposed designs?


    Your other points all LGTM.


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