Subject: Re: [Uta] I-D Action: draft-ietf-uta-tls-attacks-01.txt

From: Chris Newman <[email-masked]>
Date: Mon, 21 Jul 2014 17:46:04 -0700

I've reviewed draft-ietf-uta-tls-attacks-01.txt and support its publication. I
believe the document would be improved by including CVE numbers for the
vulnerabilities in the document.

I had volunteered to write text describing the STARTTLS attack. Here's strawman
text:

---
2.9 STARTTLS Command Injection Attack (CVE-2011-0411)

A number of IETF application protocols have used an application-level command,
usually STARTTLS, to upgrade a clear-text connection to use TLS. Multiple
implementations of STARTTLS had a flaw where an application-layer input buffer
retained commands that were pipelined with the STARTTLS command, such that
commands received prior to TLS negotiation are executed after TLS negotiation.
This problem is resolved by requiring the application-level command input
buffer to be empty before negotiating TLS. Note that this flaw lives in the
application layer code and does not impact the TLS protocol directly.

Because several independent implementations had the same problem, use of
STARTTLS in new IETF protocols is discouraged.
---

This attack is a key factor in changing the bias of the application area with
respect to use of STARTTLS and is one of the motivations behind the "implicit
TLS" preference in

 http://tools.ietf.org/html/draft-newman-email-deep-01

		- Chris

---

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

Hi Chris, thanks for the proposed text. That's always appreciated.

> application layer code and does not impact the TLS protocol directly.

That seems accurate.

> STARTTLS in new IETF protocols is discouraged.

I don't think it's the role of draft-ietf-uta-tls-attacks (which, if 
approved, would be an Informational RFC) to discourage the use of 
STARTTLS in new IETF protocols.

(I also don't think that the presence of bugs in implementations 
necessitates the kind of changes you have recommended here - instead, 
those bugs need to be fixed.)

> respect to use of STARTTLS

Is that "bias" captured in a document that has the consensus of the 
application area? Furthermore, has the application area discovered how 
to weigh the no-STARTTLS bias against the port-conservation bias 
captured in RFC 6335?

IMHO this topic is probably out of scope for the UTA WG, and deserves to 
be openly aired in the application area so that consensus can be reached 
there. Until such a consensus is reached, I don't think we can make such 
a strong statement in any of the UTA documents.

Peter