Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

Ryan Sleevi <ryan-ietftls@sleevi.com> Thu, 21 May 2020 14:12 UTC

Return-Path: <ryan.sleevi@gmail.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 BD2383A0CEC for <tls@ietfa.amsl.com>; Thu, 21 May 2020 07:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 hzpbKbfQkeaI for <tls@ietfa.amsl.com>; Thu, 21 May 2020 07:12:44 -0700 (PDT)
Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 806A73A0CEA for <tls@ietf.org>; Thu, 21 May 2020 07:12:44 -0700 (PDT)
Received: by mail-lj1-f175.google.com with SMTP id b6so8473610ljj.1 for <tls@ietf.org>; Thu, 21 May 2020 07:12:44 -0700 (PDT)
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=WtG2PC0KWy2MFJscB10hFqPgPjx+1J1l1TKftPZftps=; b=h8tcDOspCZimWMOxjBgbvNiGiopZCTOohYQIRNs9AMMDndaO6KCoqZmB52ic5yRRgD iMgtbIXHgCVqFWmt0u0BT6L2Pw7NSfZDC8tlc1FfbWRSUUsoDqQGIjOeqoLuaPZbwbUa mgawBYv19oFlAb0w5bdL62LNsVKGR7Womy7wDUZS25c8KSkrEWKnOVOHUFfDHc8KsKK3 0SW+Fl5zCP79DnUyBySBGMGZvUblyD5I37TG7ut7UMVb5Bsc1Wv1dZ5oLB6qKwgBHdF+ rb7bK9yNfaQ2SOR8U+PpQfCG6KnibjlhMzpRIGbqACEfo/KOFjNZ/tfJPANQQiYEZhnl N5YA==
X-Gm-Message-State: AOAM531Q+dVIuUCjY+yjzbhCO59FT0DSGBM29s7Np1Q9TS8nfJSyKgkm 5vHlbuS1K37ZYcVKiBGQim2IkZWH
X-Google-Smtp-Source: ABdhPJwkVryzAh1kEV03sqNv3EQD84Gl4Qb0fyIyCk/tcJSzsueuQK7boac7lc2jd8ATxWJoYVzExQ==
X-Received: by 2002:a2e:2e08:: with SMTP id u8mr5200707lju.132.1590070362239; Thu, 21 May 2020 07:12:42 -0700 (PDT)
Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id t5sm1812473lff.39.2020.05.21.07.12.41 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 07:12:41 -0700 (PDT)
Received: by mail-lj1-f173.google.com with SMTP id o14so8478038ljp.4 for <tls@ietf.org>; Thu, 21 May 2020 07:12:41 -0700 (PDT)
X-Received: by 2002:a2e:81d1:: with SMTP id s17mr5335079ljg.91.1590070361356; Thu, 21 May 2020 07:12:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoDqtCmkBZYoGT5BaMJN8wgSBFKR00VSUXB9Qu8rDT3S_g@mail.gmail.com> <47A87699-B13C-480B-9C51-2386F1C69D74@vigilsec.com>
In-Reply-To: <47A87699-B13C-480B-9C51-2386F1C69D74@vigilsec.com>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Thu, 21 May 2020 10:12:03 -0400
X-Gmail-Original-Message-ID: <CAErg=HFNMz+JEna8FP6agD_XRuW1u7xavGCByupMJ5A9iDvqaA@mail.gmail.com>
Message-ID: <CAErg=HFNMz+JEna8FP6agD_XRuW1u7xavGCByupMJ5A9iDvqaA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000e7eb005a6291b9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RC5BWPUVwqjSaL768VTiX7VfsbE>
Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07
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, 21 May 2020 14:12:47 -0000

On Wed, May 20, 2020 at 6:40 PM Russ Housley <housley@vigilsec.com> wrote:

> MINOR
>
> Section 1 also says:
>
>    Because the above problems do not relate to the CA's inherent
>    function of validating possession of names, ....
>
> The CA is responsible for confirming that the public key in the
> certificate corresponds to a private key that can be used by the
> certificate subject.  This is usually done by a proof of possession
> mechanism.  So, I think that the start of this sentence should be
> reworded to avoid the impression that the CA only validates the
> name.
>

The existing framing is correct. The most widely used Internet PKI, the Web
PKI, intentionally doesn’t not require a proof of possession mechanism. It
is not used as an authentication mechanism (i.e. a binding of a key to an
identity) but an authorization mechanism (i.e. a binding of an authorized
set of identities to a key).

The “CA only validates the name” is not just an impression, it’s the
widespread running code. Due to how TLS certificates are used (online
protocol negotiation, without non-repudiation support), there’s no risk
opened nor any necessity to do a strong proof of possession binding, even
in cases of strong identity binding.

QUESTION
>
> While I have no objection to the DelegationUsage extension,
> I wonder is an extended key usage would provide the same
> confidence in the certificate.
>

In practice, no. As things currently are, it would unfortunately undermine
the confidence, although this an entirely fair and reasonable question.

As a recap (and more for those without the same context you have) the way
5280 and it’s predecessors were designed, the Certificate Policies
extension is the primary means of expressing or indicating compliance to a
particular policy. If a relying party explicitly attempts to validate a
certificate, for a RP-determined Certificate Policy, then they can know
whether or not that certificate complied with their expectations for
issuance and management. This is all defined within 5280, albeit quite
complex, and involves processing rules for both leaves and intermediates,
as well as the ability to map between different policies (via
policyMappings), such that an RP expecting policy A can validate a
certificate bearing only policy B, provided some trusted party in the
certification path asserted that B was equal-or-equivalent-to A

Additionally, certificates have the extendedKeyUsage, which is most
commonly used to restrict the protocol or protocols a given certificate can
be used for. In RFC 5280 and friends, this restriction only applies to lead
certificates. However, from the very earliest days of PKIX, the two main
implementations (Microsoft and Netscape) diverged from this, in unspecified
ways that ultimately PKIX declined to incorporate, to allow EKUs to be used
on intermediates to restrict the protocols that certificates can be issued
for. If a leaf EKU is not a subset of its issuing chain, then that EKU is
not permitted; much like policy OIDs.

This divergence, which has existed since the very earliest days of TLS,
resulted in a different approach to managing policy than the idealized goal
of PKIX. Rather than having every relying party application provide an
initial policy, such as a policy OID assigned by the root store vendor
(typically the OS/browser vendor), to indicate compliance with the root
store’s policy, and using policy mappings for that, implementations simply
used the EKU as a joint indicator for “uses protocol X and complies with
the issuance policies for protocol X, as defined by the root store vendor”.

This whole long preamble builds to our present day. In wide practice, and
even for those root stores/OSes/applications that do not implement EKU
chaining in the fashion mentioned above, the mere presence of an EKU is the
indicator for compliance with a set of policies, and altering EKUs, like
altering policy OIDs, requires issuing new intermediates permitted for that
EKU.

If DC certificates only bore a DC EKU, they would, in effect, be exempt
from all of the certificate policies widely practiced for the issuance of
TLS certificates, which would reduce the confidence in the certificate.
They would also typically require the CA to issue new intermediate
certificates prior to being able to issue such certificates that were
accepted. For applications, the certificate validation libraries apply
local policy to certificates based on their EKU via technical measures, to
ensure they match the expected issuance policy, such as checking for
certificate transparency information or limiting the maximum validity
period the application will accept.

Recall that the design of DC is also possible via simply nameConstrained
subCAs, but part of the reason for DC is that it does not require or
reduces dependencies on external PKIs in order to satisfy local protocol
needs. The same argument applies here against EKU: to use EKU would place
ongoing dependencies back on those external PKI, be incompatible with how
those PKIs are typically administered, and would cause significant
challenges for applications implementing on common libraries (such as those
provided by their OS).

It’s far from perfect, but the current state of the art is this approach.
If something is meant to be “like” TLS, at minimum, it needs to contain the
TLS EKU, so it is subjected to the TLS policies and usable with TLS
validation stacks. Extensions, with or without the critical bit set, serve
as the way to distinguish whether and how it should be usable with TLS and
the “something like TLS” protocol.

An EKU certainly could be pursued, and it’s by no means an unreasonable
question, but in order to provide the same confidence as currently
specified, existing root store policies would need to be rewritten and
redefined to include that EKU in scope of their “subject to TLS”, as would
their software and validation libraries similarly be updated to process
that.