Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

Benjamin Kaduk <bkaduk@akamai.com> Tue, 29 May 2018 21:00 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 2CCF012E885 for <tls@ietfa.amsl.com>; Tue, 29 May 2018 14:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 nHUV1NrRdyxA for <tls@ietfa.amsl.com>; Tue, 29 May 2018 14:00:26 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599BD12F281 for <tls@ietf.org>; Tue, 29 May 2018 14:00:26 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TKvNND001921; Tue, 29 May 2018 22:00:19 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=LdAFCyMaC9b+zUmv2xdohsqkgRWqWS6Vrz0lxBn1YhE=; b=Qaacm2Oe/01YuFDsXT1Tn9PweEyewpoTQ8AF6QT2KavSZam2IRBFJQjxFTE4/hWKOY+P /Xy8eO6ytuLeyIepeJqFJ3KmHOQvlFQUNbJ5haVpq2uhUUecFUlJ1afxHpnJtZa3kLZs vv6pJTTaxDlQ9Lah2Z25fJqBL5DtfiwXvkdMWTPyCsfHdM/o4qydQf+GHTHsl5+FMi2n GHl8S6WXW7C0XWhaJqwuFvLW4zUXdybHEnnF85VwJ+VtOU9MTc5onEiJ2tKNyS7L6z5Q bCGs379j7VBNtjFBCaDsmaJ733fX5Oa0vRoV+tWmFJckltnkc1Ve9yKuNUQief7Jgej4 dg==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2j9cw50948-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 22:00:19 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4TKtUB8007062; Tue, 29 May 2018 17:00:18 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j9cvv0bjy-1; Tue, 29 May 2018 17:00:18 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 52CCB20068; Tue, 29 May 2018 21:00:18 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fNlj7-0005M4-EJ; Tue, 29 May 2018 16:00:17 -0500
Date: Tue, 29 May 2018 16:00:17 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Andrey Jivsov <crypto@brainhub.org>
Cc: David Benjamin <davidben@chromium.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180529210017.GM13834@akamai.com>
References: <a96fb90a-5533-6fc9-4473-fa2e5d0ac131@brainhub.org> <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org> <20180529194251.GK13834@akamai.com> <50f2f097-d8b0-334d-e1b2-1ea34fff9d29@brainhub.org> <CAF8qwaAZOZs__81Q2zvreM-X-t07G80V-4t1NKgZCWiP5yD-Yg@mail.gmail.com> <d8b6f651-f5ac-a16e-db81-91812e483f72@brainhub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d8b6f651-f5ac-a16e-db81-91812e483f72@brainhub.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290221
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290221
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9HFc7QmPMUcqRXqOm5vt5Gc7k4g>
Subject: Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?
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, 29 May 2018 21:00:36 -0000

On Tue, May 29, 2018 at 01:26:27PM -0700, Andrey Jivsov wrote:
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> > 
> > At the same time, you still talk to some TLS 1.2 servers, so you may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> > 
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your situation?
> 
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
> 
> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.

In short: no.  CertificateRequest/CertificateVerify have a separate signature+hash
negotiation from the initial handshake, and the server is highly unlikely
to only list the new signature schemes.  (And I think you could decline the
authentication in that case anyway, but didn't double-check.)

The answer could also be "yes" in that if both sides *want* to, it can be done
for client authentication, but in your case you don't want to and are not
obligated to do so.

-Ben

> There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).