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

From: Chris Newman <[email-masked]>
Date: Thu, 24 Jul 2014 09:13:50 -0400

--On July 21, 2014 16:16:07 -0600 Peter Saint-Andre <[email-masked]> wrote:
> Hi Chris, thanks for the proposed text. That's always appreciated.
> 
> On 7/21/14, 6:46 PM, Chris Newman wrote:
>> 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.
> 
> That seems accurate.
> 
>> Because several independent implementations had the same problem, use of
>> 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.

Fair enough, let's drop that sentence from the strawman text for this document.

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

What CVE-2011-0411 demonstrated is there's a class of implementation security
bugs that are possible with STARTTLS and do not occur with implicit TLS. Of
course those bugs should already have been fixed (and when we revise
specifications including STARTTLS we should mention the buffer-clearing
requirement in the updates). But even if we don't say so in any IETF
specifications, future new designs show avoid unnecessary opportunities for
implementation security bugs. That's simply good engineering. This is not to
say STARTTLS is fundamentally wrong-minded, or that we should try to deprecate
it in protocols that already use it or have a good reason to use it. The
underlying goal is more use of TLS and simpler use of secure TLS. To me, that
goal trumps many other considerations.

>> This attack is a key factor in changing the bias of the application area with
>> respect to use of STARTTLS
> 
> Is that "bias" captured in a document that has the consensus of the
> application area?

Not yet. But there is relevance to UTA because it impacts how we deal with
email protocols in particular. We've never documented or standardized imaps or
pop3s ports, they just got registered by a quirk of history. We've had STARTTLS
documented since RFC 2595 (June 1999). That document explicitly discourages use
of imaps and pop3s (and I believe all of the reasons for doing so were correct
except one of them). However, when we go out and measure what's deployed, there
are many sites that only offer imaps/pop3s and not STARTTLS+imap/POP and no
sites that offer STARTTLS without also offering imaps/pop3s. Whether or not I
like the outcome, the industry prefers separate-port SSL/TLS and will deploy it
more widely than STARTTLS. So I was wrong to prefer STARTTLS in the past,
regardless of the validity of my reasons.

Even SMTP submission where port 465 was de-registered, the industry still makes
heavy use of that port for Submission+TLS, often instead of the documented
SMTP+STARTTLS mechanism.

> Furthermore, has the application area discovered how to
> weigh the no-STARTTLS bias against the port-conservation bias captured in RFC
> 6335?

Registering a TLS-only port for a new protocol is sensible. What the
port-conservation bias means is that registering a non-TLS port for a new
protocol needs to be justified.

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

I don't agree the topic is out of scope for UTA WG, but I agree it needs more
discussion and don't care where that discussion happens.

		- Chris

---

From: John Mattsson <[email-masked]>
Date: Thu, 24 Jul 2014 17:25:21 +0000

I reviewed "draft-ietf-uta-tls-attacks-01” (I have not read the recent
review comments on the list). Some comments:

- General
The title is "Summarizing Current Attacks on TLS and DTLS" but there is no
section on
Attacks on DTLS. This needs to be fixed.

Either you make two separate sections or you need to describe which
attacks apply to
TLS vs DTLS. All of the attacks in Section 2 does not work on DTLS, e.g.
BEAST.

- Section 1
"generic and protocol-specific recommendation for the use of TLS and DTLS."
Shouldn't this be "recommendations"

- Section 2.1
This section is very HTTP focused. Is "SSL Stripping" really a good
general term for
"Various attacks attempt to remove the use of SSL/TLS altogether", and was
Moxie really
first with MITM attacks blocking access TLS forcing users to use plaintext?

- Section 2.4
"2^26 sessions or 13x2^30" -> "2^26 sessions or 2^33.7"

"As a result, RC4 can no longer be seen as providing a sufficient level of
security for TLS sessions."
Should there be recommendations in this document?

- Section 2.5
"cookies" -> "HTTP cookies"

I would recommend to write "TLS level" instead of "protocol-level" and
"protocol level"

Delete ", as recommended below."

- Section 2.6
"is only mitigated by TLS 1.1.” -> "was not mitigated before TLS 1.1” or
something similar.

- Section 2.7 
I think you should write out "MITM" -> "Man-in-the-Middle"

Cheers,

John

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 27 Jul 2014 10:44:02 +0300

Hi John,

Thanks for your review. Please see responses inline.

> TLS vs DTLS. All of the attacks in Section 2 does not work on DTLS, e.g.

Personally, I don't have the precise information on which attacks do and 
which do not apply to DTLS. Also, I think the WG interest in DTLS is 
very low. So unless we hear strong objections, I suggest to remove DTLS 
from the draft.

> first with MITM attacks blocking access TLS forcing users to use plaintext?

I personally like the name, it is short and to the point. I suppose the 
term (rather than the general idea) was coined by Moxie, and I would 
gladly replace it by an earlier reference if you can suggest one.

> Should there be recommendations in this document?

This is not a recommendation, it is an opinion (which I don't think you 
have a problem with).

> Delete ", as recommended below."

Yes.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 29 Jul 2014 08:37:05 -0700

Hi John,

On 07/24/2014 08:25 PM, John Mattsson wrote:
> I reviewed "draft-ietf-uta-tls-attacks-01■ (I have not read the recent

> "is only mitigated by TLS 1.1.■ -> "was not mitigated before TLS 1.1■ or
> something similar.
>
>
> - Section 2.7