IETF Logo Mail Archive

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

David Benjamin <davidben@chromium.org> Mon, 21 October 2019 15:44 UTC

Return-Path: <davidben@google.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 9D10712009E for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 08:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Level:
X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 VnEjwpbzQ6I2 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 08:44:09 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 B3061120098 for <TLS@ietf.org>; Mon, 21 Oct 2019 08:44:09 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id d22so6808907pll.7 for <TLS@ietf.org>; Mon, 21 Oct 2019 08:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q9FBzYwm8I5OsfZWGzyq1h+sOK+FtqD8528yiQnCR+o=; b=m7dux5EvsLcwmL3vARboXwvX1AInxHt4bik7rpza4FBzNexnhBIy+SdNsjtqAq2EGJ QfahGOKdzQrT6zvl09NHt57h4nF7Nuv10Bt/ZdiKStcp9v9TE5tM6A/sTMkjB3509ZiK sEkO5oJnkSa7WlxxiZ2V/CajnI0mvNo2i7EqU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q9FBzYwm8I5OsfZWGzyq1h+sOK+FtqD8528yiQnCR+o=; b=igDNGFqhAHY3MqXTDGpF58IE4dTqIBXzcvKc8eXSmvaI3pIigV44dRqedfBLiuFcjL Khn9b4y7IUb+JB3cTddWKy2tBqx9MCLFZ68tkbNG7lZqWr8ilemQSO7RXPIG6MdxV/iC L795VoGSAVyzeBzRQcT+n9crRJsT6ywyKJ/cjjXhTazNDjnKqPgd56F9J6a2NQfIS17Z VtCxdGfvJxuPcYgWV3ntuKXEUDJ6ViXNBsBkCJxzAe4SyHJnBhdCpCA3GbtidYOSSWa7 +W5Q9t3LIjcC0SURu/kZl1gR6TUKFeMhYdVlClMmdGTexJHv1Ap4W3h8JW9bfWJj7pfi cEYA==
X-Gm-Message-State: APjAAAX2/Q2Dc503AgIeeu+sEXXw3nC0Ou3joVl+NLXR5VyA+/52EYe8 1yw6jv29GEvmI90rS7tWR6U6JUl92Gl55w8LGdYb
X-Google-Smtp-Source: APXvYqxSEZBNjbj4HN7XtgsMctA/gu4ty71sQ7QisYVtaoKeTfL6VvHt7vsi/o00YXu7qFRy/ioXvbsvBBUJQSdfMnk=
X-Received: by 2002:a17:902:9a41:: with SMTP id x1mr24910148plv.331.1571672648833; Mon, 21 Oct 2019 08:44:08 -0700 (PDT)
MIME-Version: 1.0
References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com>
In-Reply-To: <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 21 Oct 2019 11:43:52 -0400
Message-ID: <CAF8qwaArxgaKOM-m6ee+DJwn0mfckOt=qc+M7zksec0HR-gLLw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0918805956d8dc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eKGAv45gP_OVMwON2O22lhbtiWE>
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 15:44:12 -0000

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.

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.

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
>

v2.23.0 | Report a Bug | By Email