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

From: Daryl Malas <[email-masked]>
Date: Tue, 3 Feb 2015 18:14:29 +0000

I concur.

‹Daryl

On 2/3/15, 7:22 AM, "Francois Le Faucheur (flefauch)" <[email-masked]>
wrote:

>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
>> 
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: John Mattsson <[email-masked]>
Date: Mon, 16 Feb 2015 10:10:22 +0000

Hi,

>       * the various CDNI interfaces ought to include consistent text for TLS, unless there is a specific reason to do otherwise

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

- This is not enough to make sure that the implementation is secure. At a bare minimum the list should be enhanced with:

* The general TLS usage guidance in [TLSBCP<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#ref-TLSBCP>] SHOULD be followed

The cipher suite is only one part and there is still many ways to end up with something insecure.

- As TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 requires TLS 1.2, the text "TLS MUST be implemented”, could as well be changed to “TLS 1.2 MUST be implemented”. And as TLS 1.2 MUST be implemented there is no reason to use TLS 1.0 or 1.1. The list could therefore say.

* TLS 1.2 MUST be implemented

* Implementations that use TLS, MUST use TLS 1.2 or higher.

- As this is a new standard/deployment, it can be even stricter than the TLSBCP (which takes legacy implementations into account). The HTTP/2 specification (draft-ietf-httpbis-http2-17), Section 9.2, is a good example of how a TLS profile for a new deployment can be designed, It could maybe be used for guidance, alternatively referred to as the TLS profile also for CDNI.

Cheers,

John

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
Senior Researcher, Security

Ericsson AB
Ericsson Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com/>