Re: [TLS] One approach to rollback protection
Martin Rex <mrex@sap.com> Tue, 27 September 2011 00:18 UTC
Return-Path: <mrex@sap.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 8EAAC11E80AA for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.909
X-Spam-Level:
X-Spam-Status: No, score=-8.909 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8]
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 8bjq+KF78bF0 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:18:52 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE611E808A for <tls@ietf.org>; Mon, 26 Sep 2011 17:18:52 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8R0LXRf015832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 02:21:33 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp>
To: ekr@rtfm.com
Date: Tue, 27 Sep 2011 02:21:33 +0200
In-Reply-To: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com> from "Eric Rescorla" at Sep 26, 11 04:44:18 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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 00:18:53 -0000
Eric Rescorla wrote: > > I've been doing some thinking about how to prevent rollback to > TLS 1.0/SSLv3 from TLS 1.1-capable agents. > > Since there's very little deployment of TLS 1.1+, basically anything > we do now will roll out more or less in parallel with TLS 1.1 deployment, > as long as it's backward compatible.The obvious technique here is to > stuff the relevant indicator in the cipher suites list, since we know that > servers ignore unknown entries there. > > I've taken an initial crack at a draft for this: > http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt 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) So a client offering SSLv3, TLSv1.0 an TLSv1.1 would include cipher suite { 0xYY, 0x07 } And a client offering TLSv1.0 and TLSv1.2 (but not SSLv3 and not TLSv1.1) would include cipher suite { 0xYY, 0x82 } -Martin
- [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