[TLS] Re: Transparent TLS Client Auth (t2CA)

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 22, 2025 at 1:04 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, May 22, 2025 at 9:56 AM Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>>
>>
>> On Thu, May 22, 2025 at 11:50 AM Eric Rescorla <[e-mail]> wrote:
>>
>>> A few observations here.
>>>
>>> I generally agree that a signature-based scheme has superior privacy
>>> properties to something like OAuth, though the details really matter
>>> here. For example, if the system requires having a TXT record at the
>>> leaf node (e.g., ekr.<something>.gmail.com) then the end result is
>>> similar because the DNS server will get a query from the relying party
>>> for your specific identity, allowing the server to track you [0]
>>>
>>
>> The idea here is that you have your own personal DNS name that is yours
>> and only you use for authentication. It is a different approach but one
>> that has some surprising effects.
>>
>> A traditional Internet account is a delegation to a service. so
>> [e-mail]. To resolve that name, a client first locates the auth
>> server for rtfm.com and then sends it a query.
>>
>> In the Blue Sky model, your account has its own DNS name and can be
>> queried independently of any account discovery service: @ekr.example.com
>> .
>>
>
> Yes, I understand this, but as a practical matter, people don't have their
> own DNS names, and I don't think it's likely they are going to get them.
> Rather, they are likely to have them subordinated under some provider,
> exactly as they do now, in which case it will be `[e-mail]` which
> maps to `alice.gmail.com`, hence the privacy point I am making.
>

I accept that most people are going to go for a free DNS handle issued by a
handle provider. But a system in which users have the option of exit has
completely different dynamics to one where they are locked in by switching
costs.

I don't have any real control over or visibility into how my IdPs manage my
private data today. More importantly for me, neither does my significant
other who complains to me incessantly about privacy abuses.






>
>
>>
>> * 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.
>
> -Ekr
>

The target 'site' in this case is the HTTPS server built into my next IoT
thermostat after the current one is disabled because of malicious
obsolescence.