Subject: [CDNi] TLS usage recommendations in CDNI Logging a well as other interfaces

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Mar 2015 13:43:39 +0000

Folks,

Consistently with John’s comment below, we received similar comments as part of the IESG review of cdni-logging that we should refer to the TLS BCP being finalised by the UTA Working Group, instead of making up our own recommendations. This makes tons of sense of course, as we were only making our own recommendations because we were not aware of this BCP.

So, for cdni-logging, I’ve proposed to the IESG that we make the following specific edits:

OLD:
“
   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.
"
NEW:
"
 The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
   followed.
“

Let us know if you have any comment or concern with that, so we can make a generic decision that would apply (by default) to all CDNI interfaces.

Cheers

Francois

On 16 Feb 2015, at 11:10, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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

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

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

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 5 Mar 2015 14:55:21 +0000

This sounds very reasonable to me.

-          Jan

From: CDNi [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Donnerstag, 5. März 2015 14:44
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; John Mattsson
Subject: [CDNi] TLS usage recommendations in CDNI Logging a well as other interfaces

Folks,

OLD:
“

Cheers

Francois

Hi,

Cheers,

John

JOHN MATTSSON

Ericsson AB
Ericsson Research
Färögatan 6

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Mar 2015 19:21:03 +0000

Actually, In several aspects the new text is actually weaker:

- The old text said “MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256” while the new does not mandate support of any cipher suites without known weaknesses.

- “MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256” implied “MUST support TLS 1.2” while the new text only implies “SHOULD support TLS 1.2”.

I think supporting TLS 1.2 and a cipher suite without weaknesses should be mandated.

And while the TLS BCP is great for general guidance, it is alone not a good profile for a new standard. It heavily takes interop with legacy endpoints into account and does e.g. not forbid weak TLS sessions like: TLS 1.0 with 3DES_CBC, TLS compression, RSA-768 keys, and 768-bit Diffie-Hellman groups.

As CDNi is a new standard is there a reason to not be stricter? I would suggest:

“The general TLS usage guidance in [I-D.draft-ietf-httpbis-http2, Section 9.2] MUST be followed.”

Cheers,
John

On 05 Mar 2015, at 14:43, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

OLD:
“

Cheers

Francois

Hi,

Cheers,

John

JOHN MATTSSON

Ericsson AB
Ericsson Research
Färögatan 6

---

From: Michael Hallgren <[email-masked]>
Date: Thu, 05 Mar 2015 20:25:25 +0100

Hi, 

What you propose appears as my natural choice, so count my voice in support. 

Cheers, 

mh 

Le 5 mars 2015 20:21:03 CET, John Mattsson <[email-masked]> a écrit :
>- The old text said “MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256”
>while the new does not mandate support of any cipher suites without
>known weaknesses.
>
>- “MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256” implied “MUST
>support TLS 1.2” while the new text only implies “SHOULD support TLS
>1.2”.
>
>And while the TLS BCP is great for general guidance, it is alone not a
>good profile for a new standard. It heavily takes interop with legacy
>endpoints into account and does e.g. not forbid weak TLS sessions like:
>TLS 1.0 with 3DES_CBC, TLS compression, RSA-768 keys, and 768-bit
>Diffie-Hellman groups.
>
>
>On 05 Mar 2015, at 14:43, Francois Le Faucheur (flefauch)
><[email-masked]<mailto:[email-masked]>> wrote:
>
>Folks,
>
>Consistently with John’s comment below, we received similar comments as
>part of the IESG review of cdni-logging that we should refer to the TLS
>BCP being finalised by the UTA Working Group, instead of making up our
>own recommendations. This makes tons of sense of course, as we were
>only making our own recommendations because we were not aware of this
>BCP.
>
>Let us know if you have any comment or concern with that, so we can
>make a generic decision that would apply (by default) to all CDNI
>interfaces.
>
>
>Cheers
>
>Francois
>
>
>On 16 Feb 2015, at 11:10, John Mattsson
><[email-masked]<mailto:[email-masked]>> wrote:
>
>
>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
>
>- 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.
>
>- 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
>------------------------------------------------------------------------
>
>[email-masked]

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 6 Mar 2015 00:19:40 +0000

Francois, WG,

I would much rather reference an existing BCP/document than have each specification define a profile for itself or repeat the same text.

I don't care whether it is SHOULD or MUST. I believe folks will implement/deploy whatever makes sense to them regardless of what we say.

Ben
 
> On 5 Mar 2015, at 19:21, John Mattsson <[email-masked]> wrote:
> 
>> On 05 Mar 2015, at 14:43, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
>> 
>> Folks,
>> 
>>> On 16 Feb 2015, at 11:10, John Mattsson <[email-masked]> wrote:
>>> 
>>> Hi,
>>> * The general TLS usage guidance in [TLSBCP] SHOULD be followed
>>> [email-masked]
>>> www.ericsson.com
>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Mar 2015 20:17:02 -0500

Hi,

Sent from my iPhone

> On Mar 5, 2015, at 2:21 PM, John Mattsson <[email-masked]> wrote:
> 
Agreed.  My comment was that a reference to the BCP is in line with your recommendations as the cipher suite selected is in the BCP as one if the recommended, so there was no conflict in also adding a reference to get the benefit of the other configuration recommendations.  Thanks for making that easy with a good cipher as required.

> And while the TLS BCP is great for general guidance, it is alone not a good profile for a new standard. It heavily takes interop with legacy endpoints into account and does e.g. not forbid weak TLS…
Right, it just backs up your choices and may be helpful for other configuration details.

Did my review get to the list or is it in a mail queue waiting to be approved?  In any case, you can look at the IESG comments to see where we all had questions.  I offered some text as a suggestion to help and had written my review before a response was sent to to SecDir review.  Thanks so much for addressing Klaas' concerns.

Best regards,
Kathleen

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 6 Mar 2015 14:19:51 +0000

All, 

(as a CDNI WG Chair)

I would agree with Ben.

Given the "Using TLS in Applications (uta)” Working Group charter specifically includes:
“
- Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement.
...
- Create a document that helps application protocol developers use TLS in future application definitions.
“
I feel that our Working Group should ideally simply defer to UTA for these recommendations.
If additional recommendations are needed, it seems that those would be best discussed under the uta WG auspices rather than within a given application WG (that does not have any unique security/TLS requirements) and does not have the necessary expertise.

So, my proposal would be that we stick with the proposed reference to the uta TLS BCP:
NEW:
"
The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be followed. 
"
(I am also OK replacing the SHOULD by a MUST in the sentence above if some folks feel strongly about that)

Francois

> On 6 Mar 2015, at 01:19, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Francois, WG,
>

---

From: John Mattsson <[email-masked]>
Date: Fri, 6 Mar 2015 19:30:36 +0000

Francois, WG,

I think this is an important problem, and one that many other groups will have in the future: “How to define a TLS profile for a new standard?”

Looking at the TLS BCP instead of the UTA charter, it says: “This document provides recommendations for improving the security of deployed services”. I don’t think a new standard such as CDNi can be considered “deployed”. 

I completely agree with you Francois in that the best option is to defer to UTA. I don’t agree with your conclusion, instead of trying to figure out what UTA would want, I think the obvious answer is the ask them. 

Cheers,
John

> On 06 Mar 2015, at 15:19, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
> 
> All, 
> 
> (as a CDNI WG Chair)
> 
> I would agree with Ben.
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 9 Mar 2015 12:51:12 +0000

Hello John,

> On 6 Mar 2015, at 20:30, John Mattsson <[email-masked]> wrote:
> 
> Francois, WG,
> 

I completely agree. 

> I completely agree with you Francois in that the best option is to defer to UTA.

Perfect.

> I don’t agree with your conclusion, instead of trying to figure out what UTA would want, I think the obvious answer is the ask them. 

Just to be clear, I was not trying to second guess what UTA would want. I was only proposing to refer to the current deliverables available from UTA. Since their charter is already asking UTA for recommendations on what a new standard should do, and they do not have a specification for this yet (AFAICT), I was (perhaps hastily) second-guessing that they may not have the answer fully cooked yet. But I agree the best is to ask them. And I thank you for having done that already.

Francois