[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> Tue, 29 May 2018 18:57 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 E21B7124234 for <tls@ietfa.amsl.com>; Tue, 29 May 2018 11:57:43 -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 xY8j_RF4jkqF for <tls@ietfa.amsl.com>; Tue, 29 May 2018 11:57:41 -0700 (PDT)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 7438012EAB7 for <tls@ietf.org>; Tue, 29 May 2018 11:57:41 -0700 (PDT)
Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-08v.sys.comcast.net with ESMTP id NgjzfFeENuPXCNjoSfC7sS; Tue, 29 May 2018 18:57:40 +0000
Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-20v.sys.comcast.net with ESMTPSA id NjoRf2Qv9fXTANjoRfG8xE; Tue, 29 May 2018 18:57:40 +0000
To: "tls@ietf.org" <tls@ietf.org>
From: Andrey Jivsov <crypto@brainhub.org>
Openpgp: preference=signencrypt
Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= xsBNBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAHNH0FuZHJleSBKaXZzb3YgPGEuaml2c292QGY1LmNvbT7CwHgEEwECACIFAlbFIFYCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELgEWn228sNLaVAH/2kv4jXHYn6mP8yTWeD5 5BmBK4eu/vAiNLZVXBhUJxv3oZLBbowZGYgnQ1BwOYZn53hbC7TGIg5QIhEAgfxvyR73R7jO DqV8Uc/jRhyl2L8eB5MkKcxBpcT0Y8g2bm7bPlCF4YX7HEks+qu9c7bAbCdYJiaqjA3WgMFm 9yh3zthsOzzC/WWq+SeXeSQ6NTK3+2TH4zlDkuwt189cTKi8KG1yyLtd6FXWGDg+Zizv40p5 OM67KdTEOmn52gGWPlLZzPzpLlrR8zVTFoxKmZW/Xhp4IEsamk+lmF5OJXQysoYEIjdEcBFE CK4czNJC3tnqOOf/+hgNlo5CwhrkSzeZL7vOwE0EVsUgOQEIAOVkchUqBCxNVAm7qn8rSIZA D5iloxoaqnf4EKtJxbauyBq4XxkskTm1gzprjZsnWQirv4+1ebi2rgTtg5wyhV2WfrF61r7c trjIpmfe2fqK3xhhUrresbXNAv16mc08UR+ZYflBaCwumjYTBD4Rq57cS+kL1AoiZta+0Idy llOjJiIUuYq6yL+eNVFQ+Sv31MIV0ydWskjsSM9Hq/JyuUmcjPSi+g6xSbSP1lFJ1rGKRQp3 UX+H5ExJekLPHzLpGNHwHy/fOtf2VJzKCafWfDDnggm3PahxMgN8tFqpJ1WJiL9T+xQRhBCh bYXHnCv0dmjzyQlVMH7awPqXLRmp8CMAEQEAAcLAXwQYAQIACQUCVsUgOQIbDAAKCRC4BFp9 tvLDS9zHB/wMZBXPQVTj9kmTs8+wecG1HSgv08wt88HJAYNOlgWRcygGHvlinwRCnon9kxEF PAKlu35qYl5qFHcglJZRaiZVwfOhVmqXg+SmFKKmnhrrFHQCHqq2mW2+K/dloATKy8j8m9Rz /zCLD2xDAb0bIJDF4f7iemymBdDaFiNok5+XgXg/QXNndz3FO/S2IF+t2oHM1e7hBj+NEfER nNTE9gG8KkQGPVvyPZmVgSwsQ7dGnxuvdak6EaWG4M6Rbcwq0vu2lzvj1I3xaqJHhhwmsHAo qL9t8B/g6QwXr7hkHZ+zHKtFaY1zp3aKjj6xayfIUXY19VvAHodzCPjq8Sa7RJi8
Message-ID: <a96fb90a-5533-6fc9-4473-fa2e5d0ac131@brainhub.org>
Date: Tue, 29 May 2018 11:57:39 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-CMAE-Envelope: MS4wfEulnnsWg0Z/C0IXruXzS2OcZVv2oDOp31hyc4urYUSX20RERCfV6eAX1wtcwcPcqUSOCTOERI1HRrqGScAeugLRdRgrS1ogvYJ/HpV8EDGO77QcbMp+ REzPMOf3hyWs+vpwnUHZv98Z6cgLxUtA09ogiWxL99bqv0Qoca8erKRt
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/neQ25m-K17bxuBVcrZIwjsGPdGc>
Subject: [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 18:57:44 -0000

Greetings.

TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
wants to negotiate TLS 1.3, it must support an upgraded (and
incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.

You might recall that the possibility to negotiate between PSS and
RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
signatures, was discussed on the mailing list. The WG decision then was
to hard-wire PSS in the TLS 1.3 handshake.

I don't recall any discussion on going further than this, all the way to
changing the 10-year old TLS 1.2.

Unfortunately, our products have issues with PSS beyond our control. The
only solution left to avoid receiving PSS with TLS 1.2 is to never
negotiate TLS 1.3 as a client. Another solution is insecure fallback,
but we presently don't do this.

Is my reading of the situation correct? Thank you.