Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
Hubert Kario <hkario@redhat.com> Mon, 21 October 2019 16:13 UTC
Return-Path: <hkario@redhat.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 09BE1120089 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 09:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 1HC3ShqoCymc for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 09:13:25 -0700 (PDT)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF310120071 for <tls@ietf.org>; Mon, 21 Oct 2019 09:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571674404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=35hqzeWe1aLa6HYCPOVgYvmha60FAtpIkInDxk8ohd4=; b=h4QvzzZY/C0MVLUZ/QGuES30m1rnZPMTIpLW2iPxCcV9BdJEtKbq1OBfuLewNTaq8PdNzH yOxel4rIq7Eaj+vnPgoWCZi1YTuKQeBgWUX4mo9Y63867FBhETahOcAhYCGVvBYfcmx1B4 y48dpZmKG4k9djcSogvcdjIglVlZ4co=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-qnK0SeKrN6OZdMPEDKf3sA-1; Mon, 21 Oct 2019 12:13:18 -0400
X-MC-Unique: qnK0SeKrN6OZdMPEDKf3sA-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1DC61800D79; Mon, 21 Oct 2019 16:13:17 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE95E6012D; Mon, 21 Oct 2019 16:13:16 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Date: Mon, 21 Oct 2019 18:13:10 +0200
Message-ID: <2346333.Tok7fK9tdU@pintsize.usersys.redhat.com>
In-Reply-To: <CAF8qwaArxgaKOM-m6ee+DJwn0mfckOt=qc+M7zksec0HR-gLLw@mail.gmail.com>
References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> <CAF8qwaArxgaKOM-m6ee+DJwn0mfckOt=qc+M7zksec0HR-gLLw@mail.gmail.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Mimecast-Spam-Score: 0
Content-Type: multipart/signed; boundary="nextPart3659103.3jaaIzUkP6"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5AYFmBuqvY6hh_8JTt6L7ZsCTqE>
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: Mon, 21 Oct 2019 16:13:28 -0000
On Monday, 21 October 2019 17:43:52 CEST David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario <hkario@redhat.com> wrote: > > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > > > > > which can be found here: > > > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > > > > > It will run until November 1, 2019. Please indicate whether or not you > > > > would > > > > > like to see this draft adopted and whether you will review and provide > > > feedback on it going forward. > > > > Yes, requiring RSA-PSS causes interoperability issues with smartcards that > > don't implement this 16 year old algorithm. But being able to say "if > > you're > > using TLS 1.3 that means you are not using legacy crypto" has non > > insignificant value too. > > > > This document erodes that. > > The document goes into the rationale here under Security Considerations. > I'm unhappy about this too, but our experience is that devices without PSS > support are fairly common in client certificates. The negotiation order > means that accounting for such devices effectively means servers hold back > TLS 1.3 for *all* their clients, not just those that are affected. > Additionally, even if one could get the negotiation order correct, TLS 1.3 > fixes a serious privacy leak with client certificates. Keeping those > clients on TLS 1.2 means they continue to leak their identity over the > network. yes, I've read it. 1. I don't expect that heterogeneous deployments of clients (where some smartcards can do RSA-PSS and some can't) will be a significant portion, let alone the majority, of deployments. 2. servers that do use client certificates for authentication are not generally deployed for the public, on the internet. Those are closed systems, so impact for publicly facing servers is minimal if they need to downgrade to TLS 1.2. 3. while client certificate authentication /may/ leak client certificates in plaintext in TLS 1.2, by sending them in initial handshake, is not the only configuration that provides certificate based authentication. Adding client certificates through renegotiation does not leak them and is fairly common deployment model. > To mitigate the second-order effects, the document intentionally makes the > code points client-only (the above motivations don't apply for server > keys), as well as allocating separate code points from the existing PKCS#1 > values. If a client or server wishes to not use[*] PKCS#1 signatures in TLS > 1.3, it doesn't need to advertise/accept those code points. TLS libraries > probably should also disable them by default. yes, that's a very good part of this i-d (I will suggest making the language around it more strict than it is now, if the i-d is adopted), but the problem I have is that they are allowed at all, as that means the legacy hardware is given another decade if not two to get replaced Having configurations that need to downgrade to TLS 1.2 for interoperability is a good thing because it raises obvious red flags during audits. Algorithms advertised by server in CertificateVerify are not an obvious red flag. > Given all that, I think adding code points for deployments that need them > is the right tradeoff. > > [*] PKCS#1 signatures in certificates and the downgrade-sensitivity of the > TLS 1.2 signature aside. > > > So I'm against adoption of this draft by the WG. > > > > If it is adopted, I will review and provide feedback on it. > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > > Republic_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [TLS] Adoption call for draft-davidben-tls13-pkcs1 Christopher Wood
- Re: [TLS] Adoption call for draft-davidben-tls13-… Salz, Rich
- Re: [TLS] Adoption call for draft-davidben-tls13-… David Benjamin
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… David Benjamin
- Re: [TLS] Adoption call for draft-davidben-tls13-… Richard Barnes
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… David Benjamin
- Re: [TLS] Adoption call for draft-davidben-tls13-… Sean Turner
- Re: [TLS] Adoption call for draft-davidben-tls13-… Christopher Wood
- Re: [TLS] Adoption call for draft-davidben-tls13-… Adam Langley
- Re: [TLS] Adoption call for draft-davidben-tls13-… Darin Pettis
- Re: [TLS] Adoption call for draft-davidben-tls13-… Ilari Liusvaara
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… Ilari Liusvaara
- Re: [TLS] Adoption call for draft-davidben-tls13-… David Benjamin
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… Filippo Valsorda
- Re: [TLS] Adoption call for draft-davidben-tls13-… Ryan Sleevi
- Re: [TLS] Adoption call for draft-davidben-tls13-… David Benjamin
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario
- Re: [TLS] Adoption call for draft-davidben-tls13-… Nick Harper
- Re: [TLS] Adoption call for draft-davidben-tls13-… Hubert Kario