Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00

From: Eran Messeri <[email-masked]>
Date: Wed, 16 Nov 2016 11:17:04 +0900

Ryan Hurst and Clint Wilson had a discussion on name redaction use-cases
(following the trans WG meeting).
AIUI Clint intends to post a summary of that discussion to the list.

On Fri, Oct 28, 2016 at 10:49 PM, Tarah Wheeler <[email-masked]>
wrote:

> I've had one or two :) I'll look forward to your thoughts on them. I'll
> have some work for you all to look at soon.
>
> Tarah Wheeler
> Principal Security Advocate
> Senior Director of Engineering, Website Security
> Symantec
> [email-masked]
>
>
> > On Oct 25, 2016, at 5:23 PM, Rob Stradling <[email-masked]>
> wrote:
> >
> >> On 23/09/16 20:04, Tarah Wheeler wrote:
> >> I will co-author the redaction RFC.
> >
> > Hi Tarah.  Have you had any further thoughts on this since the call for
> > adoption a month ago?
> >
> > After the discussion at the CABForum F2F last week, it seems that
> > redaction is going to be a hot topic in Seoul.  So I'm just wondering if
> > there are any updates worth doing to draft-strad-trans-redaction before
> > the draft cut-off date (Monday 31st Oct) that might facilitate the
> > discussions.
> >
> > --
> > Rob Stradling
> > Senior Research & Development Scientist
> > COMODO - Creating Trust Online
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Tarah Wheeler <[email-masked]>
Date: Thu, 17 Nov 2016 00:45:11 +0000

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-masked]<mailto:[email-masked]>

From: Eran Messeri <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 15, 2016 at 6:17 PM
To: Tarah Wheeler <[email-masked]<mailto:[email-masked]>>
Cc: Rob Stradling <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00

AIUI

---

From: Clint Wilson <[email-masked]>
Date: Fri, 18 Nov 2016 15:53:35 +0000

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-masked]>
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

From: Eran Messeri <[email-masked]>
Date: Tuesday, November 15, 2016 at 6:17 PM
To: Tarah Wheeler <[email-masked]>
Cc: Rob Stradling <[email-masked]>, "[email-masked]" <
[email-masked]>
Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00

AIUI

---

From: Tarah Wheeler <[email-masked]>
Date: Sat, 19 Nov 2016 06:39:30 +0000

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

From: Clint Wilson <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 18, 2016 at 7:53 AM
To: Tarah Wheeler <[email-masked]<mailto:[email-masked]>>, Eran Messeri <[email-masked]<mailto:[email-masked]>>
Cc: Rob Stradling <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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<http://secret.example.com>” would result in “{redacted}.example.com<http://example.com>” while “secret.example.co.uk<http://secret.example.co.uk>” would result in “{redacted}.example.co.uk<http://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-masked]<mailto:[email-masked]>> 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

AIUI
_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 19 Nov 2016 21:45:54 -0800

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-masked]> 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
> From: Clint Wilson <[email-masked]>
> To: Tarah Wheeler <[email-masked]>, Eran Messeri
> <[email-masked]>
>
> Cc: Rob Stradling <[email-masked]>, "[email-masked]"
> <[email-masked]>
> 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.
>
> 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!
>
>> 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
>> 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
>> Cc: Rob Stradling <[email-masked]>, "[email-masked]"
>> <[email-masked]>

---

From: Peter Bowen <[email-masked]>
Date: Sat, 19 Nov 2016 22:02:21 -0800

Tarah,

There have been multiple requests for use cases to be brought to the
group.  I have brought some use cases from a group discussion outside
the IETF and others have contributed well.  We also know that the IETF
has addressed DNS privacy in several WGs, including the DNSEXT WG,
which developed DNSSEC Hashed Authenticated Denial of Existence (aka
NSEC3), and the DPRIVE WG which published DNS Privacy Considerations
(RFC 7626).

What guidance are you hoping the WG will get by asking for
"corporate-neutral experts"?  How does that align with the rough
consensus model used in WGs?

Thanks,
Peter

---

From: Clint Wilson <[email-masked]>
Date: Sun, 20 Nov 2016 13:13:45 +0000

The more input we can get, the better, in my opinion. I'm personally not
sure how to effectively lobby for more expert opinion than has already been
shared here, but I'm supportive of the idea if you've got a plan to do so.

On Fri, Nov 18, 2016 at 11:39 PM Tarah Wheeler <[email-masked]>
wrote:

> To: Tarah Wheeler <[email-masked]>, Eran Messeri <
> [email-masked]>
>
> 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
> 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

---

From: Clint Wilson <[email-masked]>
Date: Sun, 20 Nov 2016 13:35:07 +0000

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-masked]> wrote:

> above
> result
> the
> redacted
> signal
> and
> that

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Nov 2016 15:31:53 +0000

> The more input we can get, the better, in my opinion.

Anybody can join the email list.  Anyone can have input forwarded, but without direct participation, their opinion is less valued.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Nov 2016 00:42:10 -0500 (EST)

On Sat, 19 Nov 2016, Tarah Wheeler wrote:

[ chair hat on ]

> 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?

There are no "insiders" or "outsiders" at IETF. Everyone is welcome to
join any Working Group or mailing list or any discussion or meeting the
IETF holds.

We strongly encourage everyone who is interested to participate.
Participation is done as individuals only. For more information,
please see:

https://www.ietf.org/tao.html

https://www.ietf.org/newcomers.html

Paul

---

From: Rob Stradling <[email-masked]>
Date: Mon, 21 Nov 2016 09:41:04 +0000

On 20/11/16 05:45, Ryan Sleevi wrote:
<snip>
> https://tools.ietf.org/html/draft-ietf-tls-https-00#section-3.1 ,

We've flip-flopped several times on this topic during the last several 
years' worth of discussions on redaction.

See here, for example:
https://trac.ietf.org/trac/trans/ticket/17