IETF Logo Mail Archive

Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and

Wan-Teh Chang <wtc@google.com> Thu, 17 February 2011 01:30 UTC

Return-Path: <wtc@google.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469763A6F08 for <tls@core3.amsl.com>; Wed, 16 Feb 2011 17:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.477
X-Spam-Level:
X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MBJ7Qum7qM7 for <tls@core3.amsl.com>; Wed, 16 Feb 2011 17:30:47 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A7A513A6F02 for <tls@ietf.org>; Wed, 16 Feb 2011 17:30:46 -0800 (PST)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p1H1VFwc031204 for <tls@ietf.org>; Wed, 16 Feb 2011 17:31:15 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297906275; bh=AKLZIJfRdplNYrojpzmVXV4IZh8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=DoGzi6k2rsaKWJ4i21aYNWMd6yW5ufYPiOR852kSVQqzejA21pU1imvkLzYfhR7NI 7fd04hiFEZpk7MSn+E6zg==
Received: from wwf26 (wwf26.prod.google.com [10.241.242.90]) by hpaq5.eem.corp.google.com with ESMTP id p1H1VEbT029436 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Wed, 16 Feb 2011 17:31:14 -0800
Received: by wwf26 with SMTP id 26so2132340wwf.19 for <tls@ietf.org>; Wed, 16 Feb 2011 17:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ALRFodL4Eyz8v2Y6I+tnAch2shjFhVuKU+izemA3+dU=; b=SWmmoZSobmrECg42txauHjeG1iwousdSsoI3EzOddtspziKWKnj/zOLAj/eEt87gXq rlk5Iu6o48Ct4pMFpjsA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hjQrBWUTDAGiyCSibWIb3hgSbQZakDbAPr+/WgGe3TfP0/xR0K7pAtz0v+asZtl35O +oP9JjJDWgziNL9tuAXg==
MIME-Version: 1.0
Received: by 10.216.63.138 with SMTP id a10mr1074299wed.27.1297906273715; Wed, 16 Feb 2011 17:31:13 -0800 (PST)
Received: by 10.216.6.81 with HTTP; Wed, 16 Feb 2011 17:31:13 -0800 (PST)
In-Reply-To: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp>
References: <4D59B8FE.6010908@pobox.com> <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp>
Date: Wed, 16 Feb 2011 17:31:13 -0800
Message-ID: <AANLkTi=bwX8nnHLuOs93eL9WpkieGQnY2PzaiTsy9pJa@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: mrex@sap.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Thu, 17 Feb 2011 01:30:48 -0000

On Wed, Feb 16, 2011 at 3:35 PM, Martin Rex <mrex@sap.com> wrote:
>
> What I also don't understand is the idea behind "default signature
> algorithms".  For implementing TLSv1.2, SHA-256 _must_ be supported,
> but unless explicitly negotiated with the TLS SignatureAlgorithm
> extension, SHA-256 appears not allowed to be used for CertificateVerify.
>
> That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms
> extension exchanged, the resulting signature with an RSA client cert
> in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1,
> but _only_ SHA-1 (which slightly weakens that signature compared to
> prior protocol versions...).  The use of SHA-256 is prohibited!??!

I think you're right.  RFC 5246 Section 7.4.1.4.1 seems to say that
{sha1,rsa} is the default RSA signature algorithm.

I guess the solution is for a TLS 1.2 client to always send the
signature_algorithms extension, and for a TLS 1.2 server to use
a non-empty supported_signature_algorithms field in the
Certificate Request message.

Alternatively, we can amend RFC 5246 to change the default
RSA signature algorithm to {sha256,rsa} .  It seems that anything
that uses MD5+SHA-1 in TLS 1.0 and 1.1 should use SHA-256
by default in TLS 1.2, for consistency.

Wan-Teh Chang

v2.23.0 | Report a Bug | By Email