Hey Soatok, my name is Manu Sporny and I’m a standards editor for a variety of security specifications at W3C and IETF. I’ve read a number of your posts over the years and have found many of them on point and reflective of concerns that a number of us have at both W3C and IETF. More recently, we’ve started work at W3C in the Verifiable Credentials Working Group on a global pre-standard called Data Integrity (which has been incubating since 2012) that attempts to fix a number of the issues you highlight in your post as well as other good points you’ve made in the past. Namely, you might find this draft specification text of interest:
As you might imagine, we’ve had significant push back by a vocal minority in the JOSE/JWT community over the years. Large technology vendors have actively objected to creating work items that might reign some of the worst aspects of JOSE and JWTs in… actions which have delayed the work. Some application developers that use JWTs often react negatively to the notion that there are fundamental problems with JWT – everything from “If that were true, why is JWT so successful and widely deployed!?”… to “oh, the problem is with the implementers, not the standards”… to “oh, the problem is that we don’t have good test suites”. The responses to those defending the design of JOSE/JWTs tend to be “Just because something is widely deployed doesn’t mean it’s easy to use in a safe manner.”… “The standards create optionality but don’t do much to protect application developers from picking the wrong options.”… “Yes, test suites might help – it’s been almost a decade, where are the JOSE test suites… where is the language and test suite that deprecates alg=none and fails implementations for not deprecating it (or HMAC/signature algorithm confusion)?”. As you can guess, those conversations have been going nowhere for the better part of a decade.
So, we’re actively doing something about it by demonstrating that it is not only possible to ratchet the attack surface around cryptographic library implementations down and protect application developers from themselves, but that it’s necessary to standardize tightly controlled combinations of cryptography (cryptographic suites), and actively test implementations against a conformance test suite that is maintained by the Working Group. This is active work that’s been going on for a while now, and we’re in the last two years before we standardize such a mechanism. I invite you to contribute to the discussion, if you have the time via the IETF CFRG, W3C VCWG, or Github issue trackers for Data Integrity. We’d love to have your input as we create safer cryptographic standards led by the principles you have written about in your blog.
Once upon a time I was trying to explain the problems with JWT to someone who allegedly was a “security person”, and that person told me, in about as many words, that all the vulnerabilities were due to bad developers using dynamically-typed languages, not due to the combinatoric explosion of stuff JWT forces you to think about and either defuse or disable.
Unfortunately, JWT still ended up winning in both that debate and most of the SSO protocols :/
And as an aside: I’ve been fighting against JWTs in Django for years, on similar grounds, and so far have been winning that fight. There are a bunch of third-party add-ons to Django that will give you JWTs if you really want them, though.
This makes me feel ok about my choice to use a zero-options protocol (SecretHandshake) for my project. I really like the simplicity.
I’m a bit concerned about hardcoding Ed25519 public keys as user identities; but it looks like whatever replaces elliptic curves will use godawful-long keys so they’ll be easy to distinguish from the current 32-byte keys without needing any metadata.
Great overview of the approaches, their ups and downs. I think one approach not taken as much but kind of sits in the middle of versioning and agility is the cryptographic suites approach. In this one, instead of allowing the user to select from a set of pieces (this hash, that encryption algorithm, this signing algorithm) a “suite” is fully named and specifies how all the pieces are used. Somewhat like a version number, you’re taking a vetted set of things at once, but it doesn’t necessarily have one single incrementing path.
I’m not an expert in cryptographic areas, so I won’t say “this is what you should do!” but I will say I think it’s an interesting approach, worth highlighting as the possible tradeoffs are expressed.
To me it sounds like versioning except strictly less good. For each particular use case you’re going to have a single Best Choice, so why not just use that suite and call it V1, and if a better one comes along you just use that one and call it V2?
There can be situations where there are multiple best choices, depending on what you are running on. Embedded devices often have accelerators for cryptographic functions, and what functions perform best depends on the chip. If you have multiple products with different chips in them, that talk to the same service, then you may need multiple different suites for each one to perform at it’s best.
That sounds like a great way to shoot yourself in the foot. Cryptography is complicated enough, adding more complexity is inviting trouble where one probably doesn’t need it.
Having n working versions isn’t that much more complicated than having 2 versions, one of which is in progress of deprecation. You still need version identifiers, and you still need to use appropriate algorithms for each version. The only problem is that there is a larger attack surface in the systems that need to interact with all of the versions, but in the use case I suggested, it usually is the control system, and is usually a lot easier to update than the embedded devices. From the embedded device point of view, there is only a single version of the protocol.
As you wrote already on your blog post : allowing for everything is just dumb, so I do not really understand why all of your cases that you presented allow user to do anything and everything.
To shorten it, let’s establish a short glossary:
CA – crypto agility
First, let’s separate the concerns – language is abstract, design is abstract, we are talking not about specific implementations like JWT, SSH or anything – we are talking about CA as a concept. There are better and better and worse implementation out there and very different usages depending on application.
CA does not state anywhere that you have to have a. backward compatibility and b. to be able to switch to anything anywhere – those are implementation-specific, and again you are saying that the concept itself is broken. This is False Attribution Fallacy,
padding, oracle, and downgrade attacks, are also, implementation specific to the code, usage and application, Again, False Attribution Fallacy,
the post is clearly made from the web-developer perspective, but talks about the general concept and its usage. You are not considering different usages that already exists and focusing mostly on the narrow, specialized usage (tiny slice of networking applications). This is Packaged Deal Fallacy.
allowing for everything is just dumb, so I do not really understand why all of your cases that you presented allow user to do anything and everything.
Because every implementation of a design that prioritized Crypto Agility inevitably fucked up in exactly this way.
Real world cryptography is messy and full of mistakes.
This is Packaged Deal Fallacy.
I blog as my fursona, which I keep totally separate from my legal identity as much as reasonably possible.
Most of the real world examples I could point to for why agility fails are under my legal name, and also restricted by NDA. This forces me to take some liberties in how I write.
If you want to cross examine my experience (without forcing me to put myself in a legally precarious situation), simply ask other cryptography/security experts if their experience matches mine. Preferably one that you’re paying for their time, so that their incentives are aligned with your interests, not mine.
Every solution that avoided the “allow everything stupid” pitfalls began with the premise of not doing Crypto Agility (i.e. WireGuard), or only doing minimal Crypto Agility (i.e. PASETO).
I blog as my fursona, which I keep totally separate from my legal identity as much as reasonably possible.
I do not care. Honestly, I’m not concerned with your social interactions. IMO, At the very moment you mix those things into discussion about the technology, which is ruled by specifications, RFCs, and is known for being precise, the strength of your arguments falls to the ground. I would also advise not to bring lawyers, sociology, gender, religious or political beliefs, race, or other non-technical things to the technical discussion; since those are both confusing to the readers and brings nothing to the table – just a free tip for the future.
Because every implementation of a design that prioritized Crypto Agility inevitably fucked up in exactly this way.
Real world cryptography is messy and full of mistakes.
Does every implementation have done it? Mine was fine, it had no such problems that you mentioned? Was it good? fuck no – but does that mean that you saw what I wrote? Does that mean that you saw everything other people wrote? Are you saying you are an all-knowing being from another dimension, granting us your wisdom?
You clearly said that all CA is wrong, but you do not know all the applications of it. Moreover, your core understanding of CA is very wrong. I wrote about that before.
Most of the real world examples I could point to for why agility fails are under my legal name, and also restricted by NDA. This forces me to take some liberties in how I write
To me, a sentence
"i took some liberties to how i write"
sounds like a fancy version of
"i lied and/or overcolorized what i wrote, whatyougonadoabboutit".
It’s like saying
“oh no your honor, i did not kill the man, i barely depraved him of oxygen in the mixture of air he was breathing, but I clearly stated by my actions he was not at liberty to use.”;
a.k.a. "a word salad".
Long story short – I am on the other side of the fence. What you are writing is being dishonest to the work i’ve done, and the work of other developers in the field. That’s why I started this discussion.
That is also the reason I postulate that you are deliberately either:
1. pose as someone, you are not,
2. advertising yourself having experience in the field you clearly lack,
3. or deliberately misguiding the audience.
If you are not, then you have my sincerest, apology, but your last comment does not strike me as convincing – at least to this point.
Every solution that avoided the “allow everything stupid” pitfalls began with the premise of not doing Crypto Agility (i.e. WireGuard), or only doing minimal Crypto Agility (i.e. PASETO).
That’s again a lie, so let me rephrase that for you: "Every solution that I know or noticed did that". And that would be a valid statement, and I would totally emphasize with you. But, clearly, the one I was working on didn’t have such problem, and I already wrote why. Allow me to clarify that again, in simpler words, so it will be easier to understand – CA is like a pattern, a tool, let’s say a gun. Some guns are terrible, some are at least okay-ish, but clearly you got a bad one – you cheeped out, it blew your face off, and now you are ranting that all of them are bad. That is a very childish approach.
Conclusion? If you are writing about your experiences, state it as such. Do not discredit or disregard other people’s work. What you wrote is good in theory as a beginning of a debate or a precise and directed rant, but not as an article stating the fact. If for every fallacy you committed I would get a dime, I could buy myself a very good coffee now.
IMO, At the very moment you mix those things into discussion about the technology, which is ruled by specifications, RFCs, and is known for being precise, the strength of your arguments falls to the ground.
Which IETF working group do you think is responsible, exactly, for my personal blog where the article was published?
There are no real “rules” for personal blogs. I write in a conversational English style. I use furry art at my discretion to punctuate my points. Some people dislike it. I simply increase the amount of furry art I use when people complain.
I would also advise not to bring lawyers, sociology, gender, religious or political beliefs, race, or other non-technical things to the technical discussion; since those are both confusing to the readers and brings nothing to the table – just a free tip for the future.
This is a lot of unsolicited advice from someone who doesn’t care.
I’m not going to bother reading the rest of your comment. You should familiarize yourself with the Lobsters rules. We strive to be more positive and constructive than HN or Reddit here.
Also, if you think your implementation is special and perfect, at least have the decency to drop a link to the source code so it can be critiqued.
Hey Soatok, my name is Manu Sporny and I’m a standards editor for a variety of security specifications at W3C and IETF. I’ve read a number of your posts over the years and have found many of them on point and reflective of concerns that a number of us have at both W3C and IETF. More recently, we’ve started work at W3C in the Verifiable Credentials Working Group on a global pre-standard called Data Integrity (which has been incubating since 2012) that attempts to fix a number of the issues you highlight in your post as well as other good points you’ve made in the past. Namely, you might find this draft specification text of interest:
Cryptographic Agility and Cryptographic Hardening: https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/41.html#agility-and-hardening
Cryptographic Suite Versioning: https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/41.html#versioning-cryptography-suites
CFRG discussion on how much cryptographic optionality, and at what layer, is useful: https://mailarchive.ietf.org/arch/msg/cfrg/ahcgo7RZ7rL7wavG2Z4_LbE2tkk/
As you might imagine, we’ve had significant push back by a vocal minority in the JOSE/JWT community over the years. Large technology vendors have actively objected to creating work items that might reign some of the worst aspects of JOSE and JWTs in… actions which have delayed the work. Some application developers that use JWTs often react negatively to the notion that there are fundamental problems with JWT – everything from “If that were true, why is JWT so successful and widely deployed!?”… to “oh, the problem is with the implementers, not the standards”… to “oh, the problem is that we don’t have good test suites”. The responses to those defending the design of JOSE/JWTs tend to be “Just because something is widely deployed doesn’t mean it’s easy to use in a safe manner.”… “The standards create optionality but don’t do much to protect application developers from picking the wrong options.”… “Yes, test suites might help – it’s been almost a decade, where are the JOSE test suites… where is the language and test suite that deprecates alg=none and fails implementations for not deprecating it (or HMAC/signature algorithm confusion)?”. As you can guess, those conversations have been going nowhere for the better part of a decade.
So, we’re actively doing something about it by demonstrating that it is not only possible to ratchet the attack surface around cryptographic library implementations down and protect application developers from themselves, but that it’s necessary to standardize tightly controlled combinations of cryptography (cryptographic suites), and actively test implementations against a conformance test suite that is maintained by the Working Group. This is active work that’s been going on for a while now, and we’re in the last two years before we standardize such a mechanism. I invite you to contribute to the discussion, if you have the time via the IETF CFRG, W3C VCWG, or Github issue trackers for Data Integrity. We’d love to have your input as we create safer cryptographic standards led by the principles you have written about in your blog.
Once upon a time I was trying to explain the problems with JWT to someone who allegedly was a “security person”, and that person told me, in about as many words, that all the vulnerabilities were due to bad developers using dynamically-typed languages, not due to the combinatoric explosion of stuff JWT forces you to think about and either defuse or disable.
Unfortunately, JWT still ended up winning in both that debate and most of the SSO protocols :/
And as an aside: I’ve been fighting against JWTs in Django for years, on similar grounds, and so far have been winning that fight. There are a bunch of third-party add-ons to Django that will give you JWTs if you really want them, though.
Thanks for resisting JWT in Django. This builds up my confidence in Django as a Python framework. :)
This makes me feel ok about my choice to use a zero-options protocol (SecretHandshake) for my project. I really like the simplicity.
I’m a bit concerned about hardcoding Ed25519 public keys as user identities; but it looks like whatever replaces elliptic curves will use godawful-long keys so they’ll be easy to distinguish from the current 32-byte keys without needing any metadata.
Great overview of the approaches, their ups and downs. I think one approach not taken as much but kind of sits in the middle of versioning and agility is the cryptographic suites approach. In this one, instead of allowing the user to select from a set of pieces (this hash, that encryption algorithm, this signing algorithm) a “suite” is fully named and specifies how all the pieces are used. Somewhat like a version number, you’re taking a vetted set of things at once, but it doesn’t necessarily have one single incrementing path.
I’m not an expert in cryptographic areas, so I won’t say “this is what you should do!” but I will say I think it’s an interesting approach, worth highlighting as the possible tradeoffs are expressed.
To me it sounds like versioning except strictly less good. For each particular use case you’re going to have a single Best Choice, so why not just use that suite and call it V1, and if a better one comes along you just use that one and call it V2?
There can be situations where there are multiple best choices, depending on what you are running on. Embedded devices often have accelerators for cryptographic functions, and what functions perform best depends on the chip. If you have multiple products with different chips in them, that talk to the same service, then you may need multiple different suites for each one to perform at it’s best.
That sounds like a great way to shoot yourself in the foot. Cryptography is complicated enough, adding more complexity is inviting trouble where one probably doesn’t need it.
Having n working versions isn’t that much more complicated than having 2 versions, one of which is in progress of deprecation. You still need version identifiers, and you still need to use appropriate algorithms for each version. The only problem is that there is a larger attack surface in the systems that need to interact with all of the versions, but in the use case I suggested, it usually is the control system, and is usually a lot easier to update than the embedded devices. From the embedded device point of view, there is only a single version of the protocol.
This is a really good read of how easy it is to fall short especially when expanding in terms of breath and complexity.
As you wrote already on your blog post : allowing for everything is just dumb, so I do not really understand why all of your cases that you presented allow user to do anything and everything.
To shorten it, let’s establish a short glossary: CA – crypto agility
First, let’s separate the concerns – language is abstract, design is abstract, we are talking not about specific implementations like JWT, SSH or anything – we are talking about CA as a concept. There are better and better and worse implementation out there and very different usages depending on application.
Because every implementation of a design that prioritized Crypto Agility inevitably fucked up in exactly this way.
Real world cryptography is messy and full of mistakes.
I blog as my fursona, which I keep totally separate from my legal identity as much as reasonably possible.
Most of the real world examples I could point to for why agility fails are under my legal name, and also restricted by NDA. This forces me to take some liberties in how I write.
If you want to cross examine my experience (without forcing me to put myself in a legally precarious situation), simply ask other cryptography/security experts if their experience matches mine. Preferably one that you’re paying for their time, so that their incentives are aligned with your interests, not mine.
Every solution that avoided the “allow everything stupid” pitfalls began with the premise of not doing Crypto Agility (i.e. WireGuard), or only doing minimal Crypto Agility (i.e. PASETO).
I do not care. Honestly, I’m not concerned with your social interactions. IMO, At the very moment you mix those things into discussion about the technology, which is ruled by specifications, RFCs, and is known for being precise, the strength of your arguments falls to the ground. I would also advise not to bring lawyers, sociology, gender, religious or political beliefs, race, or other non-technical things to the technical discussion; since those are both confusing to the readers and brings nothing to the table – just a free tip for the future.
Does every implementation have done it? Mine was fine, it had no such problems that you mentioned? Was it good? fuck no – but does that mean that you saw what I wrote? Does that mean that you saw everything other people wrote? Are you saying you are an all-knowing being from another dimension, granting us your wisdom?
You clearly said that all CA is wrong, but you do not know all the applications of it. Moreover, your core understanding of CA is very wrong. I wrote about that before.
To me, a sentence
sounds like a fancy version of
It’s like saying
a.k.a.
"a word salad".Long story short – I am on the other side of the fence. What you are writing is being dishonest to the work i’ve done, and the work of other developers in the field. That’s why I started this discussion.
That is also the reason I postulate that you are deliberately either:
If you are not, then you have my sincerest, apology, but your last comment does not strike me as convincing – at least to this point.
That’s again a lie, so let me rephrase that for you:
"Every solution that I know or noticed did that". And that would be a valid statement, and I would totally emphasize with you. But, clearly, the one I was working on didn’t have such problem, and I already wrote why. Allow me to clarify that again, in simpler words, so it will be easier to understand – CA is like a pattern, a tool, let’s say a gun. Some guns are terrible, some are at least okay-ish, but clearly you got a bad one – you cheeped out, it blew your face off, and now you are ranting that all of them are bad. That is a very childish approach.Conclusion? If you are writing about your experiences, state it as such. Do not discredit or disregard other people’s work. What you wrote is good in theory as a beginning of a debate or a precise and directed rant, but not as an article stating the fact. If for every fallacy you committed I would get a dime, I could buy myself a very good coffee now.
“I created an account just to comment on this post on Hacker News, and then created a Lobsters account less than an hour later to post a negative comment here too” - Someone who doesn’t care, apparently
Which IETF working group do you think is responsible, exactly, for my personal blog where the article was published?
There are no real “rules” for personal blogs. I write in a conversational English style. I use furry art at my discretion to punctuate my points. Some people dislike it. I simply increase the amount of furry art I use when people complain.
This is a lot of unsolicited advice from someone who doesn’t care.
I’m not going to bother reading the rest of your comment. You should familiarize yourself with the Lobsters rules. We strive to be more positive and constructive than HN or Reddit here.
Also, if you think your implementation is special and perfect, at least have the decency to drop a link to the source code so it can be critiqued.