Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

"Filippo Valsorda" <filippo@ml.filippo.io> Thu, 12 December 2019 15:26 UTC

Return-Path: <filippo@ml.filippo.io>
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 31CDF120047 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2019 07:26:21 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filippo.io header.b=sGdF+NmB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JKXK+z9z
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 OLo0jkUdEfoE for <tls@ietfa.amsl.com>; Thu, 12 Dec 2019 07:26:19 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033D7120033 for <tls@ietf.org>; Thu, 12 Dec 2019 07:26:18 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1BC152275F for <tls@ietf.org>; Thu, 12 Dec 2019 10:26:18 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Thu, 12 Dec 2019 10:26:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=8w9sM eWyX/h6YdjxpuGlLOmOj31+a09DPzanVpZaE0Y=; b=sGdF+NmByxvkrn2cZKpQq kBvNttI06fj9SihhTffyzpqoKS0FYioOPMOs7cRmFX8XCdRIS8b0HgTRBkfGgUnq 8S8OJZ9XtN+OVMRdmrRt815FpM8Bq+WOkBDlYfJObo4foYdJHj3v9YPK2QpKGkS9 Q/3j8cUOmdsgJhZIZvzpguiQkYxmTV6P88bZVcbv+xMr4spYsUh/mVIIMMc+yQUI i/bxJ3QODQMnhTe22nyYMugS4SFoRy1N4Xj92zx9nID6ZnGXNL+ujCEUa/rVt/SJ 61mGJZvSBDnmbUmEGr9K3Vwa71IJMTS9TTwcejkuYepiMnmSPNW/ihSX6B/xTVft g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=8w9sMeWyX/h6YdjxpuGlLOmOj31+a09DPzanVpZaE 0Y=; b=JKXK+z9zkdX150XDocqB8bBW2qokcqDe58k27lRFh3r6jtw2D3xjsbumc D/qug+YajFujuR6IwCyom4LS7sNa40ia1QlYj9nCCe7aF9nOhYEtWvQZnln7cdZK Ewcy173L/39T/INermnS9tPmk+USFbni59s2TRZr5LuFPbrioYf25lyvnvDAUkNO ZWoxt1l3JvMuhDsHSNKgbW/DSDmm1lRXCzA7PCvtZIBjySQNT/hVy2/qlOPNnTNN Q+VdpouwxGf7vdkGjHJk05syq7SczF+aPGy04cw5h3L3tWZxRrSZG/IZ4v889FYt rW5SozM8ZXvaiANmIHMwAwxMVRghg==
X-ME-Sender: <xms:GVzyXZOLm8iHu922eSphsyy1b96vnJ5LazrqTLlHk-C7e2r1THHdkQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeljedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhi lhhiphhpohesmhhlrdhfihhlihhpphhordhioheqnecuffhomhgrihhnpehrvgguhhgrth drtghomhdpghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfihhl ihhpphhosehmlhdrfhhilhhiphhpohdrihhonecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:GVzyXeRmFcryAhvxdz6FuQ4l5rUxgQmuLs1_x9SuJ8GmKsTmT4VgmA> <xmx:GVzyXX6QtFyuou8n6-0PCISCMJ14GGUabvmjhT4LFSSjC-VkvUYAwA> <xmx:GVzyXd3mQcUMSFOgZVfmWH65FkGI3SeZvWn4-LixNX5sqINf8_vKPg> <xmx:GlzyXV5vo7dhvZATJsmU0IEQKLbt1dLXtZ9P6fuQRf1cF1K1xHKSCA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B069DC200A4; Thu, 12 Dec 2019 10:26:17 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-679-g1f7ccac-fmstable-20191210v1
Mime-Version: 1.0
Message-Id: <8b89d2f0-589d-4019-8d17-2eeac84b0233@www.fastmail.com>
In-Reply-To: <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com>
References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <c4bab542-f1fd-4c80-89b8-1b7a3ef883a7@www.fastmail.com> <CAMfhd9W_+1i=Q48GKAxT=TtHm+fKxUKUepqCtfJ7xQ6LgM4h_w@mail.gmail.com> <CAEMoRCshwo1vsb+bYbJLpOCMWGcJ15sz8COXeXbxmX-KDbY8Mw@mail.gmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <CAF8qwaAHXGWwAswv8XfhjhN3fi7XtVSngLJY8sekYgX+u=wXVA@mail.gmail.com> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com>
Date: Thu, 12 Dec 2019 10:25:55 -0500
From: "Filippo Valsorda" <filippo@ml.filippo.io>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bfrLb-gm2j8crtefS-6LQ9Ir3GQ>
Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 12 Dec 2019 15:26:21 -0000

2019-12-12 06:51 GMT-05:00 Hubert Kario <hkario@redhat.com>om>:
> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote:
> > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara <ilariliusvaara@welho.com>
> > wrote:
> >
> >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
> >>> On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
> >>>> 
> >>>> One test I just tried:
> >>>> 
> >>>> - Smartcard capable of raw RSA.
> >>>> - OpenSC PKCS#11 drivers.
> >>>> - Firefox ESR 68
> >>>> - Server supports TLS 1.3 (Accept RSA PKCS#1v1.5 client signatures is
> >>>>   enabled[2]).
> >>>> 
> >>>> Result: Failed. Client hits internal error code
> >>>> SEC_ERROR_LIBRARY_FAILURE
> >>>> [3].
> >>> 
> >>> That doesn't match my understanding of how NSS works – AFAIK, NSS (and as
> >>> such, Firefox), will try both raw RSA and rsa-pss signatures with the
> >>> token,
> >>> depending on what kind of algorithms the token advertises.
> >>> 
> >>> I think the issue was the old version of OpenSC, new versions can do
> >>> rsa-pss
> >>> with rsa-raw:
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1595626
> >>> https://github.com/OpenSC/OpenSC/pull/1435
> >> 
> >> Ok, upgrading the OpenSC to git master (0.20.0-rc34-2-gee78b0b8) makes
> >> client certificates in TLS 1.3 in Firefox work with that card (works even
> >> if accept RSA PKCS#1v1.5 client signatures is disabled on server side).
> >> 
> >> There is apparently no release with the fix. One needs 0.20-rcX or recent
> >> git master.
> >> 
> >
> > Chrome likewise tries to polyfill PSS support out of raw RSA when the
> > underlying keys support it, but PSS support is still a problem. In
> > particular, I believe TPM 1.2 can neither do RSA-PSS nor polyfill it with
> > raw padding. (Oddly, the spec does reference OAEP, but signing is only
> > PKCS#1 v1.5.) TPM 2.0 can do PSS, but hardware lifecycles are long. Between
> > the negotiation ordering and the client certificate privacy flaw fixed in
> > TLS 1.3, simply saying "no TLS 1.3 for those keys" is problematic. Thus,
> > the draft. It's true that it adds some transitionary codepoints to TLS 1.3,
> > but the point of TLS 1.3 was not switching to PSS. That's a minor bonus on
> > top of *much* more important changes.
> >
> > Most properties negotiated by TLS can be unilaterally updated by the
> > TLS-related components of a system. This is great because it means we can
> > deploy TLS 1.3's improvements. The long-term credentials are one of the big
> > exceptions here and, indeed, we didn't just make TLS 1.3 mandate Ed25519.
> > We wanted to maintain continuity with existing RSA keys, but since it was
> > possible to switch them to RSA-PSS we went ahead and did that. Sadly, it
> > appears that last point can be more true for server keys than client keys.
> > :-(
> 
> If TLS 1.2 was looking insecure, I would be with you on this one. But given
> that TLS 1.2 can be configured to be as secure as TLS 1.3

TLS 1.3 provides privacy for client certificates, which TLS 1.2 does not.

> I think introducing
> weak points to TLS 1.3, weak points we will have to live with for the next
> decade, if not two, is counter-productive and will only delay deployemnt of 
> RSA-PSS capable HSMs.

This draft is only about client authentication, it does not release
pressure from server-side HSMs.

I just had to hold back a Go crypto/tls deployment from TLS 1.3 due to
the same issue that David encountered, so I'd support this draft.

Leaving behind entire client hardware generations is not the same thing
as enforcing progress in software implementations.