Re: [TLS] TLS 1.2 clarification requested

Yoav Nir <ynir@checkpoint.com> Tue, 01 October 2013 19:48 UTC

Return-Path: <ynir@checkpoint.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 AFB4311E8270 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 12:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 i4-fzKNAT8gS for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 12:47:51 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B29C421E805F for <tls@ietf.org>; Tue, 1 Oct 2013 12:46:20 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r91JkIvY016560; Tue, 1 Oct 2013 22:46:18 +0300
X-CheckPoint: {524B2689-F-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 22:46:17 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "Kain, Michael T" <Michael.Kain@unisys.com>
Thread-Topic: [TLS] TLS 1.2 clarification requested
Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhP//2+0A
Date: Tue, 1 Oct 2013 19:46:17 +0000
Message-ID: <A2B75A91-EBFC-415A-9671-81E939819ACF@checkpoint.com>
References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com>
In-Reply-To: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.231]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: multipart/alternative; boundary="_000_A2B75A91EBFC415A967181E939819ACFcheckpointcom_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.2 clarification requested
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, 01 Oct 2013 19:48:04 -0000

On Oct 1, 2013, at 9:58 PM, "Kain, Michael T" <Michael.Kain@unisys.com<mailto:Michael.Kain@unisys.com>> wrote:

I’m trying to understand the TLS 1.2 restrictions and signature algorithms and how they interact.  Is there a relation between the signature algorithm that is negotiated between client and server and the algorithm which signed the server certificate?

Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectively, and also MUST be signed by ECDSA and RSA respectively. I'm not sure why that last restriction is needed, but it's there. For non-EC ciphersuites, there is no restriction, but you still need to negotiate an algorithm that works with the public key.

Does that affect the hash algorithm of TLS 1.2 – or is that always SHA256?

The hash used in the algorithm (for example: to calculate the Finished message) is ciphersuite-specific, but all current ciphersuites that anybody uses specify SHA-256.

For example, if I’ve got a server configured with a server certificate signed with SHA256, can it still establish a connection using the TLS_RSA_WITH_AES_256_CBC_SHA?

Yes, and then you'll have
 - a certificate signed with RSA-with-SHA256
 - records MAC'd with HMAC-SHA1
 - SHA256 in the Finished calculation

Does the signature algorithm for a certificate affect which Ciphersuites can be negotiated and used?

Only because the ECC RFC says so. It is obviously restricted by the public key. There's also the DH and ECDH key exchanges (non-ephemeral) that have their own restrictions, but I'm not aware of anyone who uses them.

Yoav