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

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 28 Jul 2016 16:31:51 -0700

On Thu, July 28, 2016 7:05 am, Rob Stradling wrote:
> > 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]

Well, to be fair, Andrew Ayer also pointed out the issues with monitoring
that the previous redaction proposal had.

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

Unfortunately, we're in the swirling nexus that is policy, practice, and
technology. While I've largely remained quiet on this list, and instead
channeled concerns through colleagues, I don't think it's a good idea for
redaction to remain in 6962-bis. I think separating it out into its own
specification, with its own enumeration of concerns, is useful.

My operating assumption is first and foremost that certificate revocation
does not work or scale at present. I can expand on that topic separately,
but I think most people on the list are familiar with the issues the
WebPKI faces there. Second, I assume that CAs will screw up and do things
out of stupidity or malice (if we can even distinguish the two) with every
knob and control given. I know, it's an uncharitable assumption for a
number of individuals, but history and evidence show that, collectively,
it's a historic trend that's getting worse, rather than better.

As such, these two combine to make it unlikely that Chrome will support
redaction as specified in 6962-bis. While there are technical reasons for
this (I'll expand on), I want to note the major objection is policy
reasons. Solving the policy problems is hard, and involves multiple
stakeholders: We need the CA/Browser Forum (and in particular, the
browsers) to mandate any adoption of policy controls (technical or
otherwise), we need CAs and site operators to elaborate on their threat
models and assumptions, and we'll likely need the IETF's support in
developing appropriate technical controls (such as the CAA policies I
mentioned on the thread Rob linked)

To me, specifying the technical means of redaction is the wrong ordering;
we should be specifying it last, rather than first. We need to discuss the
policy issues - what do we do when a CA screws up and what are the
possible consequences and implications of that screw up? Then we need to
discuss possible mitigations - e.g. CAA policies on redaction or
requirements on how the CA authenticates the request for redaction or
requirements for auditors to examine - and then we should visit the
technical. It's a fluid, multi-stakeholder conversation because I don't
think we're going to solve everything here, in TRANS, without
understanding how possible policies and mitigations could work, and what
they can or can't solve.

James' question I think is illustrative of this; the redaction-as-proposed
is trying to address, in part, the concerns I raised for 'un'redacting a
cert, and this makes trade-offs (such as to privacy) that seem difficult
to justify without understanding the policy or practice components. I
think most of 6962-bis is ready to go, but I've expressed particular
concern to my colleagues that it's not at all a given that redaction as
specified will meet our needs, because the other conversations haven't
been happening. I had hoped that my position on redaction would have
sparked the broader conversation, but it seems the focus of the redaction
proponents has been on the tech and politics of it, without addressing the
policy concerns.

To the more technical concern, I'm uneasy with how 'fixed' this redaction
method is. That is, it's coupled very closely to the use of dNSNames,
under the assumption that is the only thing that could or should be
redacted. However, as the CA/Browser Forum explores support for SRVNames,
which could be a significant boon to server security (by further scoping
certificates' capability), it's natural to question: Should SRVNames be as
redactable as dNSNames? Why or why not? Are there any special
considerations we'd have to consider? Is the service name of an SRVName
considered public or private? Why?

I think it's also useful to compare the logging of redacted certificates
(which at least one CA is doing with their own non-conforming log) against
those publicly logged certificates. If you do, you'll see the same thing I
am: redaction is hard for users to get right, and often results in
'obviously wrong' things. We could blame the CA for making it too easy,
but I also thinks it's reasonable to suggest that perhaps it's not as
important as some have claimed.

For a quick sample, consider:
- https://crt.sh/?serial=7f90c4250ef1f03f96fbe59fcb807857 : Redacted "www"
- https://crt.sh/?serial=7fe0023277563c51af6c299e9baed126 : Redacted "www"
- https://crt.sh/?serial=132c3fd48f0bb6391200e9f56d43272d : Redacted "www"
- https://crt.sh/?serial=2c1fa499a25405936098e31404c2dc8e : Redacted
"mystatus", despite it being a well-known URL

Is the ecosystem harmed by those mistakes? I would argue yes, but I know
others would argue no. Regardless, I think this is something that spans
beyond just the tech, involves questions that we (in the TRANS group) are
not well suited to answer, and feels very much like something better
removed into a separate spec and the full discussions about the tradeoffs
can happen there. It's very clear that the people actively participating
are passionate about the tech, but I think the issues go beyond the tech,
and I'd hate to see us settle on an incomplete or unsuitable solution.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 29 Jul 2016 10:52:58 +0100

On 29/07/16 00:31, Ryan Sleevi wrote:
<snip>
> "mystatus", despite it being a well-known URL

Hi Ryan.

FYI, here's a snapshot I just generated of all the "redacted 
precertificates" and (where known to CT) the corresponding certificates:
https://crt.sh/reports/20160729_redacted-precertificates.html

(See also https://crt.sh/redacted-precertificates - generated in 
realtime using the latest data; very slow to load; sometimes falls 
victim to crt.sh's automated long-running-query killer)

> can happen there.

Were going round in circles again.  :-(

Please review the "Name redaction - stay or go?" thread from 6 weeks ago 
[1].  FWIW, I too proposed moving redaction to a separate doc [2], but 
the chairs did not direct us to take this course of action.

There are plenty of folks with a strong preference to leave redaction in 
6962-bis, and there are plenty of folks with a strong preference to 
remove redaction from 6962-bis.

How on earth are we going to get this document through Last Call?

> It's very clear that the people actively participating

+1

[1] https://mailarchive.ietf.org/arch/msg/trans/DCIS3dwb-QbYY4ttZwlCd_zmmXY

[2] https://mailarchive.ietf.org/arch/msg/trans/046Cv3IQTNzNRq8LUQJsPMNeCTo

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

---

From: Eran Messeri <[email-masked]>
Date: Fri, 29 Jul 2016 12:23:29 +0100

It seems to me that:
- James is hinting the redaction mechanism as specified does not redact
"enough" (this problem is exacerbated by the lack of a proper threat model
- i.e. the attacks it should defend against and attackers' capabilities) .
- Ryan is saying that it's hard to evaluate the technical suitability of
the specified redaction mechanism since discussions around policy and
redaction of other fields did not take place.
- There's otherwise no endorsement of this mechanism from any party with an
interest in redaction.

All of this suggests that name redaction, as currently specified, is a
compromise that pleases no-one and there's not enough feedback to
significantly improve it.
Did I get this right?

Eran

On Fri, Jul 29, 2016 at 10:52 AM, Rob Stradling <[email-masked]>
wrote:

> (See also https://crt.sh/redacted-precertificates - generated in realtime
> using the latest data; very slow to load; sometimes falls victim to
> crt.sh's automated long-running-query killer)
>
> [1].  FWIW, I too proposed moving redaction to a separate doc [2], but the
> chairs did not direct us to take this course of action.
>
> 6962-bis, and there are plenty of folks with a strong preference to remove
> redaction from 6962-bis.
>
> [1]
> https://mailarchive.ietf.org/arch/msg/trans/DCIS3dwb-QbYY4ttZwlCd_zmmXY
>
> [2]
> https://mailarchive.ietf.org/arch/msg/trans/046Cv3IQTNzNRq8LUQJsPMNeCTo
>
> --
> Rob Stradling
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Fri, 29 Jul 2016 12:35:33 +0100

On 29/07/16 12:23, Eran Messeri wrote:
> "enough" (this problem is exacerbated by the lack of a proper threat
> model - i.e. the attacks it should defend against and attackers'
> capabilities) .
> - There's otherwise no endorsement of this mechanism from any party with
> an interest in redaction.
>

Yes.  Good summary.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 30 Jul 2016 18:35:33 -0400 (EDT)

On Fri, 29 Jul 2016, Eran Messeri wrote:

> - There's otherwise no endorsement of this mechanism from any party with an interest in redaction.

You mean from browsers? Because we have already seen redacted
precertificates. Unless you think those were just tests?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 30 Jul 2016 18:40:40 -0400 (EDT)

On Fri, 29 Jul 2016, Eran Messeri wrote:

> All of this suggests that name redaction, as currently specified, is a compromise that pleases no-one and there's not enough feedback to

<with chair hat>

I believe so.

If anyone thinks redaction as currently specified or with minor changes
should remain in the document, please speak up soon. Otherwise I think
the consensus is to remove the redaction from the current document.

Paul

---

From: Eran Messeri <[email-masked]>
Date: Sun, 31 Jul 2016 03:07:03 +0100

> precertificates. Unless you think those were just tests?

I mean CAs / domain owners who care about keeping some of their dns names
private.
We have seen redacted precertificates that were redacted using a mechanism
specified in one of the earlier drafts but grafted onto 6962 log (*not* a
6962-bis log). As Ryan Sleevi pointed out in his post, some of these
redactions did not make any sense. Either way the SCTs for these redacted
precerts would not be accepted by any TLS client that supports CT, not now
(with 6962 client) and not in the future (6962-bis clients).

Eran