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 19:35 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 131F812EC1A for <tls@ietfa.amsl.com>; Tue, 29 May 2018 12:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brainhub-org.20150623.gappssmtp.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 ZmuHKDH98g_x for <tls@ietfa.amsl.com>; Tue, 29 May 2018 12:35:22 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 C690512EBD7 for <tls@ietf.org>; Tue, 29 May 2018 12:35:22 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id a14-v6so7770210pfi.1 for <tls@ietf.org>; Tue, 29 May 2018 12:35:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainhub-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I1BA6D5YVLejCu1VkNBNhsIrupY6Q/F/suv/f//NUYY=; b=Nd/XM/QeDafVdbG3CAO78PmXZEo09pB7pnCKQ5nAAYSo+u3slpBCcWydto1TqJ33ax ejcYXZmK/KvMEpQLp+hmnPwlbp7bsVmoLvxIrKwG03C6zT5RFBLlJXUgVl9ElmZfLYqI lsZ8l/F9XOM7Lhd7o6t6e9oHY8nKxq0cf9DSRxZASRIASRj2Ar0IfqE3HEtxVbEGyG/r rzbcD4VHrWAGsFUEhQd+r17G7nr9qklU0f4Mdx1KBst6+LbNqsFRyYw224fi/6MNpUuD 8bRNpSFfHiZQkK9Oh0nsPmQVClt/Mf3QA+HLm9MUIi89jVuhbxZCsHcsuFVu7Fb/y1xw ysQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I1BA6D5YVLejCu1VkNBNhsIrupY6Q/F/suv/f//NUYY=; b=WN7K4X0mQnUsp49elKiN2uBwwZ68ftLLuc0SqEK3NV9uJaX2cU5XbqpD2rDbAfg84v 0xYej+W/W7Mn7G51NAW9+tgCsg30GeCYZGH/PVvrvBNzn1y+3wn3eGIhQluwcgZyXHpA 1AJ1S6XNV4GtzYAEDc4rlYQuzlh6IUEv9fjAM9X0ICeCGDcK8587xukn6YZePdRcm6tr BMP5Fcj1kxTmJFcP/GcQBWVxyBVbGFYRwwP8XXpXWDxpfiaJ24hUik58Ex/jSSLhDdWv EA6U6FI5OyHuj4Ya8GX0XiDmykElZVNsclRvORzqEg+W6qYPuiwUVsj5Pu2BAQA1nu0n 6Iig==
X-Gm-Message-State: ALKqPwf6pW7iM35Bqiq9yw/ZYlYlsKoIIyBeyonKRpH1vltWRcCf0+2r bZFefwc17A3F+lffPECzuWT3vpaX
X-Google-Smtp-Source: ADUXVKKE6Kw1UM0OhOO2gueIPwxxnDMS+ZdA+fp9gzzGUv6JcgEdHn80qpSIaEslqFTRntl3kdt6kQ==
X-Received: by 2002:a62:a054:: with SMTP id r81-v6mr13752001pfe.10.1527622521913; Tue, 29 May 2018 12:35:21 -0700 (PDT)
Received: from [192.168.86.104] ([104.219.107.83]) by smtp.googlemail.com with ESMTPSA id r68-v6sm71475313pfi.174.2018.05.29.12.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 12:35:21 -0700 (PDT)
Sender: Andrey <andrey@brainhub.org>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <a96fb90a-5533-6fc9-4473-fa2e5d0ac131@brainhub.org> <20180529191319.GJ13834@akamai.com>
From: Andrey Jivsov <crypto@brainhub.org>
Message-ID: <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org>
Date: Tue, 29 May 2018 12:35:20 -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: <20180529191319.GJ13834@akamai.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9vVT0oVsNhWRPReoiz6a4cPLgrw>
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 19:35:25 -0000

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.

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.