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

Ash Wilson <ash.wilson@valimail.com> Tue, 11 May 2021 22:22 UTC

Return-Path: <ash.wilson@valimail.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 BA80A3A28B9 for <tls@ietfa.amsl.com>; Tue, 11 May 2021 15:22:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 2PJoKgtfpuGk for <tls@ietfa.amsl.com>; Tue, 11 May 2021 15:22:18 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 A93063A28B5 for <tls@ietf.org>; Tue, 11 May 2021 15:22:18 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id c20so9448102qkm.3 for <tls@ietf.org>; Tue, 11 May 2021 15:22:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nHc6Ap4z8JKUuYo+PpCZmY/yiZSRGXJGU7JyCabfzvE=; b=eCS6n2lACNpf9HvI8yXIxu4mbH1g09rS9efExKfEgBv7GLE0E8TblVavYSDZMcj2hA 0uzuse0ivlwXiEDjXkJPl84i68JxTH3WdOZ+40EIAokQ5Wvk3CiC6aXAL0mOsJI4w9Ej BysuJEu6H7wVoQSYfYdMyFyn48LsaIMYtmz2FNC62LWTEXx1u7GTdH0eS/nszcC9W6K9 FKJXRd+nTXScsMaImvvLqzM3LsRuKu+X1nLp8MTUD3G0dPac9J14DSimoBKxjUDDGgxQ vvT8pMJVIGDZ6BMqiZCRgKpu5L2s3VK8FR2uWj/DbsTfX2kPfA1HEeJCQMmUaKSezoJa +jJA==
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=nHc6Ap4z8JKUuYo+PpCZmY/yiZSRGXJGU7JyCabfzvE=; b=cnhR6yDhuyCe4rjCyqnA33w7jILJbSXQgHOeBz16POEXeucJYbL9BfEJ8u+GTJF8++ EIAj/0ogbIyFkf7ZEsMyz/SpBKwqsEnwR1jMPS4GGVnBMqXFe24ZtRyDLBjbF919B7eX YfUGpb9TigeYUBjvFQgdk55L6/oQIfFZkEhGY/EoJ+tcuyEq3WnrZzc+wc/1/KMtStwV 1pdSV0Ao0qbxpvsGNW/EXLizvJ/gJs3mBmihLZ6GzgrePzcWAjROY/jtRhswM8subHIf Jzf3KybZYyv576A1HfyeWE/xkREhPWJYfIoReJUYWowgLTTtULOoP2xR6Q7FXFkIzjqi 6Mjg==
X-Gm-Message-State: AOAM530x/lC9qPApd25QdtSu/3pQDsIcTen7iy5uoi/D0/6cYaQ1a6a/ LYu+/JfDbz+/kCM9brs8QN8IA/QjOz544toV2743CQ==
X-Google-Smtp-Source: ABdhPJxcjL8/H+ZOgisUMJIg6LgRLGpPlr/QDV1g79XgrcC37qrZHeC/aoeV1IdG5bnXGlgHtlHX3o1IaEfrqgQOgHs=
X-Received: by 2002:a37:43d4:: with SMTP id q203mr30776272qka.124.1620771736594; Tue, 11 May 2021 15:22:16 -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> <CAEpwuw3nT+4YBj1KTE4+oDMX2f1q-yWHnn6GpdNJDKgvuLKBHA@mail.gmail.com> <CAErg=HFS9W9RvVwf3NCfAjvxbUmNHyfyoatk-Wye4jrNMe-q_w@mail.gmail.com> <CAEpwuw1hETyqfvGikqsN003jbfDvNe4YKT9of0RN4UfHLdjxaQ@mail.gmail.com> <CAEpwuw1Qyq07bgxGZ6-WSJqQLZjT6wTx9-B5oTfKiwJLCtrJmA@mail.gmail.com>
In-Reply-To: <CAEpwuw1Qyq07bgxGZ6-WSJqQLZjT6wTx9-B5oTfKiwJLCtrJmA@mail.gmail.com>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Tue, 11 May 2021 15:22:05 -0700
Message-ID: <CAEfM=vR_0GzrEZ0OQ5HXUDEW5wufYsw+A5A01SnaxnHGpmQrSg@mail.gmail.com>
To: Mohit Sahni <mohit06jan@gmail.com>
Cc: Ryan Sleevi <ryan-ietftls@sleevi.com>, "tls@ietf.org" <tls@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, avamander@gmail.com
Content-Type: multipart/alternative; boundary="0000000000009f3d2205c215533b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I0rEdR4APNuprGI5D1AcdKOw_10>
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: Tue, 11 May 2021 22:22:24 -0000

Hi Mohit,
I'm a little late to the discussion, so all apologies if I'm
missing something...
It looks like what you're going for is the adoption of CT logs as a client
certificate discovery method, to make revocation checks more
straightforward.

A couple of thoughts, for your consideration:

* CT logs can be quite revealing and suppliers may be hesitant to put
device certificates into CT logs. Mining CT logs can signal all sorts of
things about a supplier that they may not want to make public. For
instance, the total number of devices currently in the field, as well as
the frequency of new identity creation, may be useful information to a
competitor. Parsing a CT log would be a really easy way to get that
information.

* If you want discoverability for certificates without making the entire
fleet easy to enumerate, consider the work we're doing in the DANISH BoF (
https://datatracker.ietf.org/wg/danish/about/). We're looking to make
entity and CA certificates discoverable via DNS, for MTLS authentication
and object security use cases. This proposal could make your revocation
checks easier, and it's more performant than querying a hosted CT log. This
can also mitigate naming collisions that can occur when you allow multiple
roots of trust into your application.

-Ash

On Tue, May 11, 2021 at 1:38 PM Mohit Sahni <mohit06jan@gmail.com> wrote:

> Hi All,
> Thanks for providing feedback regarding checking CT for Client
> certificate in MTLS connections, it looks like that we agree to come
> up with specs for this. Further, it should be doable using the
> existing TLS 1.3 protocol without any changes as David and Ryan
> commented. I will write up an Internet-draft and get back to the group
> soon.
>
> Please feel free to share any other use cases you might have for
> validating CT for client certificates in MTLS connections.
>
> Regards,
> Mohit
>
> On Mon, May 10, 2021 at 6:55 PM Mohit Sahni <mohit06jan@gmail.com> wrote:
> >
> > On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <ryan-ietftls@sleevi.com>
> wrote:
> > >
> > >
> > >
> > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <mohit06jan@gmail.com>
> wrote:
> > >>
> > >> On Mon, May 10, 2021 at 8:41 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
> > >>
> > >> I think you misunderstood me, I am not recommending the use of OCSP
> > >> stapling here. I agree with you that the OCSP Stapling is practically
> > >> almost the same as a client fetching the SCT and sending it to the
> > >> server in the TLS stream. I am recommending that the CA/OCSP responder
> > >> can attach SCTs as an OCSP extension along with the revocation status
> > >> of the client certificate in the response to the server's OCSP Request
> > >> and server can verify the certificate based both revocation status and
> > >> the number of SCTs in the OCSP response from the CA/OCSP Responder. I
> > >> know there are issues with how OCSP is implemented by various vendors
> > >> but we can always work on learning from the mistakes and improve OCSP
> > >> to make it more interoperable.
> > >
> > >
> > > In the context of CT implementations, delivering via OCSP means
> delivering via OCSP stapling. This is by design - to ensure everything is
> provided in-band during connection establishment.
> > >
> > > The server fetching an OCSP response and using the SCTs from that is
> no different than if the server simply looked up the certificate in the CT
> Log’s entries: it’s an active dependency on a 3P service during connection
> establishment, which CT intentionally worked to avoid.
> > >
> > > This is why they’re treated as equivalent: in every CT-verifying
> implementation today, OCSP support means stapling.
> >
> > Thanks for the clarification Ryan, now it all makes a lot of sense.
> > Please excuse my ignorance in this regard.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

*Ash Wilson* | Technical Director
*e:* ash.wilson@valimail.com

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.