Tarah, It seems like it might be more useful to understand the "Why"s of Clint's proposals, before digging too much into the "How". Do you see external SMEs being useful there?
Though I have some trouble with Clint's proposals, I think if we can figure out the "Why" for some of the suggestions, we might be able to explore the technical space to see if there's momentum for a draft (or, perhaps more aptly, pull requests to the redaction draft). However, unless we know why, it seems difficult to judge the complexity cost (compared to alternatives) or if the implementation cost is justified. For example, redacting the commonName, as proposed by Clint, might simply be addressed by requiring that redacted domain labels respect the deprecation notice from RFC2818 and furthered by RFC6125 - namely, don't use commonName for DNS names, use the subjectAltName. If systems that need redaction can't support it, perhaps the cost should be born by updating these systems to reflect the past 18 years of deprecation notices of commonName (see https://tools.ietf.org/html/draft-ietf-tls-https-00#section-3.1 , which became 2818) This is where understanding "Why" can help make more informed decisions and help focus the activity on the drafts. On Fri, Nov 18, 2016 at 10:39 PM, Tarah Wheeler <[email protected]> wrote: > Some of the methods of implementing these suggestions seem complex, but > there’s a lot of good ideas here. Clint, what do you think of my suggestion > on asking some outside SMEs to chime in? > > Respectfully, > > Tarah Wheeler > Principal Security Advocate > Senior Director of Engineering, Website Security > Symantec > [email protected] > > From: Clint Wilson <[email protected]> > Date: Friday, November 18, 2016 at 7:53 AM > To: Tarah Wheeler <[email protected]>, Eran Messeri > <[email protected]> > > Cc: Rob Stradling <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 > > Hi all, > > I’d like to propose that the redaction I-D allow for redacting labels above > the 2nd level domain, as determined by the public suffix used, of > SAN:dNSName values. For example, redaction of “secret.example.com” would > result in “{redacted}.example.com” while “secret.example.co.uk” would result > in “{redacted}.example.co.uk”. The I-D should also allow for redaction of > some subject DN values, especially commonName (the unfortunate reality is > this field is still used… frequently). > > To (hopefully) address some of the concerns redaction has encountered in the > past, we’d like to propose the addition of a “redaction signal”. This is > essentially the domain owner publicly signaling that they have opted-in to > redaction of their certificates. While this does not solve the issue of a > client being unable to authoritatively determine that the host name being > observed during certificate verification is the one intended in the redacted > precertificate, it does introduce a mechanism for the entity that CT is > intended to protect to assert their acceptance of this tradeoff. > > We haven’t identified the precise mechanism via which this redaction signal > would be communicated, but two options we want to throw out are CAA records > and HTTP header (such as the proposed Expect-CT header). > > We also have not identified who/what should verify the redaction signal and > when. A CA should check for the presence of the redaction signal before > submitting a redacted precert, but if that were the only entity checking, we > would need to determine a way to publicly audit this check. A Log Operator > might check for the presence of a redaction signal before accepting a > redacted precert, but this introduces a new requirement for logs to make > some form of connection to the domain(s) in the precert. A relying party > might check for the presence of the redaction signal when verifying the > SCTs, but the lack of a redaction signal at the time of connection does not > necessarily represent the state of redaction signal at the time of precert > submission. A log monitor might check for a redaction signal when a precert > is discovered for a domain of interest, in order to help determine whether a > discovered precert might represent misissuance. > > Cheers! > > On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler <[email protected]> > wrote: >> >> I’m glad to hear it, and looking forward to it. >> >> I’d like to ask about the two things that seem really necessary to me; >> sometimes a technical RFC lacks within it the rationale for why we do >> things. I’ve been creating essentially a white paper at the same time as >> writing comments and some prescriptive thoughts on privacy. >> >> There’s a fundamental disagreement here over why we would want privacy and >> transparency on a variable slider, and ultimately, it comes down to the >> motivations of the entities involved. Some of us want to sell a product that >> provides privacy, and some of us want to sell a product that is only >> possible with transparency. Let’s not pretend that we’re not all faced with >> differing incentives. >> >> I’ve been on this list for a while, and very quiet because in general, it >> seems like a fool’s game to try to argue people out of acting in their best >> interests. It wasn’t until now that I had a solid idea of what would be >> useful to this process. >> >> There are some very smart people in information security. There are those >> with strong inclinations towards advocating privacy at multiple levels of >> organizational size from a individual to a YUUUUUUGE company (sorry, >> couldn’t resist, and we all need to laugh a bit now and then). There are >> those who see full transparency as a virtue and I can certainly understand >> why, both on an ideological and a financial level. >> >> I’ve watched this situation be cautiously talked around for months now, >> and I’d be interested to hear people’s thoughts on asking some unassailably >> corporate-neutral experts on both sides of this debate to provide guidance. >> Whose opinion are you interested in hearing on whether or not permitting >> certificate privacy and accepting it as a browser standard is a good idea? >> I’m putting myself and Symantec out there in a vulnerable way; I and we >> might not always hear what we want to hear, but every one of us wants to >> make the internet better in the way we believe will work best. >> >> Respectfully, >> >> Tarah Wheeler >> Principal Security Advocate >> Senior Director of Engineering, Website Security >> Symantec >> [email protected] >> >> From: Eran Messeri <[email protected]> >> Date: Tuesday, November 15, 2016 at 6:17 PM >> To: Tarah Wheeler <[email protected]> >> Cc: Rob Stradling <[email protected]>, "[email protected]" >> <[email protected]> >> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 >> >> AIUI >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
