IETF Logo Mail Archive

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

Dr Stephen Henson <lists@drh-consultancy.co.uk> Tue, 12 September 2017 15:42 UTC

Return-Path: <lists@drh-consultancy.co.uk>
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 9E085132D7B for <tls@ietfa.amsl.com>; Tue, 12 Sep 2017 08:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG0LiPH3g2b3 for <tls@ietfa.amsl.com>; Tue, 12 Sep 2017 08:42:39 -0700 (PDT)
Received: from claranet-outbound-smtp07.uk.clara.net (claranet-outbound-smtp07.uk.clara.net [195.8.89.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8371320D9 for <tls@ietf.org>; Tue, 12 Sep 2017 08:42:39 -0700 (PDT)
Received: from host86-132-183-251.range86-132.btcentralplus.com ([86.132.183.251]:6737 helo=[192.168.1.78]) by relay07.mail.eu.clara.net (relay.clara.net [81.171.239.37]:10465) with esmtpa (authdaemon_plain:drh) id 1drnKa-00023d-Pi (return-path <lists@drh-consultancy.co.uk>); Tue, 12 Sep 2017 15:42:33 +0000
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, tls@ietf.org
References: <20170908225948.GC31695@al> <CABcZeBNYoqpWx_3V42wut3FUUt3xELv5J5YayvcrhwzJKqgcyg@mail.gmail.com> <cafe5f94-f2f8-98d7-c536-fbc59e94fb97@drh-consultancy.co.uk> <1505225444.4161.35.camel@redhat.com>
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
Message-ID: <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk>
Date: Tue, 12 Sep 2017 16:42:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1505225444.4161.35.camel@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YQuWHGZnYe6O3bQNCwFQ5UJUq-I>
Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Sep 2017 15:42:42 -0000

On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote:
> 
> That is, because a TLS server would typically sign with whatever
> algorithm the client supports and would very rarely be interested to
> utilize the security advantages of including the parameters (which,
> advantages, are quite unclear even to a crypto expert). Otherwise, a
> certificate restricted to SHA-384 and 48-bytes of salt, will not be
> able to serve a client which only supports RSASSA-PSS with SHA-256.
> 
> As such, it would make sense for TLS 1.3 to recommend no parameters for
> such RSASSA-PSS certificates, to ease their deployment.
> 

Well restrictions in CA keys would be handled by the PKI verifier: if there is a
violation the chain should be rejected and it's a problem with the chain itself
and an error by the CA that issued it. A different case is where the
restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, though
again it's a CA error issuing such a chain for TLS 1.3 use.

A restriction on the EE key isn't quite the same. There are two cases.

One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 digest
doesn't match signing digest or minimum salt length exceeds digest length). In
this case a server should never present the chain or if it does a client would
justifiably reject it and abort the handshake. Again this is an error by the
issuing authority which should be corrected.

The second case is that the parameter restriction is permitted by TLS 1.3 and
this limits the digest which the key can sign with. Say the restriction is
SHA384 and the client only supports rsa_pss_sha256. The server might then use to
a different PSS key (and certificate chain) that supports rsa_pss_sha256 or fall
back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS message
signed with parameters that violate the restrictions it could (with some
justification) abort the handshake.

This could get pretty messy: it requires a logic not used in any other
algorithm. I'd be more than happy to have an outright prohibition on EE PSS key
parameter restrictions in TLS 1.3 so implementers don't have to bother with this.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/

v2.23.0 | Report a Bug | By Email