[{"author": "Francesca Palombini", "text": "


", "time": "2024-03-19T07:34:37Z"}, {"author": "Kazuho Oku", "text": "

Is there a concern of this header field leaking keys to the origin behind CDN?

", "time": "2024-03-19T07:51:40Z"}, {"author": "Benjamin Schwartz", "text": "

I think the exporter is not a \"key\".

", "time": "2024-03-19T07:52:01Z"}, {"author": "Jonathan Hoyland", "text": "

It shouldn't matter, because the exporter is supposed to be a channel binding

", "time": "2024-03-19T07:52:30Z"}, {"author": "Jonathan Hoyland", "text": "

i.e., part of the security guarantee of channel binding is that you can make it public without reducing security

", "time": "2024-03-19T07:53:34Z"}, {"author": "Martin Thomson", "text": "

can someone backronym RSASSA-PKCS1v1.5 ?

", "time": "2024-03-19T07:55:03Z"}, {"author": "Kazuho Oku", "text": "

thanks I'm concerned of key leaking for request A being used for doing something with request B (that share the same end connection), but I think I have to consider if there's threat

", "time": "2024-03-19T07:55:51Z"}, {"author": "Julian Reschke", "text": "

We may want to define the \"Signature\" auth scheme then as well.

", "time": "2024-03-19T07:55:59Z"}, {"author": "Paul Gear", "text": "

How many of these images are AI-generated?

", "time": "2024-03-19T07:56:37Z"}, {"author": "David Benjamin", "text": "

Kazuho Oku said:


thanks I'm concerned of key leaking for request A being used for doing something with request B (that share the same end connection), but I think I have to consider if there's threat


That's why there's a label in the exporter interface. It is possible to use export keying material to export a key. However, that would be a different label and thus a separate secret.

", "time": "2024-03-19T07:57:13Z"}, {"author": "Tommy Jensen", "text": "

Certainly! When designing an HTTP mechanism that allows clients to provide authentication to a server without explicitly revealing that it accepts authentication, consider naming it \u201cStealthAuth\u201d. This name conveys the idea of discreetly providing authentication without broadcasting its presence.

", "time": "2024-03-19T07:57:17Z"}, {"author": "Tommy Jensen", "text": "

^ the search engine that pays my mortgage

", "time": "2024-03-19T07:57:30Z"}, {"author": "Martin Thomson", "text": "

Exclusive Client Digital Signature Authentication

", "time": "2024-03-19T07:58:53Z"}, {"author": "Benjamin Schwartz", "text": "

Any HTTP authentication scheme, including Basic, can be used unprompted, and this scheme can be used not-unprompted, so I don't understand why that name would be appropriate.

", "time": "2024-03-19T07:59:28Z"}, {"author": "Martin Thomson", "text": "

Really Simple Authentication with Single Signature Application

", "time": "2024-03-19T07:59:29Z"}, {"author": "Tommy Jensen", "text": "

@mt genius

", "time": "2024-03-19T07:59:39Z"}, {"author": "Tommy Jensen", "text": "

MT, here's your backronym: \"RSASSA-PKCS: \u201cRevealed Secret Authentication System Supporting Secure Access - Pre-Knowledge Client Scheme\u201d

", "time": "2024-03-19T08:00:19Z"}, {"author": "Muhammad Sardar", "text": "

@Jonathan: can you share the link to formal analysis artifacts?

", "time": "2024-03-19T08:00:28Z"}, {"author": "Lucas Pardue", "text": "

sigsig sputnik

", "time": "2024-03-19T08:00:44Z"}, {"author": "Martin Thomson", "text": "

Tommy: I thought that mine were tortured

", "time": "2024-03-19T08:00:56Z"}, {"author": "Alex Chernyakhovsky", "text": "

UNICORN: Unprompted, New, Informational Cryptographically ORiginated ideNtity

", "time": "2024-03-19T08:00:57Z"}, {"author": "Martin Thomson", "text": "

but that is far worse

", "time": "2024-03-19T08:00:59Z"}, {"author": "Alex Chernyakhovsky", "text": "

(because the only upgrade from ponies is unicorns, right?)

", "time": "2024-03-19T08:01:11Z"}, {"author": "Tommy Jensen", "text": "

I blame Copilot, and whoever's sponsor created it :P

", "time": "2024-03-19T08:01:33Z"}, {"author": "Justin Richer", "text": "

@Julian if we do that it really should be based on 9421

", "time": "2024-03-19T08:01:48Z"}, {"author": "Jonathan Hoyland", "text": "

@Muhammad Sardar ugh, I forgot that it's still with my company's open sourcing people, I'll poke them and share it with the list ASAP.

", "time": "2024-03-19T08:02:10Z"}, {"author": "Tommy Jensen", "text": "

@Alex nice, but can we put the emoji Unicode in the name as well?

", "time": "2024-03-19T08:02:11Z"}, {"author": "Justin Richer", "text": "

\"blinded information signature\"

", "time": "2024-03-19T08:02:30Z"}, {"author": "Justin Richer", "text": "

Authorization: bis

", "time": "2024-03-19T08:02:38Z"}, {"author": "Kazuho Oku", "text": "

So IIUC, the context includes authority and realm but not path or headers. So anybody that obtains the key and the signature can obtain responses from the same (authority, realm). Not sure if that is necessarily a threat though

", "time": "2024-03-19T08:02:57Z"}, {"author": "Francesca Palombini", "text": "

meetecho remote participant sounds way too loud, anything you can do?

", "time": "2024-03-19T08:03:22Z"}, {"author": "Muhammad Sardar", "text": "

thanks Jonathan.

", "time": "2024-03-19T08:03:27Z"}, {"author": "Tommy Jensen", "text": "

Justin, if we rev that, is it bisbis?

", "time": "2024-03-19T08:03:33Z"}, {"author": "Chris Lemmons", "text": "

It's way too loud for the remote folks, too.

", "time": "2024-03-19T08:03:35Z"}, {"author": "Alex Chernyakhovsky", "text": "

(serious) are we allowed to do UTF-8 in HTTP headers? if so, emoji all the way

", "time": "2024-03-19T08:03:36Z"}, {"author": "Francesca Palombini", "text": "

he's reconnecting

", "time": "2024-03-19T08:03:39Z"}, {"author": "Lorenzo Miniero", "text": "

Please don't touch the mixer

", "time": "2024-03-19T08:04:10Z"}, {"author": "Lorenzo Miniero", "text": "

We can fix the volume from here

", "time": "2024-03-19T08:04:17Z"}, {"author": "Benjamin Schwartz", "text": "

I think WWW-Authenticate: UnpromptedAuth would be totally valid, and even useful, and this strongly indicates that \"unprompted\" or \"unsolicited\" is not a good name.

", "time": "2024-03-19T08:04:29Z"}, {"author": "Chris Lemmons", "text": "

Thank you! So much better.

", "time": "2024-03-19T08:04:31Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

Please do!

", "time": "2024-03-19T08:04:32Z"}, {"author": "Francesca Palombini", "text": "

now sounds good :) thanks

", "time": "2024-03-19T08:04:34Z"}, {"author": "Lorenzo Miniero", "text": "

Can you still hear the speaker?

", "time": "2024-03-19T08:04:40Z"}, {"author": "Muhammad Sardar", "text": "


", "time": "2024-03-19T08:04:53Z"}, {"author": "David Schinazi", "text": "

Gemini has spoken: The document describes a cryptographic authentication scheme for HTTP that offers several advantages:


Non-probeable: It prevents unauthenticated clients from discovering the existence of resources that require authentication.
\nFreshness guarantee: It ensures the signature is based on fresh data and not a replay of a previous signature.
\nTLS integration: It leverages existing TLS features for key derivation.
\nBased on these functionalities, here are some name options that better capture the essence of the scheme:


FreshTLS-Auth (Fresh TLS Authentication) - This name emphasizes both the freshness guarantee and the TLS integration.
\nNoPeek-HTTP-Sig (No-Peek HTTP Signature) - This name highlights the non-probeability aspect and the use of signatures.
\nConceal-HTTP-Auth (Conceal HTTP Authentication) - This name focuses on the ability to hide the existence of authenticated resources.
\nThe final choice depends on which aspect you want to prioritize. If non-probeability is the key feature, \"NoPeek-HTTP-Sig\" might be most suitable. If you want to emphasize both freshness and TLS, \"FreshTLS-Auth\" could be a good option.

", "time": "2024-03-19T08:04:53Z"}, {"author": "Justin Richer", "text": "


", "time": "2024-03-19T08:05:02Z"}, {"author": "Chris Lemmons", "text": "

Yes, hear the speaker loud and clear, but not painfully so. :D

", "time": "2024-03-19T08:05:07Z"}, {"author": "Alex Chernyakhovsky", "text": "

@David Schinazi those are all terrible

", "time": "2024-03-19T08:05:15Z"}, {"author": "David Schinazi", "text": "

well yes

", "time": "2024-03-19T08:05:24Z"}, {"author": "Alex Chernyakhovsky", "text": "

Please tell the LLM to try harder

", "time": "2024-03-19T08:05:34Z"}, {"author": "Thomas Eizinger", "text": "

Oblivious authentication?

", "time": "2024-03-19T08:05:47Z"}, {"author": "Tommy Jensen", "text": "

Gemini versus Copilot: who does acronyms worse?

", "time": "2024-03-19T08:06:03Z"}, {"author": "David Schinazi", "text": "

You're right, I can do better! Here are some improved name options for the authentication scheme, incorporating the feedback and aiming for a more creative and informative approach:


Cryptonym: This combines \"cryptography\" with \"anonymity,\" highlighting the secure authentication without revealing resource existence.
\nVeritas: Derived from the Latin word for \"truth,\" it emphasizes the freshness guarantee and authenticity of requests.
\nTLShield: A portmanteau of \"TLS\" and \"shield,\" emphasizing the leverage of TLS for secure communication.
\nSpectreAuth: \"Spectre\" suggests the invisibility of protected resources, while \"Auth\" stands for authentication.
\nSigNet: A combination of \"signature\" and \"net,\" signifying the use of digital signatures within the network.
\nThese names are more evocative and informative than the previous options. They also consider the feedback of \"trying harder\" by incorporating a more creative approach.


Here's a bonus option with a technical twist:


NHDR-Sig (Non-Probeable HTTP Digital-Signature): This name explicitly mentions the core functionalities for those familiar with the technical details.
\nUltimately, the best name choice depends on the specific target audience and the desired emphasis.

", "time": "2024-03-19T08:06:03Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

Discreet, Enigmatic Signature.

", "time": "2024-03-19T08:06:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

...you know it's bad when the acronym it proposes is the least bad one.

", "time": "2024-03-19T08:06:37Z"}, {"author": "Tommy Jensen", "text": "

@Alejandro congratulations, you managed to make the most offensive one

", "time": "2024-03-19T08:06:58Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Alejandro Sede\u00f1o :angry:

", "time": "2024-03-19T08:06:58Z"}, {"author": "David Benjamin", "text": "



Clearly we should call it speculative auth and confuse everyone into thinking about CPU bugs.

", "time": "2024-03-19T08:07:09Z"}, {"author": "Alex Chernyakhovsky", "text": "

@David Benjamin Heartbleed auth?

", "time": "2024-03-19T08:07:38Z"}, {"author": "Martin Thomson", "text": "

Restricted Object using TLS 1.3 (ROT13)

", "time": "2024-03-19T08:07:48Z"}, {"author": "Thomas Eizinger", "text": "


", "time": "2024-03-19T08:07:55Z"}, {"author": "Jonathan Hoyland", "text": "

Speculative auth isn't a bad name actually

", "time": "2024-03-19T08:08:10Z"}, {"author": "Jonathan Hoyland", "text": "

@Thomas Eizinger Only if we implement it with Monads :joy:

", "time": "2024-03-19T08:08:27Z"}, {"author": "Chris Lemmons", "text": "

Secret-Knock :D

", "time": "2024-03-19T08:08:31Z"}, {"author": "Benjamin Schwartz", "text": "

@Jonathan Hoyland Nothing about this requires it to be used speculatively! Many other auth schemes can be used speculatively!

", "time": "2024-03-19T08:08:52Z"}, {"author": "Tommy Jensen", "text": "

ROT13... you have two weeks to make it an April 1 RFC

", "time": "2024-03-19T08:09:12Z"}, {"author": "Jonathan Hoyland", "text": "

I think the key thing is that it's bound to the underlying TLS session, so maybe something related to that?

", "time": "2024-03-19T08:09:48Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2024-03-19T08:10:39Z"}, {"author": "Sanjeev Gupta", "text": "

@Martin Thomas , what happens if I authenticate twice? ROT26?

", "time": "2024-03-19T08:10:41Z"}, {"author": "David Oliver", "text": "

@ben Doesn't WWW-Authenticate require a 401 Unauthorized response, thus revealing the authenticated resource?

", "time": "2024-03-19T08:10:42Z"}, {"author": "Martin Thomson", "text": "

specify times using relative values

", "time": "2024-03-19T08:10:49Z"}, {"author": "David Benjamin", "text": "

Benjamin Schwartz said:


Jonathan Hoyland Nothing about this requires it to be used speculatively! Many other auth schemes can be used speculatively!


I was going to suggest this, but then I changed my mind on this. This particular design does seem to actually want to be speculative. There's this whole key ID machinery and whatnot and that presumes you already have a priori knowledge about how the server works. There isn't a WWW-Authenticate defined here as far as I can tell, etc.

", "time": "2024-03-19T08:11:00Z"}, {"author": "Martin Thomson", "text": "

no absolute times in protocols, please

", "time": "2024-03-19T08:11:02Z"}, {"author": "David Benjamin", "text": "

Whereas if we wanted to, say, build an HTTP auth mechanism that mirrors TLS client certificates, we'd still sign exporters, but the dressing around it would be different. So I think we don't actually want to key on the channel binding.

", "time": "2024-03-19T08:11:43Z"}, {"author": "Benjamin Schwartz", "text": "

@David Benjamin I'm pretty sure WWW-Authenticate is well-defined here. It's also a totally reasonable and useful way to use this scheme, in cases where you want bearer-like authentication but with less log-stealability, and you don't want to waste bandwidth on sending the Authorization header when it isn't needed.

", "time": "2024-03-19T08:12:42Z"}, {"author": "Jonathan Hoyland", "text": "

I think our initial pass was using Frames and thus this was connection level, which made stuff more obvious

", "time": "2024-03-19T08:13:02Z"}, {"author": "Tommy Jensen", "text": "

What if we focus on the fact that the client is acting first... like, ProactiveAuth, or VolunteeredAuth?

", "time": "2024-03-19T08:13:14Z"}, {"author": "Rahul Gupta", "text": "

Use Structured Fields Date

", "time": "2024-03-19T08:13:50Z"}, {"author": "Jonathan Hoyland", "text": "

It's (currently) the only way for a client to auth using the TLS layer without the server asking for it.

", "time": "2024-03-19T08:13:58Z"}, {"author": "Jonathan Hoyland", "text": "

I do have another draft that also enables this feature, but let's not go there.

", "time": "2024-03-19T08:14:36Z"}, {"author": "Martin Thomson", "text": "

I think that the only general one is size, which is a fine way to leave it

", "time": "2024-03-19T08:16:39Z"}, {"author": "Martin Thomson", "text": "

Eww, meetecho does some pretty nasty things to text with backticks.

", "time": "2024-03-19T08:17:06Z"}, {"author": "Lucas Pardue", "text": "

for simplicity I _think_ putting all those upload limits in resumable uploads is probably correct

", "time": "2024-03-19T08:17:39Z"}, {"author": "Alexander Clouter", "text": "

trailing header checksums could be useful for upload

", "time": "2024-03-19T08:18:44Z"}, {"author": "Tommy Jensen", "text": "

It's (currently) the only way for a client to auth using the TLS layer without the server asking for it


PREemptive Client Auth?

", "time": "2024-03-19T08:19:16Z"}, {"author": "Alexander Clouter", "text": "

so partial writes of an interrupted patch may be undesirable

", "time": "2024-03-19T08:19:19Z"}, {"author": "Benjamin Schwartz", "text": "

/me votes for scheme = \"Exporter\"

", "time": "2024-03-19T08:20:04Z"}, {"author": "Jonathan Hoyland", "text": "

I don't hate it, although would that preclude us using e.g. symmetric auth + Exporter keys?

", "time": "2024-03-19T08:21:01Z"}, {"author": "Martin Thomson", "text": "

Content codings don't really work this way.

", "time": "2024-03-19T08:21:29Z"}, {"author": "David Benjamin", "text": "

The great Content-Encoding vs Transfer-Encoding confusion.

", "time": "2024-03-19T08:22:24Z"}, {"author": "Martin Thomson", "text": "

Transfer coding is dead

", "time": "2024-03-19T08:23:08Z"}, {"author": "Julian Reschke", "text": "

The answer needs to be: the same way as for any other method.

", "time": "2024-03-19T08:23:10Z"}]