From nobody Tue Jun 14 20:14:32 2022 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D27C157908; Tue, 14 Jun 2022 20:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpzLX1iAx9q8; Tue, 14 Jun 2022 20:14:27 -0700 (PDT) Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960BEC147921; Tue, 14 Jun 2022 20:14:27 -0700 (PDT) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-30fa61b1a83so49075017b3.0; Tue, 14 Jun 2022 20:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k47WPxfK52WQvRcF/6EfVftivAKEY6X0D43DDvtWeAI=; b=3V9pCyNB7abBllId0Qr0icrG3W678KfU2kHIQ4vPwtVDke0xSovwWM5q1kI9poIABC s9JEQlEc/nxrc5CNamnQYnfbpAc9C8f450NVB4DsHkdSi/Uk87PGdtQonktPgz0AZbH9 d/WTiAzlgB6klGoTh+IiNlxpv/1d00uOycmtMc6GlSi2dLqH4zFh19QqSK9tqYGKX4/M 33Lo/w2596DSXjwlbiVOYmAmJYjRWgNqiuIi/OT5T6fRvQLKX8TtkMNh7R1g9m6iaNwv WDJC/wjTZ/yWOjKOzzYmXCr9qBLmO5NceoEPj6gnrA+b/PTX5B5m7e0+Hi7cZgBsnVmo k0Yg== X-Gm-Message-State: AJIora+GGqoowAJXxeOUwTDxr4MpVUFymu6U3bhSIFhXhJLIHo8lCNxZ dBSv52jG5nL7pePsIUUX3uuuLFiAR6Q29r2/zqQ7D6koRC/TyA== X-Google-Smtp-Source: AGRyM1tQ9KUfchYxGhhpEhCyIcs1eXw5Jj5rDEv3T0msTYoqW3fyEO5Owp071p2UcSQ73JO48lDSzb1ijf7Y6Y5HUr4= X-Received: by 2002:a81:5784:0:b0:313:7c98:d6bb with SMTP id l126-20020a815784000000b003137c98d6bbmr9145278ywb.213.1655262866704; Tue, 14 Jun 2022 20:14:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 14 Jun 2022 23:14:15 -0400 Message-ID: To: Mike Ounsworth Cc: SPASM , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002e0f3805e173eb65" Archived-At: Subject: Re: [lamps] [EXTERNAL] Distinguished names for self certified TLS client authj X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2022 03:14:31 -0000 --0000000000002e0f3805e173eb65 Content-Type: text/plain; charset="UTF-8" Hmm... looks like this is a piece of brokenness in the browsers. I see this as a two step thing. First there is 'getting it to work in the legacy browsers' and then there is 'doing it the right way'. For the second step, I have actually written my own browser (yes really) and one of the goals of that work is precisely so that I can control the privacy etc. profiles and show how I think it can be done right. The idea of the client cert selection extension was to avoid the need for that cert selector extension. But as the article points out... privacy hole! Ooops. What does Firefox do if a server specifies a list of client cert DNs that only matches a single cert? The goal was to avoid the need for the selection box. But we definitely need that 'do you want to send a cert' dialog. My plan for Phill's Hypothetical Browser is to allow users to specify site profiles and apply their own security policies to them. So Alice has 3 machines A, B and C. She wants to have a seamless experience across all of these. So log into the NYT on A and she will automatically log in on B. Alice uses a number of different sites X, Y, Z are sites she uses for work and it is important TO ALICE that the site X knows that she is the same Alice who is doing something on site Y. P, Q, R are random Websites that Alice uses but she certainly does not want P to know that she also uses site Q. So my plan here is that Alice can declare security policies 'Work' and 'Pseudonymous' so that context is shared between X, Y, Z but P and Q and R are each isolated with entirely separate cache and cookie settings. For investigation work, I would also want to be able to specify that a site be accessed through a forensic proxy, for personal privacy I might bounce requests to different sites off different proxies. So for my extreme privacy browser, I can specify that a site should use a shared certificate as specified by the security label applied to that site or a site specific certificate to prevent linkage. The github is here: https://github.com/hallambaker/PhillsHypotheticalBrowser My thanks to the Microsoft WebView2 team for making this possible. On Tue, Jun 14, 2022 at 4:44 PM Mike Ounsworth wrote: > Hi Phillip, > > What clients are you trying to use this with? Browsers? This almost feels > like a user-agent question: "What CA DN do you want the server to prompt > for so that you put up the right certs in the popup?". Is there a CA DN > that you can specify that will cause FF / Chrome to show the user all their > loaded certs? > > Note: back in 2018 I was fiddling around with this for a stackexchange > question and found that (by default) Firefox politely waits for you to > select a client cert from the popup, whereas Chrome just starts spamming > client certs at the server until it accepts one. I feel like user-agent > behaviour is going to affect the viability of your idea here. > > https://security.stackexchange.com/a/199518/61443 > > --- > Mike Ounsworth > Software Security Architect, Entrust > > From: Spasm On Behalf Of Phillip Hallam-Baker > Sent: June 14, 2022 2:58 PM > To: SPASM ; tls@ietf.org > Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS > client authj > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > ________________________________________ > [Yes, I am aware of the FIDO work and it is a completely different use > case, does not apply to non web applications. TLS Client Auth is an IETF > spec and thus within IETF scope.] > > I have an infrastructure that makes private key management really simple > for end users. They can manage private keys across devices without being > aware they are doing it. This technology has obvious applications for > existing public key authentication schemes including EAP, FIDO and TLS > Client Auth. > > When looking at TLS client auth it seems to me that it is much closer to > being a viable replacement for some uses of passwords than experience leads > us to believe. In particular, I have maybe 5 accounts I might use a > hardware token to secure but I have several hundred Web accounts that all > use the same password because when it's not my asset and I am not being > paid, I don't use my brain power to remember the password. > > So my basic idea here is that Alice connects all her devices to her > personal Mesh and they are automatically provisioned with a device specific > cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn > being (optionally) credentialed under Alice's personal Mesh via an > extension if the goal is to establish that the 'Alice' visiting site A is > the same as the Alice visiting site B. For cases where we want to prevent > linkage, we develop a separate CA per site. > > This is not how PKIX is intended to work of course. But the deployed > infrastructure supports PKIX and so that is the framework we have to work > within. > > > Looking at how TLS Client Auth works as deployed, a server sends a message > back to a client saying 'client certificate required' and a list of > distinguished names of CAs it will accept. > > So what I want to know is not 'should I do this', but 'what is the string > I should send when I do'. That is, this is something I am planning to do > and so I am asking what approach is least likely to have unintended effects. > > I see a need for two distinguished names: > > A) 'Self signed CA speaking to any relying party' > B) 'Self signed CA speaking to a specific relying party' > > The server is going to check the certificate chain itself on the other end > of course. > > > And again, yes, I do fully understand the limitations of transport layer > client auth. That is why I make use of my own authentication layer for Web > Service transactions. > > Any email and files/attachments transmitted with it are confidential and > are intended solely for the use of the individual or entity to whom they > are addressed. If this message has been sent to you in error, you must not > copy, distribute or disclose of the information it contains. Please notify > Entrust immediately and delete the message from your system. > --0000000000002e0f3805e173eb65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm... looks like this is a piece of brokenn= ess in the browsers.

I se= e this as a two step thing. First there is 'getting it to work in the l= egacy browsers' and then there is 'doing it the right way'.
=


For the second step, I have actual= ly written my own browser (yes really) and one of the goals of that work is= precisely so that I can control the privacy etc. profiles and show how I t= hink it can be done right.

The idea of the client cert selection extension was to avoid the need for= that cert selector extension. But as the article points out... privacy hol= e! Ooops. What does Firefox do if a server specifies a list of client cert = DNs that only matches a single cert? The goal was to avoid the need for the= selection box. But we definitely need that 'do you want to send a cert= ' dialog.
<= br>

<= div class=3D"gmail_default" style=3D"font-size:small">My plan for Phill'= ;s Hypothetical Browser is to allow users to specify site profiles and appl= y their own security policies to them.

So Alice has 3 machines A, B and C. She wants to have a seaml= ess experience across all of these. So log into the NYT on A and she will a= utomatically log in on B.

Alice uses a number of different sites

X, Y, Z are sites she uses for work and it is important TO A= LICE that the site X knows that she is the same Alice who is doing somethin= g on site Y.
P,= Q, R are random Websites=C2=A0that Alice uses but she certainly does not w= ant P to know that she also uses site Q.

So my plan here is that Alice can declare security pol= icies 'Work' and 'Pseudonymous' so that context is shared b= etween X, Y, Z but P and Q and R are each isolated with entirely separate c= ache and cookie settings.

For investigation work, I would also want to be able to specify that a sit= e be accessed through a forensic proxy, for personal privacy I might bounce= requests to different sites off different proxies.

So for my extreme privacy browser, I can specify= that a site should use a shared certificate as specified by the security l= abel applied to that site or a site specific certificate to prevent linkage= .

The github is here:
https://github.com/hallambaker/PhillsHypotheticalBrowser


My thanks to the Microsoft WebView2 team for= making this possible.


On Tue, Jun 14= , 2022 at 4:44 PM Mike Ounsworth <Mike.Ounsworth@entrust.com> wrote:
Hi Phillip,

What clients are you trying to use this with? Browsers? This almost feels l= ike a user-agent question: "What CA DN do you want the server to promp= t for so that you put up the right certs in the popup?". Is there a CA= DN that you can specify that will cause FF / Chrome to show the user all t= heir loaded certs?

Note: back in 2018 I was fiddling around with this for a stackexchange ques= tion and found that (by default) Firefox politely waits for you to select a= client cert from the popup, whereas Chrome just starts spamming client cer= ts at the server until it accepts one. I feel like user-agent behaviour is = going to affect the viability of your idea here.

https://security.stackexchange.com/a/199518/61443

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Phillip Hallam-Baker
Sent: June 14, 2022 2:58 PM
To: SPASM <SPASM@iet= f.org>; tls@ietf.o= rg
Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS clie= nt authj

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe.
________________________________________
[Yes, I am aware of the FIDO work and it is a completely different use case= , does not apply to non web applications. TLS Client Auth is an IETF spec a= nd thus within IETF scope.]

I have an infrastructure that makes private key management really simple fo= r end users. They can manage private keys across devices without being awar= e they are doing it. This technology has obvious applications for existing = public key authentication schemes including EAP, FIDO and TLS Client Auth.<= br>
When looking at TLS client auth it seems to me that it is much closer to be= ing a viable replacement for some uses of passwords than experience leads u= s to believe. In particular, I have maybe 5 accounts I might use a hardware= token to secure but I have several hundred Web accounts that all use the s= ame password because when it's not my asset and I am not being paid, I = don't use my brain power to remember the password.

So my basic idea here is that Alice connects all her devices to her persona= l Mesh and they are automatically provisioned with a device specific cert t= hat is chained up to one of Alice's personal PKIX CAs. The CA in turn b= eing (optionally) credentialed under Alice's personal Mesh via an exten= sion if the goal is to establish that the 'Alice' visiting site A i= s the same as the Alice visiting site B. For cases where we want to prevent= linkage, we develop a separate CA per site.

This is not how PKIX is intended to work of course. But the deployed infras= tructure supports PKIX and so that is the framework we have to work within.=


Looking at how TLS Client Auth works as deployed, a server sends a message = back to a client saying 'client certificate required' and a list of= distinguished names of CAs it will accept.

So what I want to know is not 'should I do this', but 'what is = the string I should send when I do'. That is, this is something I am pl= anning to do and so I am asking what approach is least likely to have unint= ended effects.

I see a need for two distinguished names:

A) 'Self signed CA speaking to any relying party'
B) 'Self signed CA speaking to a specific relying party'

The server is going to check the certificate chain itself on the other end = of course.


And again, yes, I do fully understand the limitations of transport layer cl= ient auth. That is why I make use of my own authentication layer for Web Se= rvice transactions.

Any email and files/attachments transmitted with it are confidential and ar= e intended solely for the use of the individual or entity to whom they are = addressed. If this message has been sent to you in error, you must not copy= , distribute or disclose of the information it contains. Please notify Entr= ust immediately and delete the message from your system.
--0000000000002e0f3805e173eb65--