Hacker News Reader

Comment by giaour | Hacker News Reader

I think you're conflating the 'seal' and 'sign' use cases. I'm not sure how one could design a secure system where encrypted cookies could either be read by everyone (encrypted with private key) or forged by everyone (encrypted with public key), but using public keys to validate that an attestation was signed by a trusted third party is both sound and commonplace.

For example, this is how identity tokens from AWS Cognito are verified. They are RS256 JWTs signed with Cognito's private key, and any server can download Cognito's public key to validate that the tokens were issued by Cognito and haven't been subsequently altered (without having to make a network call to Cognito to request validation).

View on HN

On that note: https://github.com/paragonie/past/issues/13

I might be dropping "seal" entirely, as its utility isn't really a good fit for security tokens. (Sealing APIs can be very useful in other contexts, though.)

Was just going to post this, JWT with public keys is very handy for stateless verification of claims, which is what it seems was the primary motivator of the spec.

As someone who had to work with XML-DSIG, JWT seems less bad :)

You don't need public-key crypto to do stateless verification of claims. Secret-key crypto does that just fine. You need public-key crypto if you want _other people_ to be able to verify the claims -- that's an important distinction, because it specifies what you're buying for your much more complicated crypto.

Public keys solve the key management problem. If you have just one or two tiers it's not a problem.

If you have thousands, you end up spending a lot of time on key distribution if you need individually distributed secret keys.

You say that, but best practice for systems that have that option (say, internal SAML IdPs) still means you do per-peer keys with the annoying key management problem so that you get cryptographic binding instead of relying on a bunch of broken RPs to validate audience restrictions (spoiler: they don't) and in some cases IdPs or middleboxes that need to add audience restrictions (spoiler: they don't either).

What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.)

What do you mean by "tiers" here? The specificity of that word suggest you don't just mean "peers", but at the same time clearly symmetric systems win at nested delegation. (krb5, macaroons come to mind)

> What you get is that the peer can't forge tokens. But you're trying to authenticate to them; they already have full authority. So what are you fixing? (I'm not saying it's "nothing", but I am saying it's very little, and it's definitely plausible the increased risk isn't worth it.)

You get something you can show to a third party: 'see, the bank said their client was good for $10,000!' I can see where that might be useful.

This feels like grasping at straws.

I don't think I could've made my own point this elegantly. Eventually trying to disprove what the other party is saying is literally the opposite of what normal token schemes (say, SAML or OIDC JWT) is trying to accomplish: trying to establish what the other party is claiming.

Or stateless verification when "other people" are allowed to create claims. There are certainly federation scenarios where PKI alone could be sufficient (as opposed to complex handshakes such as OpenID Connect or SAML). Obviously in accepting those claims you get to treat every claim with a giant grain of salt, but there are auth models where that makes sense (the only claim I need to trust is the certificate itself scenarios, for example).

That said, very few people want such a security scheme and as theoretically simple as it is on paper, it quickly ramps up to the real world complexity of PKI key management.

(I could see a small use for web APIs for developers and power users that allowed, for instance, Keybase-verified claims like HN account name/FB name/email, for very simple and easy to curl/iwr/httpie from the command line using Keybase-managed keys.)

I'm not sure if that small window of opportunity is worth the support complexity in PAST here, but given the model of support only specific versions, having them as separate verbs (sign/seal) makes it easy to block claims you don't expect. The one flipside from an API design standpoint that I see is that leaves a need for some sort of header like X-Accept-PAST: v2.auth

I’m not sure I follow: if the other party is allowed to create claims too, symmetric crypto seems more obvious. That’s what NS (and later KRBv5) did in the seventies. Or is that precisely what you’re saying?

In a stateless, negotiation-less flow where you have no pre-existing relationship with the other party? Isn't that exactly the bootstrap that PKI was built for?

Aha, I missed the stateless negotiation-less flow. But yes, that's basically TLS as deployed in browsers :)

Kerberos vouching hinges on "ticket-granting server says...", and you know that because the tgt shares a secret with every player. On the face of it, it'd be much easier to just demand everyone know the tgt's public key (no need for N keys on the tgt for N participants).

I've long considered the merits of a kerberos-like system built on top of something like nacl... But without out-of-the-box support from all kinds of systems... It'd essentially build down to ssh+certificates with expiration dates... So i've gathered "better CA for ssh" is the better product. And there are thankfully a couple of projects in that vein (teleport, netflix/bless, others?).

[ed: i should add: I think tptacek is absolutely right about public key systems being easier to get wrong; but part of that is also the problem domain: look at the history of security issues with Kerberos (both implementations and protocol evolution) for a great example. On the face of it NxN key exchange is "text book simple; should be easy to define, a little tricky to scale". Then there's replay, clock drift, (de)serialisation, nounces, large number of session keys (secure random numbers)...]

I don't understand the conflation. 'tptacek is arguing that you preferentially use secret-key crypto to public-key crypto, because public-key crypto is significantly more precarious. It seems like you are raising a new point, not arguing with his.

tptacek was saying everyone should be cautious about PKI-based JWTs and provided encrypted cookies as an example of something that is rarely (if ever) implemented safely and securely with PKI cryptography. My point is that while the 'seal' function of PAST may be of questionable value, the 'sign' function is not. I think it's important to disambiguate those two uses of asymmetric cryptography.

Gotcha, thanks! That makes more sense now.

I agree that they're worth examining separately, but the more general point still stands that there is a lot more that can go wrong with sign than with aead. The arguments for broken RSA-encrypted cookies apply similarly to broken signed cookies. It's not clear to me for example that an invalid curve attack against seal is intrinsically worse than a nonce (ab|re)use bug against ECDSA.

Reply on news.ycombinator.com