4 ms·

I took a look at the design and think there are a few issues with the format as proposed. # The public key is stored with the signature. This should be stored

by dlor 5y ago

I took a look at the design and think there are a few issues with the format as proposed. # The public key is stored with the signature. This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys. # The algorithm is stored with the signature. This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35 https://github.com/secure-systems-lab/dsse/issues/35 I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.

trishankdatadog 5y ago
> >The complexity designed into this system might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as, say, devising an in-toto root layout. Most open source projects should really just worry about subscribing to something like PEP 480 and signing with one-time Fulcio keys. But I think we are largely on the same page here: yes, please just minisign/signify if you want simplicity, but if you want resilience from nation-state attacks, you need something like TUF (coupled with in-toto and sigstore). We are happy to advise.
- arkadiyt 5y ago
  > I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as ... I've heard great things about TUF but if you want people to adopt it then it seems like the documentation/tutorials/tooling should be a first class citizen
  - joshuagl 5y ago
    Thanks for your comment. I completely agree, and we are working on it. If you have any suggestions for documentation/tutorials/tooling you would like to see, I'd be happy to add them to the list. We are actively working to improve reference implementation, to make it easier to maintain (easier to read code, type annotations, generally more Pythonic, cleaner design) and use (cleaner documented API, easier to plug in your own implementation of things a content update system might already have an opinionated implementation of -- i.e. the network communication stack). We hope to build more tools on top of the cleaned up reference implementation once it is feature complete. For the specification itself, we recently switched to publishing a rich HTML document with cross-linking, syntax highlighting, ToC, etc. https://theupdateframework.github.io/specification/latest/ https://theupdateframework.github.io/specification/latest/ and added a new section covering some of the repository operations https://theupdateframework.github.io/specification/v1.0.19/#adding-updating-targets https://theupdateframework.github.io/specification/v1.0.19/#...
thayne 5y ago
Interestingly, the reference implementation doesn't seem to include the algorithm, which is hard coded. But that means the reference implementation is inconsistent with the described format.
- julian-klode 5y ago
  Yes, the implementation lacks behind a bit. Project's been stale a few months
julian-klode 5y ago
I don't understand your point about the public key. The goal is to be able to verify all signatures; whether we trust a signature or not is configured inside APT by specifying a list of trusted primary keys. > # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad Which algorithms are trusted is a client side decision. We do need the string to be able to parse the signature itself. signify also has it, except that it includes it inside the base64 as the first two bytes. I do not believe there is a need to be able to configure the trusted algorithms on a per primary key basis (aka storing it with the public key). Basically the problem we have with GPG is that it trusts algorithms for far too long. So we had to implement lists of trusted algorithms inside APT ourselves. We still have no way to reject 1k RSA keys, though, because GPG does not tell us the key size. We can assign algorithms trust levels and prevent downgrades to weaker keys alongside the other downgrade attack checks for Release files we already have in APT. > I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Yes, well, if you go with the subkey approach you'll always have a subkey, so you can't sign directly with a primary key. I think there's some confusion here in that people believe both formats should be supported at the same time, but they are two separate proposals, and only one should make it into real code. > Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I've said it 4 years ago - we don't want TUF. TUF does not provide useful things, but adds (duplicates) a lot of complexity. It's the opposite of what we're trying to achieve here. https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine-for-apt-repositories/ https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine... Add to that that we'd have to rewrite the whole thing to use YAML/deb822 instead of JSON files for repository format compliance.
- julian-klode 5y ago
  > # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad So I just also realized that for the subkey scheme, it matters even less, because the algorithm is effectively part of the subkey packet. It's not encoded in there, but how high is the chance that a different algorithm would produce the same signature for it? We really just need the algorithm field to be able to determine how to parse that, but it reinforces itself by virtue of the subkey being signed by the primary key itself.

by dlor 5y ago

trishankdatadog 5y ago

> >The complexity designed into this system might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as, say, devising an in-toto root layout. Most open source projects should really just worry about subscribing to something like PEP 480 and signing with one-time Fulcio keys. But I think we are largely on the same page here: yes, please just minisign/signify if you want simplicity, but if you want resilience from nation-state attacks, you need something like TUF (coupled with in-toto and sigstore). We are happy to advise.

arkadiyt 5y ago
> I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as ... I've heard great things about TUF but if you want people to adopt it then it seems like the documentation/tutorials/tooling should be a first class citizen
- joshuagl 5y ago
  Thanks for your comment. I completely agree, and we are working on it. If you have any suggestions for documentation/tutorials/tooling you would like to see, I'd be happy to add them to the list. We are actively working to improve reference implementation, to make it easier to maintain (easier to read code, type annotations, generally more Pythonic, cleaner design) and use (cleaner documented API, easier to plug in your own implementation of things a content update system might already have an opinionated implementation of -- i.e. the network communication stack). We hope to build more tools on top of the cleaned up reference implementation once it is feature complete. For the specification itself, we recently switched to publishing a rich HTML document with cross-linking, syntax highlighting, ToC, etc. https://theupdateframework.github.io/specification/latest/ https://theupdateframework.github.io/specification/latest/ and added a new section covering some of the repository operations https://theupdateframework.github.io/specification/v1.0.19/#adding-updating-targets https://theupdateframework.github.io/specification/v1.0.19/#...

thayne 5y ago

Interestingly, the reference implementation doesn't seem to include the algorithm, which is hard coded. But that means the reference implementation is inconsistent with the described format.

julian-klode 5y ago
Yes, the implementation lacks behind a bit. Project's been stale a few months

julian-klode 5y ago

I don't understand your point about the public key. The goal is to be able to verify all signatures; whether we trust a signature or not is configured inside APT by specifying a list of trusted primary keys. > # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad Which algorithms are trusted is a client side decision. We do need the string to be able to parse the signature itself. signify also has it, except that it includes it inside the base64 as the first two bytes. I do not believe there is a need to be able to configure the trusted algorithms on a per primary key basis (aka storing it with the public key). Basically the problem we have with GPG is that it trusts algorithms for far too long. So we had to implement lists of trusted algorithms inside APT ourselves. We still have no way to reject 1k RSA keys, though, because GPG does not tell us the key size. We can assign algorithms trust levels and prevent downgrades to weaker keys alongside the other downgrade attack checks for Release files we already have in APT. > I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Yes, well, if you go with the subkey approach you'll always have a subkey, so you can't sign directly with a primary key. I think there's some confusion here in that people believe both formats should be supported at the same time, but they are two separate proposals, and only one should make it into real code. > Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I've said it 4 years ago - we don't want TUF. TUF does not provide useful things, but adds (duplicates) a lot of complexity. It's the opposite of what we're trying to achieve here. https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine-for-apt-repositories/ https://blog.jak-linux.org/2017/08/17/why-tuf-does-not-shine... Add to that that we'd have to rewrite the whole thing to use YAML/deb822 instead of JSON files for repository format compliance.

julian-klode 5y ago
> # The algorithm is stored with the signature. > This is slightly less bad than above, but still bad So I just also realized that for the subkey scheme, it matters even less, because the algorithm is effectively part of the subkey packet. It's not encoded in there, but how high is the chance that a different algorithm would produce the same signature for it? We really just need the algorithm field to be able to determine how to parse that, but it reinforces itself by virtue of the subkey being signed by the primary key itself.