Re: [TLS] One approach to rollback protection

Eric Rescorla <ekr@rtfm.com> Tue, 27 September 2011 00:26 UTC

Return-Path: <ekr@rtfm.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 7165C21F8E33 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.762
X-Spam-Level:
X-Spam-Status: No, score=-101.762 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 e+WfpUdbP5Ys for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:26:04 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4D21F8E31 for <tls@ietf.org>; Mon, 26 Sep 2011 17:26:04 -0700 (PDT)
Received: by wyh21 with SMTP id 21so4844323wyh.31 for <tls@ietf.org>; Mon, 26 Sep 2011 17:28:48 -0700 (PDT)
Received: by 10.227.178.141 with SMTP id bm13mr3316674wbb.33.1317083327777; Mon, 26 Sep 2011 17:28:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 17:28:07 -0700 (PDT)
In-Reply-To: <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp>
References: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com> <201109270021.p8R0LXMQ012210@fs4113.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Sep 2011 17:28:07 -0700
Message-ID: <CABcZeBNvASxnr1uzkP38_T2A0foYVUnz6UQhK8kH1yO=b8qLOw@mail.gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 00:26:05 -0000

Hmm... What's the advantage of something this complicated/expressive,
especially given that there is no way to currently express
"I speak TLS 1.2 but not 1.0"?

My objective here isn't to replace the TLS version negotiation mechanism
but merely to remove the downgrade attack problem. If we get that right,
and there is WG interest in revamping the version system, we can do that at
some other time.

-Ekr



On Mon, Sep 26, 2011 at 5:21 PM, Martin Rex <mrex@sap.com>; wrote:
> 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
>