design: covering publisher authenticity

[lucab]

Followup from https://twitter.com/BrandonPhilips/status/1158428113283379200

From FAQ:

Q: Why not use GPG keys or other public key signing? A: This is complimentary to public key signing! Public key signing asserts that someone with access to the private key signed the exact content. [...] If the URLs contents are both signed and logged in the URL content record then there is a guarantee that both the owner of the private key signed the content AND the content being fetched is cryptographically identical to the content other people are fetching using rget.

Those are indeed complimentary, and to the best of my understanding rget only covers integrity of content and leaves apart publisher authenticity. However, it would be interesting to explore whether there is some way to also have the signature part covered by the transparency log.

In particular, it would be interesting to see if a minisign flow could be integrated here somehow.

[philips]

@lucab Sort of. It asserts publisher authenticity in the same way that GitHub does: it verifies a URL under the control of the author.

How do people usually publish the public keys for minisign?

[lucab]

Key distribution does no have a single answer, but the fact that the key is relatively small makes it easier to embed somewhere else, and there is no keyring nor web-of-trust to manage.

Few existing cases:

• OpenBSD, prior knowledge: /etc/signify/openbsd-XX-base.pub (see http://www.openbsd.org/faq/faq4.html#Download(
• OpenBSD, out of band: https://ftp.openbsd.org/pub/OpenBSD/6.5/openbsd-65-base.pub
• minisign, prior knowledge: project README (see https://github.com/jedisct1/minisign)

[philips]

I guess the best thing to do would be to put the public key in a SAN so a key rotation would show up in the transparency log directly.

WDYT?

Where do GitHub projects usually store the keys?

On Tue, Aug 6, 2019, 6:50 AM Luca Bruno notifications@github.com wrote:

Key distribution does no have a single answer, but the fact that the key is relatively small makes it easier to embed somewhere else, and there is no keyring nor web-of-trust to manage.

Few existing cases:

• OpenBSD, prior knowledge: /etc/signify/openbsd-XX-base.pub (see http://www.openbsd.org/faq/faq4.html#Download(
• OpenBSD, out of band: https://ftp.openbsd.org/pub/OpenBSD/6.5/openbsd-65-base.pub
• minisign, prior knowledge: project README (see https://github.com/jedisct1/minisign)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/merklecounty/rget/issues/18?email_source=notifications&email_token=AAAIGCHAMCHEF4MELDJCUSLQDF6RNA5CNFSM4IJUJEQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VGK7Q#issuecomment-518677886, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAIGCGYJF2IU5RV7KMNXTDQDF6RNANCNFSM4IJUJEQA .

[mricon]

I don't think we need to put the public key into the SAN, but the actual minisign signature of the SHA256SUMS file. The public key can have its own certificate record.

[lucab]

I unfortunately don't have enough context about the flexibility of Let's Encrypt and Transparency infrastructure to give reasonable design feedback at this point, sorry.

For the publishing part, again I don't think there is a single answer, so you probably have some space to establish conventions. On top of the one I listed above, the only other relevant one I know on github is libuv, which publishes GPG fingerprints as free-form text in MAINTAINERS file.

[philips]

@mricon What do you mean by the public key can have its own certificate record? Like $hex-encoded-public-key.minisig.rget.merklecounty.github.com.recorder.merklecounty?

@lucab I feel the public key needs to end up somewhere in the CT log. If it just remains in a file on GitHub then that file could be updated just like files in the releases so it won't provide any additional guarantee if an attacker has GitHub access.

[mricon]

@philips I think so, but we also need a way to point the record to a different namespace. The situation I am trying to prevent is an attacker getting control of the project's domain (e.g. kernel.org) and then being in a position to MITM the release process (i.e. they substitute the tarballs and SHA256SUMS before our own script runs and records them in the CT records). Having minisign public key record live in the same kernel.org domain space won't protect against this the same way PGP signatures protect us now.

Should I take this to the list instead of using this issue?

[philips]

@mricon I just created a mailing list if you prefer to discuss over email.

[knisbet]

@philips the mailing list doesn't appear to be accessible. I'm not sure if this is intentional or not but I got this error from the link on the readme as well:

This group either doesn't exist, or you don't have permission to access it. If you're sure this group exists, contact the Owner of the group and ask them to give you access.

[philips]

Weird. Not intentional. AFK ATM will investigate in a few hours.

On Tue, Aug 6, 2019, 5:51 PM Kevin Nisbet notifications@github.com wrote:

@philips https://github.com/philips the mailing list doesn't appear to be accessible. I'm not sure if this is intentional or not but I got this error from the link on the readme as well:

This group either doesn't exist, or you don't have permission to access it. If you're sure this group exists, contact the Owner of the group and ask them to give you access.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/merklecounty/rget/issues/18?email_source=notifications&email_token=AAAIGCBIM57JXN4RN253NBLQDIL75A5CNFSM4IJUJEQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3W3SKY#issuecomment-518895915, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAIGCDZBLGEE74HSQLHPKLQDIL75ANCNFSM4IJUJEQA .

[lucab]

@philips I do agree on recording the pubkey somewhere in the CT logs. Assuming you are fine with coupling a bit more rget to minisign, I think this ticket and https://github.com/merklecounty/rget/issues/17 can be tied together in a single flow.

It could go like this:

• CD system has public+private keys (ephemeral ones, generated per-release and thrown away after signing, are fine here as well)
• CD builds artifacts, computes SHA256SUM, and minisign the latter.
• CD uploads all of the above to Github (or other platforms)
• CD performs a rget submit --pubkey foo https://url.to/SHA256SUM.minisign
• recorder checks that the signature is valid and certifies both the signature-url and the pubkey on CT logs

From that point on, rget can detect both changes in the release artifacts AND in the pubkey used for signature. This opens five scenarios:

• if the key is ephemeral and the digests+pubkey changed, rget detected somebody forging signatures
• if the key is long-living and the digests+pubkey changed, rget detected somebody forging signatures
• if the key is long-living and the digest changed but the pubkey did not, rget detected the publisher themself updating the artifacts
• if the key is ephemeral and the digest changed but the pubkey did not, rget detected that the publishing pipeline have been compromised and the ephemeral keys are being captured on-the-fly
• if submit fails due to mismatched pubkey, rget detected that there is a MITM ongoing in the publishing pipeline (see https://github.com/merklecounty/rget/issues/18#issuecomment-518741930)