Re: [TLS] DSS with other than SHA-1 algorithms

Martin Rex <mrex@sap.com> Wed, 11 May 2011 16:20 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 E5F42E07B0 for <tls@ietfa.amsl.com>; Wed, 11 May 2011 09:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.687
X-Spam-Level:
X-Spam-Status: No, score=-8.687 tagged_above=-999 required=5 tests=[AWL=1.562, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f+a29igmMGE for <tls@ietfa.amsl.com>; Wed, 11 May 2011 09:20:20 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4B6E07A3 for <tls@ietf.org>; Wed, 11 May 2011 09:20:19 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p4BGJxpH025866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 18:19:59 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201105111619.p4BGJwjq004242@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz
Date: Wed, 11 May 2011 18:19:58 +0200
In-Reply-To: <E1QJzDG-0006iS-85@login01.fos.auckland.ac.nz> from "Peter Gutmann" at May 11, 11 02:31:46 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] DSS with other than SHA-1 algorithms
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: Wed, 11 May 2011 16:20:23 -0000

Peter Gutmann wrote:
> 
> Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:
> >
> > According to me this study would be an argument for the _RSA ecc
> > ciphersuites rather than the ECDSA.
> 
> Why?  The draft contains the combinations of parameters and options that
> everything seems to support and everything seems to get right.  Why the
> obsession with _RSA?
> 
> (Note, if you can document support for, and interoperability among,
>  Microsoft, NSS, OpenSSL, and one or two other implementations,
>  for _RSA, I'll be happy to add it).
> 
> To reiterate this yet again, the draft collects in one place the various
> combinations of parameters and options that everything I could find supports
> and handles correctly.  What it doesn't contain is speculative options that
> may or may not work and may or may not be supported.  It is an attempt to
> document the status quo and point out the best options to use in order to
> maximise interoperability.


I think it is worth considering to describe an interoperable set of
_RSA based EC ciphersuites and parameters.

In case that there are, in fact, interop problems with the existing
definitions in the installed base, TLS WG should try to figure out
the kind of problems that exist in the installed base and
try to come up with solutions for these interop problems.

Possible solutions for interop problems with _RSA cipher suites might be:

  - describe workarounds to deal with the problem within the currently
    defined protocol options.

  - modify the existing (TLS extension) definition (in a backwards-compatible
    fashion, of course) to overcome the problem

  - add a new extension

  - define new cipher suite codepoints to represent the intended purpose
    and interop-test _before_ shipping implementations this time around


-Martin