--On July 21, 2014 16:16:07 -0600 Peter Saint-Andre <[email protected]> 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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
