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
- [TLS] Second Last Call: draft-ietf-tls-rfc4366-bi… The IESG
- Re: [TLS] Second Last Call: draft-ietf-tls-rfc436… Paul Hoffman
- [TLS] New cached-info draft 09 posted Stefan Santesson
- Re: [TLS] New cached-info draft 09 posted Michael D'Errico
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Michael D'Errico
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Michael D'Errico
- Re: [TLS] New cached-info draft 09 posted Brian Smith
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Stefan Santesson
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Stefan Santesson
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Martin Rex
- Re: [TLS] New cached-info draft 09 posted Stefan Santesson
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Stefan Santesson
- Re: [TLS] New cached-info draft 09 posted Simon Josefsson
- Re: [TLS] New cached-info draft 09 posted Marsh Ray
- Re: [TLS] New cached-info draft 09 posted Michael D'Errico
- Re: [TLS] New cached-info draft 09 posted Simon Josefsson
- Re: [TLS] New cached-info draft 09 posted Stefan Santesson