Subject: [Uta] Review of draft-ietf-uta-tls-bcp-01

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 18 Jul 2014 14:22:06 +0000

Hello,

I wanted to provide some thoughts and suggestions on draft-ietf-uta-tls-bcp-01. Especially I am focusing on recommendations on ciphersuites. Maybe focusing on specific ciphersuites is outside the scope of this work, so it might not fit in this doc. If so please let me know.

- Ephemeral vs Static DHE in TLS negotiation is not addressed in section 4.2. Static DH should be recommended to be avoided.
- _anon_ ciphersuites are not addressed. They should be avoided as well.
- MD5 is not addressed and not mentioned as avoided. Reference to RFC6151o culd be added here.
- In general, the draft's sections 3.4 and 3.5 make recommendations about good ciphersuites and security levels and ciphersuites that are "ok if there is no other options" like 1024 RSA, but it doesn't address which ciphersuites should be avoided, which are legacy to be used if no other options are available.

I believe the "secure ciphersuites" can be "algorithmized" with the use of a IANA table successfully to benefit the industry's implementers.

I am not sure if the scope of this document is to address it or maybe that should be a separate document and IANA table, but I wanted to bring it to the author's attention.

Regards,
Panos Kampanakis
Cisco Systems

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Jul 2014 20:56:31 +0300

Hi Panos,

We tried to focus on existing problematic uses, rather than including a 
long list of bad things that people MIGHT be doing, but mostly know 
better. This is why the most important negative recommendation is with 
regard to RC4, because it is heavily used in practice. If we are missing 
bad practices that are *widely used* today, please let us know.

I'm not sure I understand your last two paragraphs, but if I do: we do 
not provide an extensive list of "good" cipher suites, because we also 
care about interoperability. If we included a long list of cipher 
suites, different people would implement different subsets, and we would 
end up with negotiation failures.

Thanks,
	Yaron

On 07/18/2014 05:22 PM, Panos Kampanakis (pkampana) wrote:
> Hello,
>
> I wanted to provide some thoughts and suggestions on
> draft-ietf-uta-tls-bcp-01. Especially I am focusing on recommendations
> on ciphersuites. Maybe focusing on specific ciphersuites is outside the
> scope of this work, so it might not fit in this doc. If so please let me
> know.
>
> - Ephemeral vs Static DHE in TLS negotiation is not addressed in section
> 4.2. Static DH should be recommended to be avoided.
>
> - In general, the draft’s sections 3.4 and 3.5 make recommendations
> about good ciphersuites and security levels and ciphersuites that are
> “ok if there is no other options” like 1024 RSA, but it doesn’t address
> which ciphersuites should be avoided, which are legacy to be used if no
> other options are available.
>
> I believe the “secure ciphersuites” can be “algorithmized” with the use
> of a IANA table successfully to benefit the industry’s implementers.
>
> I am not sure if the scope of this document is to address it or maybe
> that should be a separate document and IANA table, but I wanted to bring
> it to the author’s attention.
>
> Regards,
>
> Panos Kampanakis
>
> Cisco Systems
>
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 21 Jul 2014 13:30:38 +0000

Thank you Yaron, while focusing on secure ciphersuites it slipped my mind that the bcp doc also keeps interoperability in consideration.
Panos

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Saturday, July 19, 2014 1:57 PM
To: Panos Kampanakis (pkampana); [email-masked]
Subject: Re: [Uta] Review of draft-ietf-uta-tls-bcp-01

Hi Panos,

We tried to focus on existing problematic uses, rather than including a long list of bad things that people MIGHT be doing, but mostly know better. This is why the most important negative recommendation is with regard to RC4, because it is heavily used in practice. If we are missing bad practices that are *widely used* today, please let us know.

I'm not sure I understand your last two paragraphs, but if I do: we do not provide an extensive list of "good" cipher suites, because we also care about interoperability. If we included a long list of cipher suites, different people would implement different subsets, and we would end up with negotiation failures.

Thanks,
	Yaron

On 07/18/2014 05:22 PM, Panos Kampanakis (pkampana) wrote:
> on ciphersuites. Maybe focusing on specific ciphersuites is outside 
> the scope of this work, so it might not fit in this doc. If so please 
> let me know.
>
> - Ephemeral vs Static DHE in TLS negotiation is not addressed in 
> section 4.2. Static DH should be recommended to be avoided.
>
> - In general, the draft's sections 3.4 and 3.5 make recommendations 
> "ok if there is no other options" like 1024 RSA, but it doesn't 
> address which ciphersuites should be avoided, which are legacy to be 
> used if no other options are available.
>
> I believe the "secure ciphersuites" can be "algorithmized" with the 
> use of a IANA table successfully to benefit the industry's implementers.
>
> that should be a separate document and IANA table, but I wanted to 
> bring it to the author's attention.
>
> Regards,
>
> Panos Kampanakis
>
> Cisco Systems
>
>
>

---

From: Chris Newman <[email-masked]>
Date: Mon, 21 Jul 2014 11:06:23 -0700

I've read this draft. Overall, I support publication of this draft or a revised
version as a BCP.

Minor issues (not issues I consider blocking):

* I'd like a single list/table of TLS extensions that implementers/operators
need to consider seriously included. It's fine if it just includes references
to the RFC (or section of this BCP) where the detailed rules live. This makes
it easier to navigate through the RFCs.

Section 3.4:
>    o  Implementations MUST NOT negotiate RC4 cipher suites

I'd prefer to have this statement added: "unless the only alternative would be
an unencrypted connection"

Nits to improve specification (not issues I consider blocking).

Section 1: Introduction

>   Transport Layer Security (TLS) and Datagram Transport Security Layer

This should include appropriate references

TLS  => RFC 5246 + RFC 5746
DTLS => RFC 6347

>   protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the	

These should include appropriate references where possible.

HTTP => RFC 7230
SMTP => RFC 3207
IMAP => RFC 3501
POP3 => RFC 2595
XMPP => RFC 6120

>   standardized and deployed in the field, should resolve the current
>   vulnerabilities while providing significantly better functionality,
>   and will very likely obsolete this document.

I suggest deleting the last clause. No need to predict the future. I am also
unsure if the TLS WG wants the responsibility of replacing all the material in
this draft when TLS 1.3 is published.

		- Chris

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Jul 2014 20:12:49 +0300

Hi Chris,

> an unencrypted connection"

I fully agree.

[...]

> this draft when TLS 1.3 is published.

Actually, IMHO this is exactly what the TLS WG needs to do... I see 
where you're coming from, but I still think TLS 1.3 "will likely 
obsolete this document" - so this is our warning to the reader.

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Mon, 21 Jul 2014 19:21:59 +0200

> obsolete this document" - so this is our warning to the reader.

Actually I'm not so sure. At least part of the document is arguably
deployment guidelines (for instance I don't think TLS 1.3 is going to
remove all non-cool cipher suites anytime soon).

In any case a BCP (if that is what we're doing) is a point-in-time
perspective.

It is very possible that TLS 1.3 will cause us to revisit this document
but I don't think it will be empty.

	Cheers Leif

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 21 Jul 2014 13:24:38 -0400

> remove all non-cool cipher suites anytime soon).

TLS 1.3 will (probably) remove all non-AEAD ciphersuites and a bunch of
other stuff, but of course earlier protocol versions will still remain in
use once TLS 1.3 has been finalized.

Bodo

---

From: Leif Johansson <[email-masked]>
Date: Mon, 21 Jul 2014 19:31:54 +0200

On 2014-07-21 19:24, Bodo Moeller wrote:
> other stuff, but of course earlier protocol versions will still remain
> in use once TLS 1.3 has been finalized.

My point is that as long as there are choices, sooner or later somebody
is going to update the BCP to reflect what the best choice is at that time.

	Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Jul 2014 20:55:37 +0100

I've read this draft and I support its publication as a BCP.

I have one minor issue:

In 3.3, first paragraph:

> Combining unprotected and TLS-protected communication opens the way
>     to SSL Stripping and similar attacks.  In cases where an application
>     protocol allows implementations or deployments a choice between
>     strict TLS configuration and dynamic upgrade from unencrypted to TLS-
>     protected traffic (such as STARTTLS), clients and servers SHOULD
>     prefer strict TLS configuration.

Is this text recommending use of TLS on a separate port (e.g. IMAPS), 
that STARTTLS should always be used (and remembered, in order to prevent 
downgrade attacks) or both? I would like this text to be clarified to be 
unambiguous.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jul 2014 15:47:41 -0600

> downgrade attacks) or both? I would like this text to be clarified to be

As I understand it, the text is recommending that implementations prefer 
the use of TLS on a separate port where available, and prefer not to use 
STARTTLS (or similar). Naturally this applies only to application 
protocols that support both TLS-on-a-separate-port and 
upgrade-from-unsecured-to-secured.

Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Jul 2014 23:06:58 +0100

On 21/07/2014 22:47, Peter Saint-Andre wrote:
> As I understand it, the text is recommending that implementations 
> prefer the use of TLS on a separate port where available, and prefer 
> not to use STARTTLS (or similar). Naturally this applies only to 
> application protocols that support both TLS-on-a-separate-port and 
Hi Peter,

In this case, may I suggest inserting after "strict TLS configuration" 
something like "(protocol over TLS on a separate port)"?

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jul 2014 16:17:33 -0600

> something like "(protocol over TLS on a separate port)"?

WFM.

Peter