Subject: [Trans] Redaction

From: Jeremy Rowley <[email-masked]>
Date: Mon, 12 Dec 2016 17:30:20 +0000

We've been conducting short surveys of key customers to find out whether
redaction is of interest to server operators, what form of redaction they'd
like most, and why they are concerned about redaction. Here are the results
so far:

About 70% of customers surveyed were concerned about logging all server
certs into a CT log, primarily because of privacy concerns (100% of
respondents). Security concerns were lower (20%).  Offering redaction
satisfied 100% of the respondents concerns.  100% of the concerned
respondents wanted to support redaction of the left most label in the DNS.
50% wanted to support redaction of all subject information.  50% thought a
technically constrained intermediate would work.  The 50% who wanted to
support redaction of the subject information were not the same as the
technically constrained intermediate proponents. 

Jeremy

---

From: Matt Palmer <[email-masked]>
Date: Tue, 13 Dec 2016 09:21:34 +1100

> like most, and why they are concerned about redaction. Here are the results

Can you share the sample size, respondent size, survey methodology, and
(anonymised, if necessary) raw result data?  Summaries of response data are
far less enlightening than the actual responses data points.

- Matt

---

From: Steve Medin <[email-masked]>
Date: Mon, 12 Dec 2016 23:02:31 +0000

Yea, I'm stunned that 50% of respondents can operate in the strait jacket of
TCSC, although I can see that working for Plex's customer IP address privacy
concern.

> -----Original Message-----
> From: Trans [mailto:[email-masked]] On Behalf Of Matt Palmer
> Sent: Monday, December 12, 2016 5:22 PM
> To: [email-masked]
> Subject: Re: [Trans] Redaction
> 
> > We've been conducting short surveys of key customers to find out
> > whether redaction is of interest to server operators, what form of
> > redaction they'd like most, and why they are concerned about
> > redaction. Here are the results so far:
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Peter Bowen <[email-masked]>
Date: Mon, 12 Dec 2016 15:08:39 -0800

> TCSC, although I can see that working for Plex's customer IP address privacy

TCSC aligns with split-horizon DNS perfectly, so I'm not at all
surprised at this result.

---

From: Jeremy Rowley <[email-masked]>
Date: Mon, 12 Dec 2016 23:15:04 +0000

The survey is ongoing and informal, targeting our enterprise clients (over
SMB). I wanted to get some data in place (even if informal) so there was
some information about the need redaction. Although the survey is anonymous,
we allowed participants to opt-out of the privacy, which means I should have
real names to provide at the end of the survey. 

The list of questions:
1) Are you concerned about the Google requirement to log each certificate
issued in a public database?
2) If yes, why are you concerned? 
3) Would having a way to redact information from certificates alleviate your
concern? 
4) If yes, which proposal would you like DigiCert to support (select all):
Hide the DNS label, Hid the subject information, issue under a technically
constrained intermediate. 
5) Any additional comments?
6) Do you plan on using CAA? 

Jeremy

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Steve Medin
Sent: Monday, December 12, 2016 4:03 PM
To: Matt Palmer <[email-masked]>; [email-masked]
Subject: Re: [Trans] Redaction

> Can you share the sample size, respondent size, survey methodology, 
> and (anonymised, if necessary) raw result data?  Summaries of response 
> data
are

---

From: Steve Medin <[email-masked]>
Date: Tue, 13 Dec 2016 03:10:35 +0000

Yea, but when I talk about the Plex Pass certs, I'm not on the internal 
network privacy concern that split-horizon suits, I'm talking about how TCSC 
fits customers with static and limited domain ownership.

The concern I saw in my recent past was needing to frequently add names to a 
name constraint extension, and managing N generations of intermediate CAs as 
they are expanded with new public domain realty present in external DNS and 
directory names that represent localized global brand presence and expansion.

In that same past, I produced a 23kb TCSC as an interim to a dynamically 
modified managed service and enterprise RA. Fortunately, it broke zero 
browsers.

> From: Peter Bowen [mailto:[email-masked]]
> Sent: Monday, December 12, 2016 6:09 PM
> To: Steve Medin <[email-masked]>
> Cc: Matt Palmer <[email-masked]>; [email-masked]
> > Yea, I'm stunned that 50% of respondents can operate in the strait
> > jacket of TCSC, although I can see that working for Plex's customer IP
> > address privacy concern.
>
> TCSC aligns with split-horizon DNS perfectly, so I'm not at all surprised at 
> this
> result.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Dec 2016 19:47:45 -0800

> fits customers with static and limited domain ownership.

Can you expand on what use case for redaction doesn't fit into that
model? I don't believe we've heard such a use case articulated.

That is, while it's possible to imagine foo.corp.example.com as part
of a domain hierarchy, or even impendingmerger.example.com (to use
Peter Bowen's example), are you suggesting that you believe it to be
routine and normal that such certificate holders need

impendingmerger.example.com
impendingmerger.example.net
impendingmerger.example.org
impendingmerger.example
impendingmerger.pretend-the-next-word-is-a-cctld.example
impendingmerger.some-other-brand-name.example
(etc)?

Otherwise, the discussion of the limitations of TCSC to branding don't
really seem to fit to the topic of the redaction use cases discussed
so far, but it's possible you're imagining a yet undiscovered case?

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Dec 2016 19:52:44 -0800

Out of curiousity, did you expand on what "Hide the DNS Label" means?

In your original message, you suggested "100% of the concerned
respondents wanted to support redaction of the left most label in the
DNS." - but wildcards (which, in practice and as implemented by sane
and astute readers of RFC 6125, is limited to the leftmost label)
already accomplish this.

I guess I'm trying to distinguish between whether, based on your
survey, 100% of your customers are satisfied with
?.example.com

Or if they are also imagining
?.?.example.com

Arguably, it's much easier both in policy and in tech to restrict to
?.example.com, but it may be useful to confirm that was what you
meant.

---

From: Steve Medin <[email-masked]>
Date: Tue, 13 Dec 2016 18:49:44 +0000

What the 23kb TCSC I created taught me was that there are orgs that need:

<sitepurpose>.<brand>.<geography>
And
<sitepurpose>.<brand>.<catchy new TLD>

And all the permutations thereof, as well as the directory names of 80 data 
centers owing to a legacy of inserting the place of operation in the DN rather 
than corporate global or regional HQ. Brand is also deep, not only through 
acquisition but some orgs have a web presence of hundreds of microsites that 
are FQDN rather than query path.

When a TCSC is created, it has to envelope a legacy of naming that received 
certificates in another manner. That means a lot of decisions that were made 
without DNS name and directory name constraints need to be accounted for in 
the extension.

Once the TCSC is created, unless IT has an overbearing role in domain/brand 
approval, the deep branded organization is going to put a new name in the 
second/third level domain for every launch. That's another key ceremony, a new 
intermediate on the AIA CA Issuers URI, and ALL CAPS in the certificate 
issuance email reminding the server admin to rip out the old intermediate and 
add the new one.

Ten brand launches later, 11 different TCSCs, wait, which one do I install? I 
don't intend to offend server admins, this isn't a matter of competence, it's 
a matter of the number and variety of tasks carried by the typical admin in 
the type of organization I describe.

> From: Ryan Sleevi [mailto:[email-masked]]
> Sent: Monday, December 12, 2016 10:48 PM
> Cc: Peter Bowen <[email-masked]>; Matt Palmer
> <[email-masked]>; [email-masked]
> > Yea, but when I talk about the Plex Pass certs, I'm not on the
> > internal network privacy concern that split-horizon suits, I'm talking
> > about how TCSC fits customers with static and limited domain ownership.
>
> Can you expand on what use case for redaction doesn't fit into that model? I
> don't believe we've heard such a use case articulated.
>
> That is, while it's possible to imagine foo.corp.example.com as part of a
> domain hierarchy, or even impendingmerger.example.com (to use Peter
> Bowen's example), are you suggesting that you believe it to be routine and
> normal that such certificate holders need
>
> really
> seem to fit to the topic of the redaction use cases discussed so far, but 
> it's
> possible you're imagining a yet undiscovered case?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Dec 2016 18:51:15 +0000

> What the 23kb TCSC I created taught me was that there are orgs that need:

TCSC means a sub-CA with a nameConstraints field?

---

From: Steve Medin <[email-masked]>
Date: Tue, 13 Dec 2016 18:53:48 +0000

Yes, technically constrained subordinate CA. When the subordinate's EKU 
contains TLS server auth, constraint means a finite list of DNS names and 
directory names in the name constraints extension.

> From: Salz, Rich [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2016 1:51 PM
> To: Steve Medin <[email-masked]>; Ryan Sleevi <ryan-
> [email-masked]>
> Cc: Matt Palmer <[email-masked]>; [email-masked]; Peter Bowen
> <[email-masked]>
> Subject: RE: [Trans] Redaction
>
>

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 13 Dec 2016 22:34:45 +0000

We explained in the instructions that this only meant the left-most label of 
the DNS. We are about to roll the survey out to a larger customer base. I'm 
planning on clarifying that question as most people don't read instructions. 
Note, this survey was only sent to customers we categorize as "enterprise", 
meaning Plex and similar mass issuance customers were not included.  I should 
include them for round 2.

Tl;dr - I meant left-most label, but it could have been confused.

-----Original Message-----
From: Ryan Sleevi [mailto:[email-masked]]
Sent: Monday, December 12, 2016 8:53 PM
To: Jeremy Rowley <[email-masked]>
Cc: Steve Medin <[email-masked]>; Matt Palmer <[email-masked]>; 
[email-masked]

In your original message, you suggested "100% of the concerned respondents 
wanted to support redaction of the left most label in the DNS." - but 
wildcards (which, in practice and as implemented by sane and astute readers of 
RFC 6125, is limited to the leftmost label) already accomplish this.

I guess I'm trying to distinguish between whether, based on your survey, 100% 
of your customers are satisfied with ?.example.com

Arguably, it's much easier both in policy and in tech to restrict to 
?.example.com, but it may be useful to confirm that was what you meant.

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 13 Dec 2016 22:40:56 +0000

Customers aren't required to solely the TCSC.  They could use the TCSC for the 
ones they want redacted and a standard intermediate for the others. Most of 
the customers I've spoken with don't plan on redacting a lot of domains. There 
are just certain domain paths they want to make secret. For them, the TCSC is 
perfect because they can redact all sub domains while still leaving all their 
externally facing stuff on a regular intermediate.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Steve Medin
Sent: Tuesday, December 13, 2016 11:50 AM
To: Ryan Sleevi <[email-masked]>
Cc: Matt Palmer <[email-masked]>; [email-masked]; Peter Bowen 
<[email-masked]>

> > internal network privacy concern that split-horizon suits, I'm
> > talking about how TCSC fits customers with static and limited domain 
> > ownership.
>