Hacker News Reader

Comment by andrewstuart2 | Hacker News Reader

An easy enough mantra: sign bytes, not semantics. I've trudged through the bowels of SAML long enough to know that canonicalization is thoroughly tricky and annoying to deal with.

I don't care what you throw in the bytes; I can figure that out easily enough. I want to know who generated those bytes and that they haven't changed.

For this reason also, I think the "reach for symmetric first" is bad advice. The primary benefit I can think of for HMAC is if you want to store client-side state for more stateless browser-targeted services. It makes it easy to throw an obscure cookie to your client and then validate it on the way back. It seriously complicates things if you want to allow other people to validate provenance of those bytes. With symmetric crypto, as soon as you can validate you can also generate. That's not the system we want.

View on HN

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.)

But 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.

What'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?

Signing 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.

Oh, 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.

If 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.

Partially 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.

Pinned 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?

Right. 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.

Hi hi, I'm a TUF guy, so feel free to ask questions!

https://theupdateframework.github.io/

Also see how we took it further at Datadog:

https://www.datadoghq.com/blog/engineering/secure-publicatio...

(Trishank also lifts so he is a tough TUF guy.)

Aw, shucks!

I thought the point of doing validation locally with the key was mainly performance? You do this mostly to AVOID the round trip of having the 3rd party do the validation (sub-ms to do validation with a shared secret or rsa key; vs multi-ms and complexity for an HTTPS API call).

...and once the validator becomes slow or unresponsive, the rest of the system follows

I 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 :)

Eh? 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.

Re: 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?)

Ah, gotcha. That sounds like token introspection basically, which is a (budding?) standard, not really userinfo.

Unless 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 :-)

I would think a "Pre-auth" endpoint that can be called for user information is not what consumers want...

I mean pre-auth in that you pass it a JWT with a shared credential that it parses for you, as opposed to an explicit auth'd credential.

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

This multi step interaction has some spectacular failure scenarios.

> spectacular failure scenarios

Such as? Any of them different than that of the suggestion I was replying to?

It's a good mantra--just not a wish that is applicable to the foundation of XML as a tree/document thing that self-describes its encoding and is capable of including its own signature within itself. I mean, it gets crazy complex, but the alternatives sort of require going on to some message format that isn't XML. One of the design goals of XML is that you could zip an XML document along through different systems, one of which supports only UTF-16LE, the next demands UTF-8, the next demands ISO-8859-1, and each could do the right thing. I mean, it's almost inconceivable that all the systems involved in such a quagmire would actually do the right thing, but they could, in theory. I'm sure you're already dreadfully familiar with this having looked at XML-DSIG.

OTOH: base64(jsonString(envelope)) '.' base64(jsonString(claims)) '.' base64(sig) works fine for JWT, because JSON has a very much limited choice of encoding (one option, zero alternatives!) and a JWT has no requirement to still be JSON on both sides of the transformation. It's just an opaque 7-bit-safe string to any party that doesn't know what the contents are.

> I don't care what you throw in the bytes;

I do think whoever is coming up with the scheme for assembling those bytes should care a lot. Specifically, whenever you're signing something, you have to pay attention to whether that something still has exploitable ambiguities. Most of those come from how you delineate the fields in the thing you're signing, which is a classic "you find out what you missed when someone sends you a CVE" type of problem. So you're right back to the problem of "if not JSON or XML then you're still rolling your own."

I agree with "reach for symmetric" in this sense: what are you trying to accomplish? Prove the data came from a specific source or that they are who they claim to be? Can you just use TLS with mutual auth? Prove the data came from yourself? Symmetric is probably okay.

When you need verifiable attestations of data from parties that don't talk to each other... welcome to the jungle.

> canonicalization is thoroughly tricky and annoying to deal with.

The bitcoin malleability problem was the same issue, just with ASN.1 instead of JSON.

Sign bytes makes a lot of sense. But you’re still on your own for how that “should” be done.

Obviously you need to build and hash the pairs and not just key values. But the order is obviously important too.

Is there some standard for this I don’t know of?

Sort the keys alphabetically usually comes up.

Hmm, interesting idea but I’m in embedded C. So that’s something I’d rather not do but I like the idea.

You generally don't need canonical representation.

Reply on news.ycombinator.com