Subject: [Uta] WGLC on draft-ietf-uta-tls-attacks-02

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Aug 2014 09:55:19 +0200

This starts a 2 week working group last call on
draft-ietf-uta-tls-attacks-02. Please send any final comments on the
list by 1/9.

	Leif & Orit

---

From: t.p. <[email-masked]>
Date: Mon, 18 Aug 2014 10:10:51 +0100

Is there an attack based on the TLS Heartbeat, and if so, should it be
included?

I see references on the TLS list that 'Heartbeat is dead' without any
further explanation, and I assume that that is because it enables an
attack.  At the same time, there are application protocols that lack a
heartbeat protocol and the TLS Heartbeat has been mooted as a solution,
so if it does enable an attack, then that is worth recording.

Tom Petch

----- Original Message -----
From: "Leif Johansson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 18, 2014 8:55 AM

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Aug 2014 13:03:37 +0300

> Is there an attack based on the TLS Heartbeat, and if so, should it be

I don't think so, unless the extension is badly misimplemented
("heartbleed" in OpenSSL). The extension itself has sufficient checks
(in fact, bit stricter than "common sense" ones, which would also have
been sufficient).

Now, the heartbeat extension might not be designed well, but that is
different issue.

-Ilari

---

From: Chris Newman <[email-masked]>
Date: Mon, 18 Aug 2014 11:01:02 -0700

> draft-ietf-uta-tls-attacks-02. Please send any final comments on the

I had previously spent the time to write suggested text for the draft (message
attached).

It seems that suggested text was ignored. I strongly object to advancing this
draft without having my suggested text considered.

If I see a statement along the lines "your suggested text was not included
because of X", and the WG has rough consensus on that statement, that's fine.

But ignoring suggested text is not fine.

		- Chris

Subject: Re: [Uta] I-D Action: draft-ietf-uta-tls-attacks-01.txt
From: Chris Newman <[email-masked]>
To: [email-masked]
Date: Mon, 21 Jul 2014 17:46:04 -0700
List-Id: UTA working group mailing list <uta.ietf.org>

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: Leif Johansson <[email-masked]>
Date: Mon, 18 Aug 2014 20:30:08 +0200

> But ignoring suggested text is not fine.

You got a response from stpeter
http://www.ietf.org/mail-archive/web/uta/current/msg00476.html in which
he pushed back on some of your text.

There was no further discussion on that thread so I don't think you got
ignored, rather you didn't respond to stpeter's response to you.
	
	Cheers Leif

---

From: Chris Newman <[email-masked]>
Date: Fri, 29 Aug 2014 13:47:23 -0700

--On August 18, 2014 20:30:08 +0200 Leif Johansson <[email-masked]> wrote:
>> I had previously spent the time to write suggested text for the draft
>> (message attached).
>> 

His comment on the first paragraph was "That seems accurate". He objected to
the last paragraph. I wrote a reply (attached) where I suggested dropping the
last paragraph as a compromise.

So absent other commentary, I believe the first paragraph should go in the
document:

===

===

This is an important motivation for design decisions in:
   http://tools.ietf.org/html/draft-newman-email-deep-02

> ignored, rather you didn't respond to stpeter's response to you.

I did respond to stpeter's message (response attached); I'm not sure why my
response is not in the archive.

		- Chris

Subject: Re: [Uta] I-D Action: draft-ietf-uta-tls-attacks-01.txt
From: Chris Newman <[email-masked]>
To: Peter Saint-Andre <[email-masked]>, [email-masked]
Date: Thu, 24 Jul 2014 09:13:50 -0400
List-Id: UTA working group mailing list <uta.ietf.org>

--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
>> I had volunteered to write text describing the STARTTLS attack. Here's
>> strawman text:
>> 
>> ---
>> 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.
> 
> 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.

>> 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: Leif Johansson <[email-masked]>
Date: Fri, 29 Aug 2014 22:55:49 +0200

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

Speaking as an individual that seems reasonable. Yaron? Others?

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 30 Aug 2014 09:39:17 +0300

I am fine with this text.

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Sat, 30 Aug 2014 10:48:28 +0200

> I am fine with this text.

OK then I think its fine for you to deal with this as any WGLC comment -
just include it in your final IETF-LC version.

>>> command,