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

Richard Barnes <rlb@ipv.sx> Mon, 21 October 2019 16:11 UTC

Return-Path: <rlb@ipv.sx>
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 AD7C7120071 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 09:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 5uOyquzW042m for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 09:11:37 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 82AD3120044 for <TLS@ietf.org>; Mon, 21 Oct 2019 09:11:37 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id k32so11497570otc.4 for <TLS@ietf.org>; Mon, 21 Oct 2019 09:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jnD+/urEZJ/XUTnTTNySltheEoDyLlfAH4WnkYE+adU=; b=lzq7BOsr01U85ac5U6DVmH5F5g0yIEoY82kLkYM9gZmtQF8/m0WpyOTuHB+nweyCnt edniLtQvKOzOr1U6mc6a8zxYzJOVD+feffR7sCpcEXmlhGnnlZDK30YG7TVCvgUFWDJ8 SRF/fV9YuLW3oa/U3pL567Sgp6RRbnTdIyCVOssSqRfoSfcxh1yYTfFwM4oyeRug0btW tAS+IWyEsCFyXfv7RRg0HLZ8ljcurfc2HTVB5dWJMgadna5qYOdVEDJJ7Z767A8xekg6 F9v1ovyzKzWj6pbJIzuC1KKqz7yg+HY2BCZZ3sKogpXN6/TVU63uHgNAv1TwSPi3LZU4 I1Dw==
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=jnD+/urEZJ/XUTnTTNySltheEoDyLlfAH4WnkYE+adU=; b=fIWSZjc6R2JRVsOpCUWvV8rYF+Z6kXVrRiRKl0fd1XqfGqJkJVtApFzJ0/ZrlNticg 1I/GSoMF4GAWpUIsueNcwR+hcTQc30ZrMjAo+Bh1klr47Yb9gYwQuVk2OD2YDQoQ5b0j mUvhGrHsdKcdNt+e9goHvDyRwTH1YS5X/3tqkHypE/NAyl/wZGUDjhT8H0nJik6chUKM DdfJr4kxtzyix/o+BRD7uV2FnSij/lHVBIMUz175TF4MgmHUivJkQkCCwgTIywzACfzl eeq+QoOz78b1V0j3OA4rPdyCA6H2dVPNyGfrKLgEBMR+d9R7jpzxlwKiAysrwk9tA+21 otkQ==
X-Gm-Message-State: APjAAAXdOAslWSNTD3c9KWYVMMmO173phPC0UDsfR6j1t8agZ/QB17AE ph2FTXg7ZCqqGXQyv9EnMFEM1q6rF7g7olXTx4nRwA==
X-Google-Smtp-Source: APXvYqyOCknum2L9ZWUJZfKir/W8+A1c4v2r862qhg1FNW0+OXYBH3NgnGudOG5N+PJhE3vkjeU5KC0GQonQIslB4MQ=
X-Received: by 2002:a9d:4613:: with SMTP id y19mr7396075ote.159.1571674296614; Mon, 21 Oct 2019 09:11:36 -0700 (PDT)
MIME-Version: 1.0
References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> <CAF8qwaArxgaKOM-m6ee+DJwn0mfckOt=qc+M7zksec0HR-gLLw@mail.gmail.com>
In-Reply-To: <CAF8qwaArxgaKOM-m6ee+DJwn0mfckOt=qc+M7zksec0HR-gLLw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 21 Oct 2019 12:11:19 -0400
Message-ID: <CAL02cgQC9743xRBk++JhnGxwmNhvUM86sGpae-zPLKUT0VCkzg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Hubert Kario <hkario@redhat.com>, "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027117705956df015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3M5NVGyfIUZSMzgSYsRaAUObiXk>
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:11:40 -0000

On Mon, Oct 21, 2019 at 11:44 AM David Benjamin <davidben@chromium.org>;
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.
>
> 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.
>

I think I agree with both of you here.  Eroding the modernity of TLS 1.3
makes me sad, but the draft does a good job of scoping the change to be
minimal.

The latter points you make here could be stronger in the document.  Where
you talk about the signature_algorithms in the CertificateRequest, you
could also note that if a PKCS#1 signature is received using an algorithm
not in that list, then the server MUST reject it (even though this is
probably duplicative of RFC 8446).  You could probably also say that server
implementations SHOULD disable these code points by default.

--Richard


>
> [*] 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
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>