[TLS] Re: Transparent TLS Client Auth (t2CA)
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 22 May 2025 21:13 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CFAD32C08B22 for <tls@mail2.ietf.org>; Thu, 22 May 2025 14:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYUULhvMVX_H for <tls@mail2.ietf.org>; Thu, 22 May 2025 14:13:34 -0700 (PDT)
Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D40192C08B1B for <tls@ietf.org>; Thu, 22 May 2025 14:13:34 -0700 (PDT)
Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3f7f7b70aebso6214992b6e.2 for <tls@ietf.org>; Thu, 22 May 2025 14:13:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747948414; x=1748553214; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0ahtLxRdpQo1j6AAqWgkiHSsL3f8Y5BnGMwfHn9Ixvk=; b=Iz9Yn7lxwt0PjW9SJJ4ikIaimAJW2dsm58/r0s3yRnW3AQfJLxHsinISb+ncid4Oya Qj6Did6BvPWcybbrUT7DmvhpG2aQETWkdytF9TFnAEUvOytXtAf9jXSQDv9UyrjedSSf fDm6WbmPFg18hELAE4RYUrHQmCwexe1Rd2ewhtqpz4bMzpVpOd/FNzzJlrrToZ1Ey57h PVJC28nJJTQavqTurmDos1rs1U/LVBF89/VIw5WvLRLYIcOk5cWovlKCIqxvlqpDXB82 kQPjrSB6+LBI5T1p7vEVvdg7BwUT2Z5XAReYlWkU2iy/Wfd7PirLAgmq2CLWZbZyB8c6 Zi8A==
X-Gm-Message-State: AOJu0YyX15r0hn9l2IhLEaf62MjeXE6PduWhspmPkx/TkzeGw80hvR0b vctCbk67ttT+QRZ0cq3ndwqH+teQ3aqpD0jqibUwinClG6bged3ZMu2wsfqZYBURy6IM8FWP5Cp 7s0HgrVcY/8gsnErMQjbIQCe/AAzhQ9sQAw==
X-Gm-Gg: ASbGncsAUxgIwDXS7QnSB5QvmzsoA06Kfy+aMSqLnPpIYqDiZ+Y2Alc/LdgLCLN9Kj1 nkR/URBkT3oF0YWpViZxc+AKu9hESJncXoFGA5yGj+HdTojB7+fyGfhJknKlqnmNq1GWz1jdwIH hxC0DFW7Le2Qhqg1G2GJBpAeOZlh/Z2fOL/8H2eOwdhc6rJYKb+3qIuY81fHx2aDYTRrQ=
X-Google-Smtp-Source: AGHT+IGQtcPcy7NX6VmsBufCI7xxyzKhP0KdyHJZ9iLUgrsaEpYdEBk33jW/CP8xzYnrTr63AABjmKYgehs57y3UcBY=
X-Received: by 2002:a05:6214:5017:b0:6f8:d223:3c4a with SMTP id 6a1803df08f44-6fa93a34bc0mr11224506d6.17.1747948403312; Thu, 22 May 2025 14:13:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwgUckd7M4J1wop9srwxaFkfenmibLJ1=-dJb-pfEkXxLg@mail.gmail.com> <CABcZeBMkNs=Uhe5Wv49P8OquN8rn0z_p4cXgB51gS879RFxBZA@mail.gmail.com> <CAMm+LwgszwpdfB5k0ETEfg2cYyestZtq0y5pS7=Y7kzdyoBPbw@mail.gmail.com> <CABcZeBPgxDhqroAUO+fW4Sp6qvSHugd2pym5C2_+jNcQUXaqxw@mail.gmail.com> <CAMm+LwgMgsTyHgkenDU0XsBeRAk3kOb7cfpFhZNpNpOr8sam9Q@mail.gmail.com> <CABcZeBOdmwZkPwXGfYscRDwqO-icWuG1a4=ujQ7RpJBuBJcryw@mail.gmail.com> <CAMm+Lwiz5bsb5sHM2Xnq-8kyTnbBDmS_NjEGirEvMLcnfvP0TQ@mail.gmail.com> <CABcZeBMzb5n-vuABTO5LEy_eqFc7S7=J=OY817EAqoFuVTA7_g@mail.gmail.com>
In-Reply-To: <CABcZeBMzb5n-vuABTO5LEy_eqFc7S7=J=OY817EAqoFuVTA7_g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 22 May 2025 17:13:10 -0400
X-Gm-Features: AX0GCFtjak-a1YwpjKDcQFbDBbN8WqSN0bnUrDRWruceNwnhwFT2r6Vi7rt2Eeo
Message-ID: <CAMm+LwgTU4Fz-1W1_2yOQDtpVC5ZbemqH1aR5sv5Y4wL8gOMqQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="000000000000aa4d8e0635bff3fa"
Message-ID-Hash: SZ4H4C7P3ESULZNW27VM2NLVMV7L6MXP
X-Message-ID-Hash: SZ4H4C7P3ESULZNW27VM2NLVMV7L6MXP
X-MailFrom: hallam@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tls <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Transparent TLS Client Auth (t2CA)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FV_DD98ADWAhQS6Gf8vqoudTUK8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
On Thu, May 22, 2025 at 4:07 PM Eric Rescorla <ekr@rtfm.com> wrote: > > > On Thu, May 22, 2025 at 12:58 PM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> On Thu, May 22, 2025 at 1:58 PM Eric Rescorla <ekr@rtfm.com> wrote: >> >> * Allowing the site to control the timing of the authentication >>>>> (e.g., offering you connect unauthenticated and then upgrading). >>>>> * Allowing the site to offer multiple authentication options. >>>>> * Allowing the site to control the look and feel of the interaction. >>>>> >>>> >>>> I don't want the site to be doing any of that. I want there to be a >>>> single consistent authentication experience across everything. Without >>>> consistency, users have no idea what they are doing and the scheme is >>>> vulnerable to social engineering attacks. >>>> >>> >>>>> What matters here is not what you want but rather what the site wants, >>>>> and in my experience they want these properties. >>>>> So, again, I ask: which major players in the current ecosystem are >>>>> interested in this. >>>>> >>>> >> I missed this the first time. Are you serious? >> >> 'What matters here is not what you want but rather what the site wants' >> >> So, we only listen to the businesses and corporations, not the Web users? >> > > No. I think we should design technologies that benefit users, but we > should spend our > time designing technologies that will actually get deployed. And that > means understanding > whether there is demand for these technologies by the people in charge of > deploying > them. That doesn't of course mean that every feature of those technologies > needs > to be to the liking of those players, and often it will not be, but if > there is no interest > in the big picture, then I don't think standardization work is useful. > Of all the folk working in IETF, I suspect I spend the most time developing deployment plans. I don't always succeed but I have a pretty good batting average. But working out deployment always comes after working out what the user needs and what the technical constraints are. What are the pain points driving the key stakeholders? I rather suspect a lot of European Web sites would go for any technology that allows them to drop the 'accept all cookies' banners... I think you are dead wrong about what the sites want. I have heard many, >> many sites say they want OpenID without having Facebook or Google in the >> loop. They absolutely do not want an auth system that has their biggest >> competitive threats seeing who visits them. >> > > In that case there will be interest and this might be worth doing. > > -Ekr > >
- [TLS] Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Ben Schwartz
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Shumon Huque
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Eric Rescorla
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Eric Rescorla
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Eric Rescorla
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker
- [TLS] Re: Transparent TLS Client Auth (t2CA) Eric Rescorla
- [TLS] Re: Transparent TLS Client Auth (t2CA) Phillip Hallam-Baker