[TLS] PR to clarify RSASSA-PSS requirements

Peter Wu <peter@lekensteyn.nl> Wed, 22 November 2017 03:54 UTC

Return-Path: <peter@lekensteyn.nl>
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 9B52F1250B8 for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 19:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 23PfZF9gUaoa for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 19:54:09 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C23F129C20 for <tls@ietf.org>; Tue, 21 Nov 2017 19:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=bwsz74HxjJpSf3Pao2QOdZli7w8Gxsck0eb1Es8lZDg=; b=ngMrcaRQNEOWu6YvDhqxcMf96/fGGfD5gNzb8Gl0DI0KvJ+I3eBr2sDvxXWwwYY3XetXm8f3BT6d9gG+0ntkMaWuILnT0ht+VVrWDw7RqpQgyuUIO0iyioj7GKRviabJEdu1+MVIsdr7GhPMoQ1K8+PW7H15mqXOHg55DzXrpVMCikiMw4NsVGzlUvXLi7683kyuWnvqeoUAYWrvWECZZ1R7JvswsD369ETqSgiJiQr5WYaFEFA+kJhS3WN9oYvfFQdz7msNKT64arugxWzHV86kTsLYo3QHWqv3JlYqhyHyqM13GRr2GhJodn2QYN+8Cxcee/jnnrpUVgkhB7tUhQ==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <peter@lekensteyn.nl>) id 1eHM6w-0004yj-B8 for tls@ietf.org; Wed, 22 Nov 2017 04:54:07 +0100
Date: Wed, 22 Nov 2017 03:54:04 +0000
From: Peter Wu <peter@lekensteyn.nl>
To: tls@ietf.org
Message-ID: <20171122035404.GC18321@al>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zsvehKHpL7BvUlosiyRTveqwot0>
Subject: [TLS] PR to clarify RSASSA-PSS requirements
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: Wed, 22 Nov 2017 03:54:12 -0000

Hi,

At the moment there is still ambiguity in the requirements for PSS with
relation to certificates. Proposal to clarify this:
https://github.com/tlswg/tls13-spec/pull/1098


This PR intends to clarify the requirements for PSS support.

The requirements are intentionally minimal to reduce implementation
efforts, but recognizes that some other implementations may be more
complete. Notes:

- "Supporting PSS signatures on certificates is a mandatory requirement
  and I think we should be very clear about the parameters we permit."
  https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
- Martin Rex wishes to remove TLS requirements on signature algorithms
  for certificates, hence the "MAY" for other PSS parameters in this PR.
  https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
- Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
  certificates, hence the strong MUST wording in this PR.
- It does not say anything about non-end-entity certificates, that's up
  to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
  rsa-pss; EE key: rsa" from
  https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
- PSS params in certificates are explicitly not restricted, satisfying
  https://www.ietf.org/mail-archive/web/tls/current/msg24457.html

>From what I have heard, boringssl does not (or will not?) implement any
PSS support in the certificates (yet?). Don't know if anything should be
changed here to reflect that decision, but I thought it is worth
mentioning. It is possible that I'll follow boringssl's example in tris.

If a TLS extension is introduced later, hopefully that improves interop
with odd keys and signatures that are optional in this PR (PSS pubkey or
custom salt lengths).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl