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 19:42 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 E1C4E127137 for <tls@ietfa.amsl.com>; Tue, 29 May 2018 12:42:58 -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 oWyb9ScXEZPz for <tls@ietfa.amsl.com>; Tue, 29 May 2018 12:42:56 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 14FFC12EBCF for <tls@ietf.org>; Tue, 29 May 2018 12:42:56 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TJbAcn002122; Tue, 29 May 2018 20:42:53 +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 : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=1aJlvgRpTdL5jcv9UOo7J6VFPllUR/IBNm3w6VYerlQ=; b=kWol9Emqmo9dac/Em9yzYaaAWB19H6X5iYpKUN+Ojl3MvzYXkHdH1B+XQGZYNV+cu1HL yaSTUXvaaiGcbb3KbQmyLpZrZB3gmzT5g2LgbDRolbKLGvggrmhaSNIdvO9N/psMONGG w/K6DGKIKyPae+DR136zje9mk4n4WM/mwuq8yY394et3UaSoaGXTdp1HohLOlYlHoB2f bZXbGuE8d/wQC3NvX7Szb/mC57wRtjw10aWNC4V+s3w/AX5js6PdyuXq22jkza3ry3HM +IRbAxPRkZaY+TiTwt8fViy8S/BrKmLeEKfAjvD47eckEWruRZod8pLPTgFWlJ0vTGAn nQ==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2j9cw501yp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 20:42:53 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4TJZn03007999; Tue, 29 May 2018 15:42:52 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2j9cw982k8-1; Tue, 29 May 2018 15:42:52 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 3E3E31FC11; Tue, 29 May 2018 19:42:52 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fNkWB-00053u-KF; Tue, 29 May 2018 14:42:51 -0500
Date: Tue, 29 May 2018 14:42:51 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Andrey Jivsov <crypto@brainhub.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180529194251.GK13834@akamai.com>
References: <a96fb90a-5533-6fc9-4473-fa2e5d0ac131@brainhub.org> <20180529191319.GJ13834@akamai.com> <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@brainhub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2f30d9d5-17a0-4a83-ab2d-bfd399c73fd2@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_08:, , 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-1805290209
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_08:, , 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=1015 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-1805290209
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UvvZ_W3jVNrwFkNqcCfXBCwVxxc>
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:42:59 -0000

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