Subject: [CDNi] Use of TLS in CDNI

From: Rob Murray <[email-masked]>
Date: Fri, 15 Jan 2016 22:04:17 +0000

Hi all,

Several comments came out of the secdir and IESG reviews of the CI/T draft regarding the "Security Considerations" text. We've used similar text in the Logging, Redirection and Metadata drafts. I've collected the comments together below.

The particularly-contentious paragraph in CI/T is:

   In an environment where any such protection is required, mutually
   authenticated encrypted transport MUST be used to ensure
   confidentiality of the CI/T information.  To that end, TLS MUST be
   used by CI/T, including authentication of the remote end.

Looks like I picked an older version of the text than Logging / Redirection / Metadata, or messed it up somehow. Those drafts expand a little on auth of the remote end, for example, Logging:

   In an environment where any such protection is required, mutually
   authenticated encrypted transport MUST be used to ensure
   confidentiality of the logging information.  To that end, TLS MUST be
   used (including authentication of the remote end) by the server-side
   and the client-side of the CDNI Logging feed, as well as the server-
   side and the client-side of the CDNI Logging File pull mechanism.

But the problem is with "In an environment where any such protection is required, [...]".

We need to be more clear about when TLS is needed - perhaps by making it a SHOULD and listing exceptions as Alissa suggests, or just saying MUST use TLS.

As far as I can remember, we thought we'd have the option of not using TLS for cases where the Internet's not being used for these interfaces (for example, when there's a private network / VPN).

In all of these drafts we say the interface MUST support TLS (and we don't say it MUST support plain-text).

The overhead of actually using TLS, particularly connection setup overhead, probably isn't a big concern as the connections are all likely to be persistent(?). So, for the best chance of interworking, and to keep things simple, I think my preference is to remove the ambiguity by just saying MUST use TLS.

Any thoughts?

Many thanks,
Rob.

----

Vincent Roca <[email-masked]> (secdir review)

>>
>>There are several topics I’d like to discuss:
>>1- Concerning the use of TLS to carry CI/T traffic, I see it is mandatory
>>to implement, but still optional to use (1st sentence of Section 8.1). Is
>>it still reasonable in current Internet? At a minimum I would expect a
>>« MUST support » / « SHOULD use ».
>Section 8.1 goes on to say ...
>   [ ... description of benefits of HTTPS ... ]
>   In an environment where any such protection is required, mutually
>   authenticated encrypted transport MUST be used to ensure
>   confidentiality of the CI/T information. To that end, TLS MUST be
>   used by CI/T, including authentication of the remote end.
>... the Internet is clearly an environment where such protection is
>required, and it'll often be used for these interfaces - we could state
>that explicitly, would that address the concern?
>But, CI/T could also be deployed to run over a VPN or private network
>between two interconnected CDNs, in such an environment HTTPS transport
>would not have the same benefits.

Yes, that’s my point. Say explicitly that Internet is an example of environment where
such a protection is mandatory.

----

Ben Campbell <[email-masked]>

- 8.1,  4th paragraph from the end:
The language here is ambiguous about whether the use of TLS is _always_
required, or just when "such protection is required." From context, I
assume the latter to be the case. But "To that end..." can be interpreted
to mean "In that case, one MUST do X", or to mean "In order to make that
possible when needed, one MUST _always_ do X"

I propose the following:
OLD:
   In an environment where any such protection is required, mutually
   authenticated encrypted transport MUST be used to ensure
   confidentiality of the CI/T information.  To that end, TLS MUST be
   used by CI/T, including authentication of the remote end.
NEW:
   In an environment where any such protection is required, mutually
   authenticated and encrypted TLS MUST be used to ensure
   confidentiality of the CI/T information. 
END.

[and...]

For the record, my proposed text assumed the intent was for a 
conditional "MUST use TLS". If the answer turned out to be "always 
MUST", I would certainly not object.

----

Alissa Cooper <[email-masked]>

I had the same confusion as Ben and the secdir reviewer concerning
whether TLS is always required to use or not. If there are cases in which
TLS is not mandatory to use, then I think this should be phrased as a
SHOULD with the exceptions clearly enumerated. For example, it's not
clear to me whether the only exception is environments where equivalent
protections are afforded by a different protocol, or if just being within
a single administrative domain is considered protection enough (not sure
I agree with the latter).

----

Kathleen Moriarty <[email-masked]>

I'm a no objection, but do want to see why TLS is not a MUST. I've
responded to Ben's discuss that proposes language to make it clear
whether or not TLS is a MUST. Right now, I think it is just a MUST when
certain conditions are met - the need for the security properties called
out in 8.1 and commercial privacy considerations in 8.3.

[and, in reply to Ben Campbell's DISCUSS]

I'm interested to see the response on this discuss.  From reading the
Security Considerations, I thought that TLS would be required for the
commercial confidentiality concerns cited in 8.3 and to provide the
security properties cited in 8.1.

I agree with Ben that the language goes back and forth a bit as to
whether or not it is required (I'd prefer to see it required.
However, there is enough language to suggest that it is just required
when specific conditions are met.  If there is a good argument to keep
it as-is, Ben's suggested language helps clear up any confusion, but
I'd like to make sure that there is a good reason to not have this be
a MUST use TLS.

I'm going to just tack this onto Ben's discuss as I should be on
maternity leave soon and don't want to hold up the draft while I am
out if this isn't resolved quickly.

----

Stephen Farrell <[email-masked]>

- I agree with the discuss points about use of TLS.

- I think it'd be better if you clarified that by
"mutually authenticated" you mean TLS client auth and
TLS server auth and not e.g. HTTP BASIC plus TLS server
auth.

----

---

From: Kevin Ma J <[email-masked]>
Date: Fri, 15 Jan 2016 22:14:07 +0000

Hi Rob,

  Metadata uses slightly different text which lists exceptions:

    In an environment where any such protection is required, TLS MUST be
    used (including authentication of the remote end) by the server-side
    (uCDN) and the client-side (dCDN) of the CDNI metadata interface
    unless alternate methods are used for ensuring the confidentiality of
    the information in the CDNI metadata interface requests and responses
    (such as setting up an IPsec tunnel between the two CDNs or using a
    physically secured internal network between two CDNs that are owned
    by the same corporate entity).

  I'm not necessarily advocating this over a MUST, but just putting it out there.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Rob Murray
> Sent: Friday, January 15, 2016 5:04 PM
> To: [email-masked]
> Subject: [CDNi] Use of TLS in CDNI
> 
> Hi all,
> 
> Several comments came out of the secdir and IESG reviews of the CI/T draft
> regarding the "Security Considerations" text. We've used similar text in
> the Logging, Redirection and Metadata drafts. I've collected the comments
> together below.
> 
> Looks like I picked an older version of the text than Logging /
> Redirection / Metadata, or messed it up somehow. Those drafts expand a
> little on auth of the remote end, for example, Logging:
> 
> We need to be more clear about when TLS is needed - perhaps by making it a
> SHOULD and listing exceptions as Alissa suggests, or just saying MUST use
> TLS.
> 
> As far as I can remember, we thought we'd have the option of not using TLS
> for cases where the Internet's not being used for these interfaces (for
> example, when there's a private network / VPN).
> 
> The overhead of actually using TLS, particularly connection setup
> overhead, probably isn't a big concern as the connections are all likely
> to be persistent(?). So, for the best chance of interworking, and to keep
> things simple, I think my preference is to remove the ambiguity by just
> saying MUST use TLS.
> 
> Any thoughts?
> 
> Many thanks,
> Rob.
> 
> ----
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 18 Jan 2016 09:12:58 +0000

Rob and folks,

We have been going through a similar lengthy discussion in the context of cdni-logging. Some arguing passionately that it ought to be a “MUST", some arguing passionately that it ought to be a “SHOULD” and some arguing passionately that it ought to be a “MUST be used when protection is required”.

The final conclusion was for a “MUST be used when such protection is required”. So my personal preference would be to stick to the same approach, and add the clarifications requested by the ADs i.e. :
	* add text about when such protection is not be required. The text from cdni-metadata quoted below by Kevin seems fine to me.
	* clarify that by "mutually authenticated" we mean TLS client auth and TLS server auth and not e.g. HTTP BASIC plus TLS server auth. The text in recent versions of cdni-logging quoted by Rob below seems fine to me.
	* possibly a few other word adjustments as suggested by ADs

Cheers

Francois

> On 15 Jan 2016, at 23:14, Ma Kevin <[email-masked]> wrote:
> 
> Hi Rob,
>