Re: [TLS] One approach to rollback protection
Marsh Ray <marsh@extendedsubset.com> Tue, 27 September 2011 01:36 UTC
Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF521F8EB0 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.486
X-Spam-Level:
X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, MANGLED_SAVELE=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCmG4oo5SX7H for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:36:26 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22121F8EAE for <tls@ietf.org>; Mon, 26 Sep 2011 18:36:26 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1R8Mda-000HTd-5U; Tue, 27 Sep 2011 01:39:10 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1E2516067; Tue, 27 Sep 2011 01:39:07 +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: U2FsdGVkX18K+X2J4tc+4psa3ymC9rmrqBGMPvzFhnw=
Message-ID: <4E81293A.4000402@extendedsubset.com>
Date: Mon, 26 Sep 2011 20:39:06 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: mrex@sap.com
References: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp>
In-Reply-To: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] One approach to rollback protection
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 27 Sep 2011 01:36:27 -0000
I agree that the current semantics are starting to feel a bit silly. Support for TLS 1.2 also implies a willingness to speak SSLv3? Are we expecting to continue this forever? On 09/26/2011 07:21 PM, Martin Rex wrote: > > My personal favourite would be to use an OR'ed bitmask, and we could > either "waste" a whole 256 cipher suite codepoints (or be more conservative > and require the reserved bits below to be all ZERO--requiring > only 16 cipher suite code points starting at a block boundary). > > version_major = 0xYY (assigned/reserved by IANA as { 0xYY, * } ) > version_minor = a set of 8 bits indicating TLS version offered by client > > x80|x40|x20|x10|x08|x04|x02|x01 Value > 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 Bit Position > > | | | | | | | | > | | | | | | | | > | | | | | | | `- indicates SSLv3 support {0x03,0x00} > | | | | | | `----- indicates TLSv1.0 support {0x03,0x01} > | | | | | `--------- indicates TLSv1.1 support {0x03,0x02} > | | | | `------------- indicates TLSv1.2 support {0x03,0x03} > | | | `----------------- (reserved for TLSv1.3) > | | `--------------------- (reserved for TLSv1.4) > | `------------------------- (reserved for TLSv1.5) > `----------------------------- (reserved for TLSv1.6) But the current cipher suite negotiation is already a set. Why not just have one cipher suite value for each version and burn only 4 or so code points rather than 256? On 09/26/2011 08:14 PM, Eric Rescorla wrote: > In an environment where the client could indicate any combination of > versions, the impact of implementing TLS 1.2 only would be that a > server which did not support TLS 1.2 would generate an error instead > of a ClientHello. [ServerHello?] > > Since servers are supposed to select the highest common version, I'm > not sure I see serious difference between these two. The difference is that somebody will look at Wireshark and instead of seeing random disconnects and thinking they're the subject of some low-level DoS attack, they'll see a bright yellow line that reads: "TLS Alert: Endpoints support no common protocol version." - Marsh
- [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Nico Williams
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Marsh Ray
- Re: [TLS] One approach to rollback protection Juho Vähä-Herttua
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Yoav Nir
- Re: [TLS] One approach to rollback protection Dan Winship
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Badra
- Re: [TLS] One approach to rollback protection Matt McCutchen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Yngve N. Pettersen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Martin Rex