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> Tue, 29 May 2018 20:26 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 2509112FA86 for <tls@ietfa.amsl.com>; Tue, 29 May 2018 13:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 VDUAhLoD2SDA for <tls@ietfa.amsl.com>; Tue, 29 May 2018 13:26:30 -0700 (PDT)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 36CAB12FA84 for <tls@ietf.org>; Tue, 29 May 2018 13:26:30 -0700 (PDT)
Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-04v.sys.comcast.net with ESMTP id NjenfaDVPN7zjNlCPf9iPv; Tue, 29 May 2018 20:26:29 +0000
Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-14v.sys.comcast.net with ESMTPSA id NlCNfaUq7dQERNlCOfzj2w; Tue, 29 May 2018 20:26:29 +0000
To: David Benjamin <davidben@chromium.org>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "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>
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: <d8b6f651-f5ac-a16e-db81-91812e483f72@brainhub.org>
Date: Tue, 29 May 2018 13:26:27 -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: <CAF8qwaAZOZs__81Q2zvreM-X-t07G80V-4t1NKgZCWiP5yD-Yg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfGNjpbWorH7TYVNG2bpjgjvLvCJ4/3644SrG1DuJH80wrwZkGeznYqrHY6xqQY3Q5olSscH3Zff/KB7D1sz+Aqzwz/aUm593jGtEEahOySE/KxGo4jv5 e7br5xXBkCiRJYOcLDMM7iXOCVNaNKpWXnRvxrLzvQ+tuimbvT/eKKLbFc8b37Vphs0OtDooxTocPWZSwwQ6YlVxKvsUaSoDnzk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pq0mmhfwQx1ICjknc-90Bdrn5UI>
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 20:26:33 -0000

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.

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).

> 
> On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov <crypto@brainhub.org
> <mailto:crypto@brainhub.org>> wrote:
> 
>     On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
>     > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
>     >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
>     >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
>     >>>> 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.
>     >>>
>     >>> Sounds like it:
>     >>>
>     >>>    RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm
>     using
>     >>>       RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash
>     algorithm
>     >>>       as defined in [SHS].  These values refer solely to signatures
>     >>>       which appear in certificates (see Section 4.4.2.2) and are not
>     >>>       defined for use in signed TLS handshake messages, although
>     they
>     >>>       MAY appear in "signature_algorithms" and
>     >>>       "signature_algorithms_cert" for backward compatibility
>     with TLS
>     >>>       1.2,
>     >>>
>     >>> -Ben
>     >>>
>     >>
>     >> I was referring to
>     >>>
>     >>>    -  Implementations that advertise support for RSASSA-PSS
>     (which is
>     >>>       mandatory in TLS 1.3), MUST be prepared to accept a signature
>     >>>       using that scheme even when TLS 1.2 is negotiated.  In TLS
>     1.2,
>     >>>       RSASSA-PSS is used with RSA cipher suites.
>     >>
>     >> I am OK with what you quoted. What I just quoted represents a
>     >> significant change in behavior in TLS 1.2 and there is no way to
>     opt out
>     >> of this change to TLS 1.2.
>     >
>     > Ah, I misread your original message, but all is clear now.
>     >
>     >> I will add that I've seen this behavior by servers already, even when
>     >> client doesn't advertise TLS 1.3. Just the fact of including some
>     08 xx
>     >> IDs in signature_algorithms in ClientHello, without protocol_version
>     >> extension, gets the TLS 1.2 upgraded to RSA-PSS.
>     >>
>     >> IMO this paragraph should be removed. Those that want PSS in the
>     >> handshake should negotiate TLS 1.3. Preservation of current
>     behavior of
>     >> TLS 1.2 is important, at least as an option.
>     >
>     > First off, it's basically too late to make substantive changes
>     like that;
>     > the bar to meet is something like "a huge outcry from deployments" or
>     > "a critical security flaw".
>     >
>     > Second, what's going on here is that TLS 1.3 is defining some new
>     signature
>     > algorithms for TLS messages, and making them mandatory to support
>     for TLS 1.3.
>     > But negotiation of TLS signature algorithms has *always* been
>     independent of
>     > protocol version.  If you support TLS 1.3, you also support the
>     new signature
>     > algorithms; if you support TLS 1.3 and TLS 1.2, you support the
>     new signature
>     > algorithms and you support TLS 1.2, therefore by the longstanding
>     negotiation
>     > rules you are obligated to support the combination.  You are in
>     effect proposing
>     > that we make a break in the signature (and hash) algorithm space
>     with individual
>     > algorithms supported either in <=1.2 or >=1.3, but not both -- we
>     did this for
>     > ciphersuites since we fundamentally changed the meaning of what a
>     ciphersuite is.
>     > But the signature scheme does not seem to have undergone such a
>     fundamental change,
>     > so it seems hard to justify introducing this sort of split.
>     >
>     > -Ben
>     >
> 
>     We are talking about TLS 1.3-specific IDs:
> 
>              /* RSASSA-PSS algorithms with public key OID rsaEncryption */
>               rsa_pss_rsae_sha256(0x0804),
>               rsa_pss_rsae_sha384(0x0805),
>               rsa_pss_rsae_sha512(0x0806)
> 
>     In TLS 1.2 08 corresponds to the (undefined) hash algorithm, and thus
>     these IDs have no meaning to TLS 1.2.
> 
>     TLS 1.3 spec purposely "split" these IDs so that they have no meaning to
>     TLS 1.2 servers. One needs the paragraph I quoted to force
>     implementations to change the behavior of TLS 1.2.
> 
>     What's the harm of dropping this one paragraph I quoted and keeping TLS
>     1.2 behavior the same?
> 
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>