Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake

David Benjamin <davidben@chromium.org> Mon, 10 May 2021 16:55 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 22CA23A23A6 for <tls@ietfa.amsl.com>; Mon, 10 May 2021 09:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.946
X-Spam-Level:
X-Spam-Status: No, score=-9.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 udfH-O3fI5pj for <tls@ietfa.amsl.com>; Mon, 10 May 2021 09:55:01 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 263343A238C for <tls@ietf.org>; Mon, 10 May 2021 09:55:00 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id fa21-20020a17090af0d5b0290157eb6b590fso10699030pjb.5 for <tls@ietf.org>; Mon, 10 May 2021 09:55:00 -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=9PC44iWURIBUecBgXyR+XCy/+WAOaRB81CJqHgyVUUc=; b=dZNINfpD30DGxbVwaUOCTrsdQVoYnop8UPDUrQYqFAIPB7VZFHSGURu7qfPJnvArpI Uxh2quKobpzlwpuDA+VJUlayha9p0Zc97vmhA66ydXR62gc/jSQx3kFr92YRpFEjhBaQ pwT/oPPI9JQKOJZdegEg19qg8aYh4rFI+jDms=
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=9PC44iWURIBUecBgXyR+XCy/+WAOaRB81CJqHgyVUUc=; b=FB/4TCb+J8yPiH5sW0HdQ7yD8yndgUQaJus33J+PnIBGi1X0jP16cw75etaGyx3vuq kzhot1SlMib9G9ntCAJRVL50gAD4X7cr7k1XPTJam5iOlBdmA9Z5CkApfcjbhwKqTxEZ GIqsVyKNVy+2rNWnPmqcUa3zPeNVk6B9QGGZCjAQ4VU6S+tbxjytYkYbWlkIKrHTbOrn 0gbTrAUQgKATaUNNT5SvI7804D1fFFraYlWCiWysSjW35vN4QHhf2ldSZnfT+11LdDQ7 SZxyL5bBKrrJMyfc+fudJ6PgT3xxHpIvguIGTKPmIzh5q6fd+aXn7DFtUKJclkFLySwE RVUw==
X-Gm-Message-State: AOAM533l1/Oq+Bj5N+gvQgYcGvA6H4fd8HakM1pQ+jiIOS36bZOEWat4 X+Mqcm9fSyj+ms9Ms/JajFo8Y0+cve8LwjEwrPuEV6NMuQ==
X-Google-Smtp-Source: ABdhPJxK5qaM1uoHjkaou3U+VJ67gG7rRFgristL2+Py6YRI1Vpd0PPXmuuCK/w8LmE304FeEBqWQIz2/HZjeRa0YU0=
X-Received: by 2002:a17:902:b7c8:b029:ed:2577:8dc3 with SMTP id v8-20020a170902b7c8b02900ed25778dc3mr25201924plz.9.1620665699313; Mon, 10 May 2021 09:54:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAEpwuw2tBLn-7b1YBXf3YfS4WXM-JrKbfHsQPt=_H4FYKYdmVQ@mail.gmail.com> <CAErg=HHmM649hqqb2xrqnE2YM2Ks88dOT-FRkmGmMcyjL88Fxw@mail.gmail.com> <CAEpwuw3mzdGt7UWJF7o4Z+ShgPJ4_0todsV56QENBZOv2hwJqQ@mail.gmail.com> <CAErg=HHUGXJv0kEj5cNUWsxfBT745o9zWpt5MOUcdDddwOxbag@mail.gmail.com>
In-Reply-To: <CAErg=HHUGXJv0kEj5cNUWsxfBT745o9zWpt5MOUcdDddwOxbag@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 10 May 2021 12:54:43 -0400
Message-ID: <CAF8qwaCbg54E=G3CK+zKZ+j6g8N9W1zBPJ+0KPLrQ0U61jYDkw@mail.gmail.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
Cc: Mohit Sahni <mohit06jan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f13f905c1fca385"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q2bxjPUqOG80M0vPGVEEfxRJTro>
Subject: Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
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, 10 May 2021 16:55:17 -0000

Mechanically on the TLS side, we already aligned the client and server
certificate flows in TLS 1.3. TLS 1.3 already
allows signed_certificate_timestamp in the CertificateRequest message. So
basically what you said in Approach 1, except there's no need for the
server to condition the CertificateRequest extension on a ClientHello
extension. The ClientHello -> (server)Certificate and CertificateRequest ->
(client)Certificate flows happen independently. Same with status_request
for OCSP. So I don't believe you need any TLS protocol changes here.

Of course, that is purely about where to stick the bytes in TLS. Whether
and how to use those bytes in your organization's private
client-certificate-specific PKI is a more complex question and I'll defer
to what others have said on the thread here.

On Mon, May 10, 2021 at 11:42 AM Ryan Sleevi <ryan-ietftls@sleevi.com>
wrote:

>
>
> On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <mohit06jan@gmail.com> wrote:
>
>> Hi Ryan,
>> Thanks for answering my question in a lot of detail. I asked this
>> question in the context of a private PKI for client certificates. You
>> can assume a scenario where the client certificates are issued to
>> users/devices in an organization from a self service portal by the
>> organization's existing private PKI for 1000s of users under different
>> domains (multiple CAs).
>>
>> What I get from your answer is that using CT for client certificates
>> makes sense when:
>>
>> 1) There is an existing private PKI.
>> 2) There are multiple CAs issuing the client certificates.
>> 3) The PKI uses non Web PKI (non public) CT log servers and auditors.
>>
>> I don't agree with your comment about following the same priority
>> preferences that exist for server certificates, the [2] and [3] makes
>> more sense when reversed or kept at an equal priority in the context
>> of client certificates. Here is my reasoning:
>> In the server PKI, it is practically easier to make changes in the web
>> servers to support [2]  (i.e. sending the SCT extension by pre
>> fetching the data from the CA) but it may not be that easier to
>> implement it on 100s of thousands of client devices. Imagine a large
>> cell phone manufacturer implementing [2] for all the devices that they
>> have sold in the last 10 years.
>>
>
> Right, I can understand the temptation to consider OCSP Stapling as a more
> attractive solution, because it relies on the CA taking the requisite
> action, and thus avoids the need for client implementation, in theory. But
> the problem is that it's largely "in theory" - that is, robust OCSP
> stapling is just as hard for clients to implement as obtaining SCTs
> directly.
>
> Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling
> looks like, from the server side, which captures some of the challenges
> here. Few servers robustly support this (I believe Microsoft IIS and the
> Caddy web server are the two notable exceptions), and so the idea of
> pushing that all to clients is roughly the same challenge as having clients
> obtain SCTs directly. The main argument for OCSP-embedding over
> TLS-embedding is not one of simplicity, but of centralized control and
> communication: the idea being that you can have all your clients contact a
> single point of contact (the CA's OCSP responder) to obtain the policy.
>
> For servers, in the context of the Web PKI, it's quite appealing to swap
> priority for OCSP-embedding over TLS-embedding because of this. It equally
> gives Web PKI CT Logs a single point of contact for purposes like rate
> limiting and abuse detection, which can make it easier to address any
> concerns. However, in the threat model of "Unreliable CA", where CAs
> continue to fail to implement CT correctly [2][3], that seems to be missing
> the operational lessons. Given the assumption that the model here was
> private PKI with private CT logs, then you're likely better off with a
> (privately expressed) policy mechanism on the client versus trying to
> robustly support OCSP stapling on clients, since the failure mode here
> impacts not only CT, but the revocation processing.
>
> [1] https://gist.github.com/sleevi/5efe9ef98961ecfb4da8
> [2] https://sslmate.com/blog/post/apples_new_ct_policy
> [3]
> https://www.hardenize.com/blog/certificate-transparency-policies-diverge-with-apples-update
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>