Re: [TLS] TLS RSA-PSS and various versions of TLS

Benjamin Kaduk <bkaduk@akamai.com> Tue, 25 April 2017 14:39 UTC

Return-Path: <bkaduk@akamai.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 7E301131533 for <tls@ietfa.amsl.com>; Tue, 25 Apr 2017 07:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 xNiupLYtPoD7 for <tls@ietfa.amsl.com>; Tue, 25 Apr 2017 07:39:24 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 19F67131472 for <tls@ietf.org>; Tue, 25 Apr 2017 07:36:30 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 896DB16C8F1; Tue, 25 Apr 2017 14:36:29 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6974616C8EB; Tue, 25 Apr 2017 14:36:29 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1493130989; bh=Oi2PKk/PmGkjhpVInoScUK0zrGmo2zwTwZea0mMy8DM=; l=5991; h=To:References:From:Date:In-Reply-To:From; b=JIMOL2PHBwqUQcNNTE9GMGHG/xwskfr6vepLtv/ccFmJJckls0PxQaPfZhcx8+KKh QV42u0p0zVTPHc/zteqm3ALRIBhnGmol+a7fLrfW94f3sKtcwIJcXpTUioBwfVbZ6b w0KJXBmrz1apXSON7fQ2Etd04o7V+M7FzLbdn0vE=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 180311E33C; Tue, 25 Apr 2017 14:36:28 +0000 (GMT)
To: Dr Stephen Henson <lists@drh-consultancy.co.uk>, tls@ietf.org
References: <E521BA5F-4563-44D2-B186-B11B7B214A15@mobileiron.com> <20170208211738.GB17727@LK-Perkele-V2.elisa-laajakaista.fi> <53320524-0da9-2b59-c348-e1d585572c03@drh-consultancy.co.uk> <a5e04ee0-b1d3-abff-fb1f-b397f9f8b7d2@drh-consultancy.co.uk>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <05dc96c4-900b-6237-e008-ae8364fffe65@akamai.com>
Date: Tue, 25 Apr 2017 09:36:28 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <a5e04ee0-b1d3-abff-fb1f-b397f9f8b7d2@drh-consultancy.co.uk>
Content-Type: multipart/alternative; boundary="------------CD5C658AC67C0F940310A322"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5EXEWpQwNM2PVWTLWEc9Skv3UtE>
Subject: Re: [TLS] TLS RSA-PSS and various versions of TLS
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, 25 Apr 2017 14:39:26 -0000

On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>> certificates too?
>>
>> For example could a TLS 1.2 server legally present a certificate containing an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
>> a certificate contain an RSASSA-PSS key?
>>
> I can't recall getting a definitive answer to this. IMHO we should make the
> requirements clear in the spec otherwise we could get interop issues.
>
> Based on the opinions stated in this thread that would be:
>
> 1. When PSS signatures appear certificates, MGF digest and signing digest MUST
> match and the salt length must equal the digest length.

We have (in section 4.2.3, Signature Algorithms):

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
      PSS [RFC3447 <https://tools.ietf.org/html/rfc3447>] with mask generation function 1.  The digest used in
      the mask generation function and the digest being signed are both
      the corresponding hash algorithm as defined in [SHS <https://tools.ietf.org/html/draft-ietf-tls-tls13-19#ref-SHS>].  When used
      in signed TLS handshake messages, the length of the salt MUST be
      equal to the length of the digest output.  This codepoint is also
      defined for use with TLS 1.2.


Is the concern that this is insufficiently clearly indicated as placing requirements on signatures of certificates as opposed to signatures of TLS data structures?



> 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST
> be supported both as server keys and CA keys in certificates.

Similarly to (1), I believe that it is possible to read the existing
(draft-19) text as making these requirements already, so is the concern
that the text needs to be more clear?


> 3. PSS only keys MUST be supported for TLS 1.2 also.
>

Section 1.3, "Updates Affecting TLS 1.2" notes:

   [...]
   -  RSASSA-PSS signature schemes are defined in Section 4.2.3
<https://tools.ietf.org/html/draft-ietf-tls-tls13-19#section-4.2.3>.

   An implementation of TLS 1.3 that also supports TLS 1.2 might need to
   include changes to support these changes even when TLS 1.3 is not in
   use.  See the referenced sections for more details.


-Ben