Subject: Re: [CDNi] Mandating support for TLS in draft-ietf-cdni-redirection

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 3 Feb 2015 14:22:53 +0000

Ben and all,

(as a WG Chair)

We have discussed TLS support at length in the context of other interfaces (eg cdni-logging).

I believe the concensus that was reached was:
	* the various CDNI interfaces ought to include consistent text for TLS, unless there is a specific reason to do otherwise
	* TLS MUST be implemented
	* TLS SHOULD be used whenever protection is needed
	* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite MUST be implemented
	* cypher suites supporting perfect forward secrecy SHOULD be used

To Ben’s comments below, note that the approach above does not force the use of TLS or of a particular cypher suite. It only forces all implementations to have one security mechanisms in common (TLS) and one good-enough cypher suite in common, which guarantees interoperability in a secure mode.

At this stage I don’t see a clear argument for changing that approach.

Can we not also adopt this approach for cdni-redirection?

Cheers

Francois

PS: For memory, here is an excerpt from cdni-logging on teh same topic:

"
An implementation of the CDNI Logging interface MUST support TLS
   transport of the CDNI Logging feed (Section 4.1) and of the CDNI
   Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].

   The use of TLS for transport of the CDNI Logging feed and CDNI
   Logging File pull allows:

   o  the dCDN and uCDN to authenticate each other (to ensure they are
      transmitting/receiving CDNI Logging File from an authenticated
      CDN)

   o  the CDNI Logging information to be transmitted with
      confidentiality

   o  the integrity of the CDNI Logging information to be protected
      during the exchange

   In an environment where any such protection is required, TLS SHOULD
   be used (including authentication of the remote end) by the server-
   side and the client-side of the CDNI Logging feed and the CDNI
   Logging File pull mechanism unless alternate methods are used for
   ensuring the confidentiality of the information in the logging files
   (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).

   An implementation of the CDNI Logging interface MUST support the
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]).  An
   implementation of the CDNI Logging interface SHOULD prefer cipher
   suites which support perfect forward secrecy over cipher suites that
   don't.
“

> On 10 Dec 2014, at 12:25, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Francois, Kevin & Colleagues,
> 
> As part of reviewing draft-ietf-cdni-redirection it has been suggested to mandate the use of TLS and to mandate support for some cipher suite.
> 
> I am against such a change.
> 
> The RI interface document lays out in the security considerations section the threats and then recommends (SHOULD) secure and authenticated communication.
> 
> I have changed that to a MUST in the latest draft which now reads
>   In order to prevent passive interception of RI messages the RI
>   communications channel MUST be suitably secured (e.g. use of TLS).
> 
>   In order to reduce the risk of information leakage to unauthorized
>   parties, RI clients and servers MUST use suitable authentication
>   prior to trusting the contents of RI messages.
> 
> which I believe to be sufficient.
> 
> I am against mandating TLS as it is not the only mechanism available for securing the redirection interface, e.g. CDNs may use IPSec tunnels and run the RI over them. The document already suggests TLS by example and defines that the RI MUST run over a  suitably secured & authenticated channel.
> 
> Mandating TLS adds nothing extra to the specification except inflexibility for deployers.
> 
> Likewise recommending a particular cipher suite seems problematic as we are not security experts and the recommended suite may change over time forcing a need to update the RFC just to update the advice on cipher suites. Better to have the deployer follow the current best practice for the secure channel they choose to deploy over IMO.
> 
> If the consensus of the working group is that we should mandate a specific secure channel and/or a specific cipher suite, I'm OK to be declared in the rough and make the necessary editorial changes. But I do believe we're better off not going there and leaving it to deployers to decide what is most appropriate for their environment.
> 
> Ben
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 3 Feb 2015 14:45:39 +0000

Francois,

If that is the consensus of the WG I am OK with being called in the rough.

I'll push out a new revision of the redirection draft with the agreed text later today.

Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 3 Feb 2015 15:32:21 +0000

Sounds good.

The next version should then be ready for WGLC.

Francois

> On 3 Feb 2015, at 15:45, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Francois,
>