Subject: [Trans] Name redaction consensus call

From: Melinda Shore <[email-masked]>
Date: Fri, 12 Aug 2016 16:17:16 -0800

Hi, all:

Since there was no comment at all on the proposal to retain
name redaction, we appear to have complete agreement that
it should go.  We'll go back into wglc when a new version
is submitted.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 13 Aug 2016 00:36:03 +0000

> Since there was no comment at all on the proposal to retain name redaction,
> we appear to have complete agreement that it should go.  We'll go back into
> wglc when a new version is submitted.

I did reply that I wanted to keep redaction, but agree that consensus is against it.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Jeremy Rowley <[email-masked]>
Date: Sat, 13 Aug 2016 05:11:05 +0000

I also objected to removing name redaction, but I think it was just Rich and
I.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, August 12, 2016 6:36 PM
To: Melinda Shore <[email-masked]>; [email-masked]
Subject: Re: [Trans] Name redaction consensus call

> Since there was no comment at all on the proposal to retain name 
> redaction, we appear to have complete agreement that it should go.  
> We'll go back into wglc when a new version is submitted.

I did reply that I wanted to keep redaction, but agree that consensus is
against it.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz
_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Eran Messeri <[email-masked]>
Date: Sat, 13 Aug 2016 14:44:25 -0700

It would help a lot if those objecting to name redaction would provide
their arguments against it (maybe as a link to another thread / document,
as to not derail this thread).

FWIW, my intention (and, to be clear, that's just me, before consulting the
other authors of 6962-bis) is to move name redaction to a draft of its own
rather than get rid of the concept, if the decision will be to move it out
of 6962-bis. That is so we can continue discussing/refining it to suit the
threats/concerns it intends to address.

Eran

---

From: [email-masked]
Date: Sat, 13 Aug 2016 22:19:16 +0000

> threats/concerns it intends to address.

FWIW, "figure it out later" seems like entirely the right plan to me, esp if that doesn't slow down the WG.

S.

---

From: Sanjay Modi <[email-masked]>
Date: Mon, 15 Aug 2016 18:52:42 +0000

Melinda,
We have provided feedback on redaction earlier on this forum and also on
some other public forums.
We've heard loud and clear from customers in many product segments that
they need redaction for publicly-trusted certificates because
they value privacy.
We don't think redaction as currently specified in RFC 6962-BIS makes much
sense; it's too complicated and doesn't protect the privacy of domain
owners. If
un-redaction is possible by just throwing some cycles at it, then nothing
has really been redacted.

To summarize the position we've already stated: we feel that the issuing CA
must be approached by the domain owner to achieve disclosure of the full
contents of a redacted pre-certificate. Policies and procedures should be
crafted to
standardize that, but they shouldn't be tied to a discussion on redaction
because they are needed even when a pre-certificate is not redacted.
 
A redacted pre-certificate contains 95% of the information in the
certificate, and
fully demonstrates CA compliance to policies and requirements. A redacted
pre-certificate contains 100% of the information needed for a harmed party
to take
recourse (issuer, serial number, notBefore, owned domains in the redacted
CN
and DNS SANs). The recourse for a redacted pre-certificate is exactly the
same as the
recourse for an un-redacted pre-certificate: approach the CA, within the
terms of its
Relying Party Agreement, CP, and/or CPS and state a claim that a
certificate
has been issued in error and it encroaches on the rights and property of
the
complainant. The only action that can be taken by the issuer is to revoke
the certificate. Whether a browser can or cannot consume certificate status
information in a timely manner is out of the scope of this RFC.
 
We favor the full redaction as originally proposed in earlier versions of
6962-bis. Redaction blocks FQDN components that provide intelligence about
internal networks that was designed to be parsed and understood only by
employees and peer-to-peer systems privy to internal DNS. Redaction blocks
geographical data embedded in FQDNs; it blocks harvesting of high value
targets prior to attack. Some of our largest customers have had structured
naming conventions for many years; forcing them to use wildcards or
redesign
their DNS hierarchy to preserve privacy in an eTLD+2 policy world requires
massive network renaming far beyond the staffing levels of current day IT
organizations. The type of very large organization that has a long and
vastly deployed legacy of intelligent naming and needs redaction also has
strict IT policies that require certificates to be signed by public
audited CAs.
 
If redaction is completely removed from 6962-bis, we believe that it should
be moved to another RFC so that work can proceed.

- Sanjay

---

From: Eric Mill <[email-masked]>
Date: Mon, 15 Aug 2016 15:44:14 -0400

On Mon, Aug 15, 2016 at 2:52 PM, Sanjay Modi <[email-masked]>
wrote:

> certificate, and fully demonstrates CA compliance to policies and
> requirements. A redacted
> to take recourse (issuer, serial number, notBefore, owned domains in the
> redacted
> CN and DNS SANs). The recourse for a redacted pre-certificate is exactly
> the
> same as the recourse for an un-redacted pre-certificate: approach the CA,
> within the
> terms of its Relying Party Agreement, CP, and/or CPS and state a claim
> that a
> certificate has been issued in error and it encroaches on the rights and
> property of
> the complainant. The only action that can be taken by the issuer is to
> revoke

If whether browsers can consume certificate status information in a timely
manner is out of the scope of this RFC, I would think that whether
"approach the CA" is sufficient recourse for a misissued redacted
pre-certificate would also be out of scope for this RFC.

> redesign their DNS hierarchy to preserve privacy in an eTLD+2 policy world
> requires
> organizations.

Two inconsistencies here:

* "network renaming", massive or not, would only be required for
redesigning their DNS hierarchy for eTLD+2, and would not be required for
use of wildcards.

* If redaction is for your "largest customers", enterprises that large
should be far more likely to have the resources to rename their internal
network names.

-- Eric

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Matt Palmer <[email-masked]>
Date: Tue, 16 Aug 2016 09:25:28 +1000

> be moved to another RFC so that work can proceed.

Sounds an awful lot like you're volunteering to co-author a separate
redaction RFC.  <grin>

- Matt