Re: [TLS] One approach to rollback protection

Martin Rex <mrex@sap.com> Tue, 27 September 2011 20:30 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 53EE221F9032 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 13:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.058
X-Spam-Level:
X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 NdUBI0z24uib for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 13:30:00 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7141921F9031 for <tls@ietf.org>; Tue, 27 Sep 2011 13:30:00 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8RKWdRL026772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 22:32:44 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109272032.p8RKWcOE019726@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Tue, 27 Sep 2011 22:32:38 +0200 (MEST)
In-Reply-To: <CABcZeBNvASxnr1uzkP38_T2A0foYVUnz6UQhK8kH1yO=b8qLOw@mail.gmail.com> from "Eric Rescorla" at Sep 26, 11 05:28:07 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 20:30:01 -0000

Eric Rescorla wrote:
>
> I wrote:
> > 
> >  [ciphersuite minor value composed of bitmask]
>
> 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"?

Having slept over my own proposal (and considering the lack of interop
of the original TLS version negotiation demonstrated by the installed base),
I would be fine with a small set of simple cipher suite values, starting
with TLSv1.0.

My primary interests are

  - reducing the amount of failed TLS handshakes

  - allow TLS clients without reconnect fallback to propose
    TLSv1.1 or higher without risk of new interop failures with
    version intolerant servers or bugs related to RSA premaster secret
    client_version checks, such as the bug in Win7/Win2008R2 renego.

  - get protection for the TLS version negotiation for free
    (for peers that implement this)

Our implementation is unconditionally including the rfc5746 renego SCSV
in every ClientHello, so I don't see an interop issue with this.

Even sending TLS extension (which we do not) seems to be not much
of a problem these days.  But the number of interop problems that
we have noticed ourselves in TLS version negotiation, including incorrect
RSA premaster secret client_version checks, is very disappointing.

The changes necessary to add TLSv1.1 support to our implementation
looks pretty marginal, because it is essentially only the explicit
random IVs for TLS cipher suites with block ciphers in CBC mode
(plus removing the CBC-padding oracle, but already did that
 for all protocol versions).

But I would really like see a more robust TLSv1.1 negotiation
being standardized, because I don't see sending
ClientHello.client_version = { 0x03, 0x02 } as a viable option
due to the known interop problems for some more years.


-Martin