6 ms·
You say that's not the system you want but that's based on a pretty big "if": you need "someone else" to validate something, and those people can't talk to you
by lvh 7y ago
You say that's not the system you want but that's based on a pretty big "if": you need "someone else" to validate something, and those people can't talk to you directly and ask you if it's valid or not. That's not in practice how we see this being used.
If you do need third parties to validate, a much simpler API is to just ask the thing that holds the HMAC credential over TLS, and have it return true/false. That makes it harder to demonstrate non-repudiation, but I'm not convinced that's a property you generally care about. Even in OIDC (which mandates a JWT, but for reasons that defy understanding doesn't mandate cryptographic domain separation between (IdP, RP) pairs), leading OIDC providers have long recommended you just talk to them over TLS to get userinfo. (GSuite has recently muddled this in their docs, which irks me.)
(Disclaimer: I'm the author.)
- ysleepy 7y agoBut what about myself wanting to validate the payload on a system I don't necessarily trust? In the symmetric case I would grant that system the ability to sign.
- lvh 7y agoWhat's the model where you don't trust that system not to exfiltrate data but you do trust that system not to flip the boolean that says the signature is valid at all?
- ysleepy 7y agoSigning your updates for example. If the system is breached, theres nothing you can do, but that access does not translate to forging updates for other users.
- lvh 7y agoOh, sure, yes, absolutely, software updates is one of the cases where you probably just want an (asymmetric) signature. (And probably TUF.) But my alternative suggestion also addresses that: in a model where you don't trust the host with the key but you do need to help it make a determination if a particular thing is valid or not, you could just go ask the server you got it from instead. Basically: the key doesn't have to live on the machine doing the validation.
- tastroder 7y agoIf you get a malicious update from a compromised update server and then ask said server if the hash you got is correct, you might as well just roll a dice. You'd need a pinned certificate (e.g. for HTTPS) to prevent MITM and thus asymmetric crypto anyway.
- lvh 7y agoPartially yes. You don't need a pinned certificate, just working certificate validation. I am not suggesting you should never use asymmetric crypto: you should definitely use HTTPS. The question wasn't "is asymmetric crypto morally good or bad", it's "should I use asymmetric crypto in my code to do bespoke signing things". The asymmetric crypto in TLS is fine because you're not doing bespoke signing things: you're doing the most well-understood handshake + protocol on the planet.
- tastroder 7y agoPinned or validated, you need to know that you can trust the server locally. I was just addressing the "ask the server you got it from instead. Basically: the key doesn't have to live on the machine doing the validation." part in your alternative, signatures seem kind of moot if you cannot verify the server is who it is supposed to be from the client's point of view. There's no benefit of signatures over any regular hash here, right?
- lvh 7y agoRight. As I mentioned, you're just moving the signature from the blob itself to HTTPS, and if all you care about is validating a file you'd just make that a hash. Analogously to a SHASUM file, but the authentication coming from HTTPS/WebPKI instead of something ending in .asc. One critical point is that the two servers do not have to be the same. You might distribute your files via a CDN like CloudFront (or if you're in the 90s and a Linux distribution, a ragtag team of servers that don't generally implement https). The server responsible for delivery can lie all it wants; the server responding if something is valid is what actually matters.
- forty 7y agoI worked on system that used HMAC to authenticate (similar to what AWS signature does, which has the nice priority of never transmitting the secret), and the reason why I feel it would be better with asymmetric signature is that HMAC forces you to have the secret in clear server side, which means they can be stolen, while with an asymmetric system that would not be possible. Of course the ideal system probably use asymmetric signature to get a short lived secret used to sign all the requests of the session :)
- hirsin 7y agoEh? Got additional details on which OIDC providers aren't using a proper userinfo + AT? Not that that shouldn't include TLS... We don't do token introspection (basically what you're referring to) and instead use JWT/JWE(soon) to reduce round trips for the RP. Could you expand on the OIDC issue with cryptographic domain separation? Not sure I fully understand what benefits you're looking for there.
- lvh 7y agoRe: OIDC providers: to be clear, you absolutely can just parse the JWT. I'm saying that (up until recently, if memory serves) e.g. the GSuite documentation told you that while you can validate a token, that's hard, and instead you can just hit this HTTPS API and we'll tell you what's in it. (They seem to have flipped that in the last, I dunno, 3 months or so?)
- hirsin 7y agoAh, gotcha. That sounds like token introspection basically, which is a (budding?) standard, not really userinfo.
- lvh 7y agoUnless my memory is failing me, in the Google case it was really /userinfo (as in the OIDC Core UserInfo endpoint) and not token introspection (a "post-auth" endpoint taking a token, not a "pre-auth" one you pass a JWT to). Though I agree that from the perspective of a consumer the two are basically just as good :-)
- DenisM 7y ago> holds the HMAC credential over TLS, and have it return true/false And if you're connecting to the original party anyway might as well not even use HMAC or any crypto at all. When "signed" data needs to be sent to the client don't send it at all, instead store the data locally under a GUID and send that GUID to the client. When client takes their GUID to another party, that other party connects to the original party and retrieves perfectly authentic data. Free bonus - faster client performance. Best crypto is absence of crypto.