
Cryptography Dispatches: Registries Considered Harmful - wyclif
https://buttondown.email/cryptography-dispatches/archive/cryptography-dispatches-registries-considered/
======
Luker88
The article basically says that it's bad to support multiple choices (crypto
primitives) in a protocol.

> If you need to enumerate the options you support, it means that not only you
> support multiple ones, which is already bad, but you need to communicate the
> choices in the protocol itself, meaning you do runtime negotiation. Do you
> want bugs? Because that’s how you get bugs.

The author then says that we should just bump the version of the protocol each
time we change the ciphers. This already assumes that every time there is
always only one algorithm that governments, standard bodies, cryptographers,
companies, banks, hw manufacturers and others can agree to.

Good luck with that

And besides, how will you update our map that says that protocol "age" 1 uses
rsa, "age" 2 uses ed25519? That's right, with "Registries". Unless you
convince the whole world to just instantly switch to the new version at the
same time, so that you can also drop the old version.

> The industry now understands updating and patching software quickly is
> critical

Not my experience with cellphones, iot, pcs or even servers of any os

I might be in a bad mood, but I don't feel the article provides any practical
option or that the author has thought this out much

~~~
FiloSottile
> And besides, how will you update our map that says that protocol "age" 1
> uses rsa, "age" 2 uses ed25519?

With protocol versions, which don't require a registry for the primitives.
Like, there is no number that means RSA and no number that means Ed25519,
there is just age v1 and age v2, and each of them uses only the one specified
primitive. If you want to call version numbers registries, sure, but I think
you get what I mean.

People bring up "what about AES hardware" a lot, but they also seem to like
Wireguard, which also happens to be the fastest VPN option for most
deployments. Well, Wireguard just silently went and did what I'm advocating,
including only supporting ChaCha20Poly1305.

~~~
Luker88
So instead of having "primitive1 = rsa" you have "age1 = rsa".

It's the same thing. You are just bumping the protocol version faster, and
confusing people because protocol 42 will be just another crypto change, but
43 will be a complete protocol rewrite.

Meanwhile each protocol version needs to be standardized and accepted by the
whole world. That stuff is not fast

~~~
some_furry
Your theory doesn't seem to have stopped WireGuard from becoming a successful
high-performance VPN protocol/implementation.

------
tialaramex
Anybody paying attention knows I disagree with Filippo about the actual
cryptographic content here. In practice systems have different constraints.
AES for example is pretty nice _if you have hardware support_. Some do and
some don't. By offering AES as a _choice_ you allow people who do have
hardware support to prefer AES while those who don't can have say, ChaCha20.
And so you end up needing such a registry.

So instead I will focus on how I agree with his choice of movies. Before
Sunrise in particular is really under-appreciated.

------
goalieca
> Registries Considered Harmful

Can we cut it out with the memeing of a 50 year old paper.

~~~
tialaramex
You'll be lucky. People keep calling their attempts at weak take downs of
ideas they disagree with variants on "A Modest Proposal" and Swift died in
_1745_.

~~~
KineticLensman
Indeed:
[https://en.wikipedia.org/wiki/A_Modest_Proposal#Modern_usage](https://en.wikipedia.org/wiki/A_Modest_Proposal#Modern_usage)

------
upofadown
>...but you need to communicate the choices in the protocol itself, meaning
you do runtime negotiation.

But then the author goes on to use age as an example, which encrypts data at
rest so that no negotiation is possible.Sort of a low key way to weaken your
own point.

~~~
FiloSottile
You can totally do asynchronous negotiation, and PGP has plenty of examples of
it going wrong.

Edit: here's a beautiful recent example of in-band negotiation going wrong in
an encryption at rest scheme. [https://github.com/google/security-
research/security/advisor...](https://github.com/google/security-
research/security/advisories/GHSA-7f33-f4f5-xwgw)

~~~
tialaramex
This is completely the wrong place for this, but you don't list an email
address and I don't want a Twitter account

In Dispatch #4 you complain (speaking of FIDO for OpenSSH) that "As far as I
can tell, that’s true when the key handle is indeed an encrypted private key,
but there’s nothing in the spec requiring that". In the WebAuthn spec. which
I've actually read unlike the various other specifications, there are two
alternatives offered:

1\. At least 16 bytes that include at least 100 bits of entropy, OR

2\. The public key credential source, without its Credential ID or mutable
items, encrypted so only its managing authenticator can decrypt it. This form
allows the authenticator to be nearly stateless, by having the Relying Party
store any necessary state.

~~~
FiloSottile
(The Reply-To of the Dispatches goes to my inbox!)

Nice! Both 1 and 2 should provide the security properties. Now I do wonder how
the WebAuthn spec reflects the ecosystem of tokens compatible with OpenSSH.
Honestly, I don't even know if OpenSSH implements WebAuthn or there's a
different umbrella spec?

~~~
tialaramex
There are two separate specifications, FIDO and WebAuthn.

[Edited to add links:

[https://www.w3.org/TR/2019/REC-
webauthn-1-20190304/](https://www.w3.org/TR/2019/REC-webauthn-1-20190304/) and
the current editor's draft
[https://www.w3.org/TR/webauthn-2/](https://www.w3.org/TR/webauthn-2/)

[https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-
cl...](https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-
authenticator-protocol-v2.0-ps-20190130.html)

to give context]

I can't imagine there's actually a meaningful market for products that
implement the hardware protocols described in FIDO (which use byte
conservative CBOR because it's imagined that you'd try to run them over some
ratty wireless protocol with no bandwidth) but aren't intended to be used with
WebAuthn (which is full of JSON mapped to that CBOR because it's imagined
you're a full fat modern web site displayed on a modern graphical web browser
like Chromium or Firefox) but they are separate.

But OpenSSH doesn't need WebAuthn it just needs FIDO.

You'd presumably hate both specifications, because they drag in (and rely
upon) registries for a bunch of technically unnecessary stuff and not even for
the practical engineering reason I've excused in my sister posts to this
thread. It's pure politics, you need everybody on the bus and so if they
insist upon stupid ideas A, B and C between them then your options are veto A,
B and C and nobody goes on the bus so the exercise was futile or you allow A,
B and C with your face buried in your hands and plan for the inevitable
negative security consequences.

Microsoft really wanted to do RSA for example. So, even though _you_ wouldn't
do RSA and I'm sure none of the Google people working on this love it either,
the WebAuthn specification makes RSA an option and Microsoft shipped code that
does RSA with WebAuthn.

I believe agl wanted the standards to rip out U2F's counters. Some security
people love counters (does somebody have a war story where counters actually
saved the day? I want to hear that war story) but others wanted them and so
they are still in FIDO2/ WebAuthn even though they're a potential privacy
hazard.

There are other examples.

