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