Thanks for bringing this up. Understanding the "Why"s is vital to moving forward on this draft. To that end, the primary, specific use-case for this need to be able to redact some parts of an FQDN in a precert is split-horizon DNS. When effectively used, an external DNS query will not see the same responses as one received internally to a corporate network. Because of this, a corporate entity might have DNS naming structures which should not be made widely known and could not be easily discovered by external parties.
The primary need is for subjectAltName:dNSName values to be redactable, as that is the primary way FQDNs are included in a certificate. The "Why" for commonName values is simply that this field is (unfortunately) still used quite widely as part of DNS name/certificate validation. It's end-user (in this case, TLS administrators at companies deploying split-horizon DNS and wanting to maintain secrecy of some parts of their internal DNS structure) expectation that all fields housing an FQDN be redactable in the same or similar ways. I would like to see a solution that allows for redacting commonName values, but ultimately I can understand and agree with keeping the scope more narrowly focused on subjectAltName values; not only because commonName is deprecated, but also because subjectAltName:dNSName is much more well-defined and, I think, easier to define a redaction spec for. On Sat, Nov 19, 2016 at 10:45 PM Ryan Sleevi <[email protected]> wrote: > 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
