Subject: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Mar 2016 03:10:14 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-redirection-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The basic idea of the uCDN sending everything to the dCDN so
that the dCDN can reply with all the details of a request
that'll work (i.e. the sc-* stuff) seems broken as it requires
that the uCDN expose all security and privacy sensitive data
to the dCDN in pretty much all cases. I fail to see why that
is an acceptable approach. Can you point me at where the WG
disucssed the issues with that approach and considered less
security/privacy unfriendly potential alternatives?  

Some examples:
- section 4.1 says "SHOULD convey as much information as
possible" that is surely wrong - there is no reason to
encourage sending cookies and other security/privacy sensitive
information and in fact sending such should be discouraged
(SHOULD NOT) or even, if possible, prohibited (MUST NOT).  
- The cs-(cookie) in 4.5.1 is one specific case of sending too
much.  
- 4.4.1 Resolver IP addr is liable to be that of an end user's
machine (if they operate a recursive). 

But the examples are just that, I'd like to DISCUSS the WG's
consideration of the overall design first before we dive into
those.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I support Alissa's discuss points.

- section 3: false-negative? don't you mean false-positive?
And in any case, those warnings are not false from the browser
perspective. I'd suggest s/false-negative//

- section 3: phrases like "trusted re-direction" are a bad
idea - you need to say who is trusting whom for what for this
to be meaningful and not misleading (people get misled by such
phrases all the time). I'd just delete the sentence or
s/trusted//

- 4.4.2: a JSON "string" is not the same as a DNS name is it?
What about i18n? (ULABEL or ALABEL?) what about odd characters
allowed in JSON but not in DNS names?  In general the fields
in this dictionary (and others) seem underspecified to me.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 24 Mar 2016 15:07:45 +0000

Hi Stephen,

> On 17 Mar 2016, at 10:10, Stephen Farrell <[email-masked]> wrote:

I haven’t searched the archives. I don’t recall lots of discussion around the design. The chairs may be able to shed more light.

My personal view is that there is a trade off between exposing potentially security or privacy sensitive data and the impact that might cause to e.g. efficiency or surrogate selection, user experience, etc.

The technology side of CDN interconnect does not operate in a vacuum there is also the business agreement/contractual side of such interconnects. Depending on your point of view and the specific deployment where the balance of trade-offs falls will be different and one may not be exposing anything one would not have exposed if only a single CDN was in use.

For example, if CDNI is used to interconnect two CDNs owned & operated by the same entity (e.g. a network operator using CDNI to interconnect CDNs from two different vendors) there is no additional privacy implications than if the same network operator used a single larger CDN. Or a dCDN may be refusing an IP address and if presented with a larger prefix may refuse to serve the whole prefix, leading to a poorer user experience because a different dCDN is used for the content delivery.

I do not feel qualified to decide where the line should be drawn. The document provides the technical mechanics to encapsulate existing DNS & HTTP requests and allow interconnected CDNs to perform exactly as they do today when they are operating independently. From my non-qualified point of view I do not believe CDNI makes privacy worse for users compared to the single CDN use case, but if it does, that discussion feels like it is much wider than this particular document.

See my response just now to Alissa.

> perspective. I'd suggest s/false-negative//

Good suggestion, I've removed false-negative and left it as just “trigger security warnings” from my working copy of -18. 

> phrases all the time). I'd just delete the sentence or

I’ve deleted the whole sentence from my working copy of -18

> in this dictionary (and others) seem underspecified to me.

I’m afraid I’m not an expert in JSON strings, unicode or i18n. I think what you’re getting at is that a JSON string can contain more characters than allowed by an ALABEL or a ULABEL and we should be more precise in constraining the allowed characters? And that you think there are other fields in the document that would also benefit from constraining the allowable set of characters. If that’s the case I’m happy to make the edits to improve the document but I will need some help on what the right terminology is and the right references for the allowable characters.

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 15:35:05 +0000

Hiya,

>> that the dCDN can reply with all the details of a request that'll
>> work (i.e. the sc-* stuff) seems broken as it requires that the
>> uCDN expose all security and privacy sensitive data to the dCDN in
>> pretty much all cases. I fail to see why that is an acceptable
>> approach. Can you point me at where the WG disucssed the issues
>> with that approach and considered less security/privacy unfriendly
>> potential alternatives?
>> 
>> Some examples: - section 4.1 says "SHOULD convey as much
>> information as possible" that is surely wrong - there is no reason
>> to encourage sending cookies and other security/privacy sensitive 
>> information and in fact sending such should be discouraged (SHOULD
>> NOT) or even, if possible, prohibited (MUST NOT). - The cs-(cookie)
>> in 4.5.1 is one specific case of sending too much. - 4.4.1 Resolver
>> IP addr is liable to be that of an end user's machine (if they
>> operate a recursive).
>> 
> I haven’t searched the archives. I don’t recall lots of discussion
> around the design. The chairs may be able to shed more light.
> 
> My personal view is that there is a trade off between exposing
> potentially security or privacy sensitive data and the impact that
> might cause to e.g. efficiency or surrogate selection, user
> experience, etc.
> 
> The technology side of CDN interconnect does not operate in a vacuum
> there is also the business agreement/contractual side of such
> interconnects. Depending on your point of view and the specific
> deployment where the balance of trade-offs falls will be different
> and one may not be exposing anything one would not have exposed if
> only a single CDN was in use.
> 
> For example, if CDNI is used to interconnect two CDNs owned &
> operated by the same entity (e.g. a network operator using CDNI to
> interconnect CDNs from two different vendors) there is no additional
> privacy implications than if the same network operator used a single
> larger CDN. Or a dCDN may be refusing an IP address and if presented
> with a larger prefix may refuse to serve the whole prefix, leading to
> a poorer user experience because a different dCDN is used for the
> content delivery.
> 
> I do not feel qualified to decide where the line should be drawn.

Frankly I'm not convinced by the argument above. The draft IMO now
very clearly draws the line way way over on the commercial side, and
without seeming to consider the privacy issues much or at all. The
draft says that one SHOULD send as much as possible.

I think if we base our discussion on the text we should be able to
make better progress. Can we agree that as-is, the draft is very much
aiming to meet the commercial requirements and is not taking account
or privacy requirements?

S.

> The
> document provides the technical mechanics to encapsulate existing DNS
> & HTTP requests and allow interconnected CDNs to perform exactly as
> they do today when they are operating independently. From my
> non-qualified point of view I do not believe CDNI makes privacy worse
> for users compared to the single CDN use case, but if it does, that
> discussion feels like it is much wider than this particular
> document.
> 
>> - section 3: false-negative? don't you mean false-positive? And in
>> any case, those warnings are not false from the browser 
> Good suggestion, I've removed false-negative and left it as just
> “trigger security warnings” from my working copy of -18.
> 
>> 
>> - section 3: phrases like "trusted re-direction" are a bad idea -
>> you need to say who is trusting whom for what for this to be
>> meaningful and not misleading (people get misled by such phrases
>> all the time). I'd just delete the sentence or s/trusted//
> 
>> - 4.4.2: a JSON "string" is not the same as a DNS name is it? What
>> about i18n? (ULABEL or ALABEL?) what about odd characters allowed
>> in JSON but not in DNS names?  In general the fields in this
>> dictionary (and others) seem underspecified to me.
> 
> I’m afraid I’m not an expert in JSON strings, unicode or i18n. I
> think what you’re getting at is that a JSON string can contain more
> characters than allowed by an ALABEL or a ULABEL and we should be
> more precise in constraining the allowed characters? And that you
> think there are other fields in the document that would also benefit
> from constraining the allowable set of characters. If that’s the case
> I’m happy to make the edits to improve the document but I will need
> some help on what the right terminology is and the right references
> for the allowable characters.
> 
> Ben
>

---

From: "Niven - Jenkins, Ben (Nokia - GB)" <[email-masked]>
Date: Thu, 24 Mar 2016 15:51:29 +0000

Hi Stephen,

> On 24 Mar 2016, at 15:49, EXT Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Yes I think we can agree that. Ben

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Mar 2016 17:36:22 +0100

On 24/03/16 15:51, Niven - Jenkins, Ben (Nokia - GB) wrote:
>> Can we agree that as-is, the draft is very much

Great. Then I'd suggest that the best next step may be to try get
a bunch of folks to chat in B-A about how to take privacy into
account and hopefully that'll also turn out to be a fine way to
resolve the discuss. (Or if not in B-A then a subsequent concall
maybe.)

I'll certainly try to be there for that, but I expect it may be
possible to make good progress so long as you have someone there
who knows/cares a bit about privacy.

It may also be worth pointing out here that, just as with the
cdni-logging draft, my goal here is not to try to force the CDNs
using this to be privacy friendly, since that's impossible and
(en)forcing such things against the will of an operator isn't
the IETF's responsibility. Even if we defined the protocol to
try do that, there'd be loads of ways to work around it and
companies trying to "monetize" my mouse-clicks would just do
that without asking anyone anyway. We do however need to define
a protocol that allows a willing CDN to be privacy friendly and
achieve interop for the function conerned. So that last is my goal
for this discussion.

I assume the authors, WG chairs, document shepherd or responsible
AD can take the lead in finding a time/place/set of folks to chat.

Cheers,
S.

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 28 Mar 2016 15:51:09 +0000

Hi Stephen,

  (as co-chair/shepherd) I agree we can probably make the text more privacy 
friendly.  Unfortunately, neither Ben nor I will be in BA, though Francois and 
Ray will be, if we can get a f2f talk/call setup.  In the case of logging, it 
was very helpful having you recommend folks with better security/privacy 
experience with whom we could discuss the issues.  Is there someone you could 
suggest for the redirection privacy discussion?

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, March 27, 2016 12:36 PM
> To: Niven - Jenkins, Ben (Nokia - GB)
> Cc: Ben Niven-Jenkins; [email-masked]; draft-ietf-cdni-
> [email-masked]; The IESG; [email-masked]
> Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-
> redirection-17: (with DISCUSS and COMMENT)
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Mar 2016 17:01:04 +0100

> suggest for the redirection privacy discussion?

Not sure tbh. It mightn't be a good plan to go back to the
same folks again, but I might ask 'em in B-A if they'd like
to help some more. OTOH, I'd also hope that the WG would be
better able to figure this out, having seen the kinds of
changes that helped with cdni-logging. I'd also hope that
folks involved in the WG could make the effort to reach out
to colleagues of their own that are familiar with privacy.
(It's not like this is the first time that a document from
the CDNI WG has had privacy issues;-)

S.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 Mar 2016 17:27:46 +0100

Stephen, Kevin,

> On 28 Mar 2016, at 17:01, Stephen Farrell <[email-masked]> wrote:
>> Ray will be, if we can get a f2f talk/call setup.

I’ll be in Singapore the week of IETF so it may be a little difficult to schedule something that week, but lets see. The week afterwards I have pretty good availability for a call.

>>  In the case of logging, it 
> changes that helped with cdni-logging.

I wasn’t involved in the cdni-logging draft, however I’m sure those that were will contribute their experience & suggestions.

I have a slight worry that we’ll end up playing a bit of a guessing game and coming up with changes, to be told “not good enough, try again”. Lets have the call/conversation you suggest and hopefully we can come up with some changes that are good enough that they only need a bit of tweaking, if anything.
 
> I'd also hope that

Which could be an indication that the necessary expertise does not exist in the WG.

Thinking out loud, as the IETF/IESG is showing/expecting a higher degree of privacy awareness than in the past, I wonder if having a set of known “privacy doctors” might be an idea to get this sort of review earlier in the document cycle?

Ben