Re: [TLS] New cached-info draft 09 posted

Marsh Ray <marsh@extendedsubset.com> Mon, 12 July 2010 20:34 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E333A6C77 for <tls@core3.amsl.com>; Mon, 12 Jul 2010 13:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.868
X-Spam-Level:
X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WwKUmbCabdO for <tls@core3.amsl.com>; Mon, 12 Jul 2010 13:34:02 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 930613A6BF3 for <tls@ietf.org>; Mon, 12 Jul 2010 13:33:59 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OYPhX-000MrX-Ik; Mon, 12 Jul 2010 20:34:07 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0F2526346; Mon, 12 Jul 2010 20:34:05 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+ZAnM8YwTxDPgrDtLnzJkqEMwOn6sQTsU=
Message-ID: <4C3B7C3F.3070609@extendedsubset.com>
Date: Mon, 12 Jul 2010 15:34:07 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
References: <C8601653.C649%stefan@aaa-sec.com> <4C3A6CE4.3030601@pobox.com> <4C3A6F2E.9090808@extendedsubset.com> <4C3A77AA.3040008@pobox.com> <4C3A8E19.9050001@extendedsubset.com> <4C3A9882.10907@pobox.com> <00b401cb2184$8afd3200$a0f79600$@briansmith.org>
In-Reply-To: <00b401cb2184$8afd3200$a0f79600$@briansmith.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] New cached-info draft 09 posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 20:34:10 -0000

On 07/12/2010 12:39 AM, Brian Smith wrote:
>
> There should be no problem with requiring TLS 1.2 as the minimum version for
> this extension, snap start, and false start. In fact, you could even require
> even a brand new TLS version for them at this point in time, and things
> would work out just fine.

Individually cached info, false start, and snap start seem like 
significant extensions. Since security is not generally composable, even 
if each extension is shown to be secure independently they should also 
be considered in combination. Perhaps it would be simpler 
administratively to bring them under a new TLS version number.

Taken together they seem to be a significant rework of the protocol, 
especially considering the changes to the Finished.verify_data message 
calculation. Snap start on its own is coming close to defining a new 
protocol that (for external reasons) happens to send a TLS-compatible 
Client Hello and runs on TCP port 443.

By loosening various constraints they give additional flexibility to an 
active attacker to modify the handshake, putting additional stress on 
the hash/MAC functions. It may be that verify_data needs lengthening, in 
which case a new protocol version number is probably indicated.

That said, they each have their independent merits and so it may not be 
fair to queue them all behind a new protocol version.

- Marsh