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?

Andrey Jivsov <crypto@brainhub.org> Wed, 30 May 2018 04:53 UTC

Return-Path: <crypto@brainhub.org>
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 4FB7312DA3D for <tls@ietfa.amsl.com>; Tue, 29 May 2018 21:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Q6Tw92mrKtLE for <tls@ietfa.amsl.com>; Tue, 29 May 2018 21:53:54 -0700 (PDT)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 070C61271FD for <tls@ietf.org>; Tue, 29 May 2018 21:53:52 -0700 (PDT)
Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with ESMTP id Nt64fqCdgRNLYNt7QfTExK; Wed, 30 May 2018 04:53:52 +0000
Received: from [192.168.0.10] ([73.222.32.57]) by resomta-po-20v.sys.comcast.net with ESMTPSA id Nt7Of4ihFfXTANt7PfGuht; Wed, 30 May 2018 04:53:52 +0000
To: Martin Thomson <martin.thomson@gmail.com>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
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> <CAF8qwaB_LoPAvz41k0_+FANnrAznzTHE9h4dhq5SKP+mkiL0jg@mail.gmail.com> <7c503b05-1c33-7c94-d79f-b7feb2d8c145@brainhub.org> <CABkgnnXBsNQDebM7R60XzjujX-oXZHQmW6vb1-eiHHun0pTLng@mail.gmail.com>
From: Andrey Jivsov <crypto@brainhub.org>
Message-ID: <97d05a8c-3d4e-0ce8-d0d1-7d64a8b4f227@brainhub.org>
Date: Tue, 29 May 2018 21:53:50 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnXBsNQDebM7R60XzjujX-oXZHQmW6vb1-eiHHun0pTLng@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfO5WLQtb5z7INGWGKl+reS7UlEQhooVDVTaU2RLnUtXLZciLjpdv9u+X13smudKgjuJBFF31JKaJmoA/mIUEC2lGxKp1JTckuU3WOdUfjKLnYJjjZHBi U27a/MC/0zvA5HK1qdtipifOvEj4lhpJ3fJWx+iiF20P3Nt64ZwvtIQtL1Ihndr7GL4C/XTjnQYvu2a5lbJ/lBKxxEALsv3JYfBdL6BW4Tg524RNFkPs/C5q
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Hm4QvqHHs0JRvEFIfhJhgbHcLMM>
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: Wed, 30 May 2018 04:53:56 -0000

On 05/29/2018 06:17 PM, Martin Thomson wrote:
> On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov <crypto@brainhub.org>; wrote:
>> The issue here is that some hardware devices don't implement RSA CRT
>> method with PSS, because they hard-wide RSA, legacy padding, and CRT
>> method in one operation. RSA PSS can still be done, but only via a
>> general modexp operation, which will be ~2x shower. Therefore, in these
>> scenarios PSS incurs 2x performance penalty.
> 
> I'm fairly certain that we've had this discussion before.  What is new?
> 

The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
support TLS 1.3 is new.

I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
will take place?

- This upgrade of TLS 1.2 can only be done by servers that support TLS 1.3.
- TLS 1.2 clients won't advertise TLS 1.3 Signature Algorithm IDs; only
TLS 1.3 clients will have e.g. rsa_pss_rsae_sha256 and others in
signature_algorithms.

Therefore, TLS 1.3 should get negotiated between these peers.

The relevant paragraph from the TLS 1.3 draft seems to add uncertainty
in unexplained cases when TLS 1.3 server decides to drop the negotiated
version to TLS 1.2. What problem does this paragraph try to solve?