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