Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt
Nick Sullivan <nick@cloudflare.com> Wed, 19 February 2020 20:11 UTC
Return-Path: <nick@cloudflare.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 152491201E3 for <tls@ietfa.amsl.com>; Wed, 19 Feb 2020 12:11:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.758
X-Spam-Level:
X-Spam-Status: No, score=-0.758 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, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, 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=cloudflare.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 d8p5nla0XAL0 for <tls@ietfa.amsl.com>; Wed, 19 Feb 2020 12:11:13 -0800 (PST)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 228AF12016E for <tls@ietf.org>; Wed, 19 Feb 2020 12:11:13 -0800 (PST)
Received: by mail-ua1-x934.google.com with SMTP id 1so707823uao.1 for <tls@ietf.org>; Wed, 19 Feb 2020 12:11:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QlwHCa3S2n/dTUNM8AaG9bJYhJ4ebkBkoUmGCbB4v+I=; b=jFB8O0BmfCYSfayiIDMOxddi8E+AzQ61KrIfLg3RlQAyFgIJcqqXN+O6Rq7ES1ltEa oqZ9tsyawzni56yppkFhbIVs2Cg2pV8wxMMnF+iHlM0qpA39WDu+ajk7NWdK3KrdwGeh i1yYzfyzDaWSzAMJoppVsuek7UYGPDhk0sTh8=
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=QlwHCa3S2n/dTUNM8AaG9bJYhJ4ebkBkoUmGCbB4v+I=; b=Krs9JErByR0TMIKQP5AuI9dlqacGTUJiX9TKIaW8D+0FJMz3lWLAs9R2TkBTqtKbyV r8/vipGJziNmHPuy22gVNikC5iTv2C5K6h0Cz7g4QjhhIoU3res39rq9nVb4BzLcsg4f 5A/1Wk+orXGovY2rU3M7krV9J7Wp0cC8REWHFwKR67ciXZRrenPVLl7gMKK1kTuofsFU 19I3DM5G5Di+SM7jYLvgHxYuqCs7R2xj4lMmaZ7IY1cWQrLO90zZz/oUuCYhfSaXFief hJ5pvVT6bWmKQBgCdp4Z8fYcNGF2qMzkAzC0z9aPRzh5k2lS4GnjU25R6xuv08TyYCgm TM0g==
X-Gm-Message-State: APjAAAVQ6BxAuN1X9tzqbuZtrdj7HnlX0IWlr1vWvAXgnktQMYQxPyhx Kg7WxvVGeVJdj5FwOBX7fFmXZkzPHbpxTzVRGR2ekw==
X-Google-Smtp-Source: APXvYqx38kKhFELxu8FxSdKDw/P8lfYCWjAUJ7sVk9Bea6nLyyKu02Cu7YK0Bu3YPRefxYhBX9ywJUGYz+xpcQI9ab0=
X-Received: by 2002:ab0:7025:: with SMTP id u5mr14232372ual.52.1582143071951; Wed, 19 Feb 2020 12:11:11 -0800 (PST)
MIME-Version: 1.0
References: <158093501262.12877.10966121264461280401@ietfa.amsl.com> <20200209140242.GA1489626@LK-Perkele-VII> <CAFDDyk_VTbe5CQG1A_d=eQtp-uK+-vHOm_HwMp6AePbMPakDOA@mail.gmail.com> <20200215085529.GA1659089@LK-Perkele-VII>
In-Reply-To: <20200215085529.GA1659089@LK-Perkele-VII>
From: Nick Sullivan <nick@cloudflare.com>
Date: Wed, 19 Feb 2020 12:09:39 -0800
Message-ID: <CAFDDyk_w8GaHpmfHUJjgppk_gXW4ar0D-o-mqfGg7WK+tX2JBg@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c9ce41059ef3637f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fNvnLYzEzsm4i12yoYEMC2qr3XU>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt
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: Wed, 19 Feb 2020 20:11:16 -0000
Good catches on the section number and server/client questions. Confirming below. Here's a PR with the proposed change: https://github.com/tlswg/tls-subcerts/pull/54 On Sat, Feb 15, 2020 at 12:55 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wrote: > > Ilari, > > > > Thank you for identifying these errors in the document. There was no > > intention to allow the client to constrict the server certificate's > > algorithm with the delegated_credential extension, and no intention to > > restrict the delegated credential's algorithm with the > > signature_algorithms. Let me propose some minor text changes to address > the > > issues. > > > > As a reminder, the CertificateVerify.algorithm is constrained by the > > signature_algorithms > > extension, as stated in RFC 8446: > > > > If the CertificateVerify message is sent by a server, the signature > > algorithm MUST be one offered in the client's "signature_algorithms" > > extension unless no valid certificate chain can be produced without > > unsupported algorithms (see Section 4.2.3 > > <https://tools.ietf.org/html/rfc8446#section-4.2.3>). > > > > > > > > Original text from 4.1.2.: > > > > The expected_cert_verify_algorithm fields MUST be of a > > type advertised by the client in the SignatureSchemeList and are > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > > > > > proposed text: > > > > The expected_cert_verify_algorithm field MUST be of a > > type advertised by the client in the SignatureSchemeList and is > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > The section number looks incorrect (it is about client authentication) > and the original looks to be copied from the new text. Did you mean > section 4.1.1 (Server authentication) and: > > OLD: > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > type advertised by the client in the SignatureSchemeList and are > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > NEW: > > The expected_cert_verify_algorithm field MUST be of a > type advertised by the client in the SignatureSchemeList and is > considered invalid otherwise. Clients that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. > > Yes, 4.1.1. I'll put this into a PR. > > > As for the second point, we did not add the capability for the server to > > advertise a different set of signature_algorithms for client > authentication > > other than the one advertised via the "signature_algorithms" extension. > > This was perhaps an oversight. I propose that we add that capability and > > I'd be happy to propose a PR to that effect. > > > > The new text of 4.3.2. would look something like: > > > > A server which supports this specification SHALL send an > > "delegated_credential" extension in the CertificateRequest message > > when requesting client authentication. The body of the > > extension consists of a SignatureSchemeList. If the server receives a > > delegated credential without indicating support in its > > CertificateRequest, then the server MUST abort with an > > "unexpected_message" alert. > > > > ... > > > > The algorithm field MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > of the CertificateRequest message and the > expected_cert_verify_algorithm > > field MUST be of a type advertised by the client in the > SignatureSchemeList > > and considered invalid otherwise. Clients that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > > > There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean > section 4.1.2 (Client authentication)? Yes, 4.1.2 is the right section. > The latter proposed paragraph > seems like it says "client" in two places it should say "server", did you > mean: > > The algorithm field MUST be of a > type advertised by the server in the "signature_algorithms" extension > of the CertificateRequest message and the expected_cert_verify_algorithm > field MUST be of a type advertised by the server in the > SignatureSchemeList > and considered invalid otherwise. Servers that receive invalid > delegated credentials MUST terminate the connection with an > "illegal_parameter" alert. > Yes, that's correct. > > > > -Ilari >
- [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Ilari Liusvaara
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Watson Ladd
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Carrick Bartle
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Nick Sullivan
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Nick Sullivan
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Carrick Bartle
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Ilari Liusvaara
- Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.… Nick Sullivan