Re: Keys/Signature use in OSTree/Flatpak/Flathub

[Alexander Larsson <alexl redhat com>]

On tis, 2016-10-04 at 10:55 -0400, Colin Walters wrote:
> On Fri, Sep 30, 2016, at 09:36 AM, Alexander Larsson wrote:
>
> > Walters, I know your current plans are more about relying on
> > SSL+cert
> > pinning for metadata. What are your opinions on something more
> > complex
> > like this?
>
> It's a huge amount of work, not just to implement in code, but also
> in
> maintenance for server operators.

I don't disagree here.

> I don't disagree that TUF has a strong threat model, but what I would
> say broadly is that if you compare it with pubkey-pinned TLS to a
> centralized
> metadata server, a lot of the advantages drop away.

Does ostree/libsoup support pinned TLS atm?

> For example, I'd say cert-pinned TLS addresses the "freeze attack". 

It does address the freeze attack, but I worry about the gpg key being
exposed. I'm not sure how exactly you imagine the setup to be. The
pinned TLS guarantees that we're talking to the right server. Then we
need to verify the summary with a gpg key, and then the commits.

There are two issues here that I see:

1) Sharing the same key for summary file and commits means that
whenever anything changes in the whole repo we need to re-sign
everything. Generally this means that the one key needs to be available
both during build (commit) and on the infrastructure (summary). That
means an attack on the server can expose the key and allow arbitrary
code execution. If we had different keys for the summary and the
commits then only the summary key would need to be on the
infrastructure, and the commit key on the build machines.

2) In a repository that acts mainly as a redistribution mechanism for
content that have been build by multiple sources, the lack of commit
key signature delegation is problematic. Take for example a generic
flatpak "app store" repo. I would like to be able to say "branches
starting with app/org.spotify.Spotify/ must be signed by this key", and
sign this statement with a repo-specific key. Then spotify could sign
their own builds, and the app store keys wouldn't need to be (much)
involved with spotify doing an update.

> So basically I assert that combining two well known and proven
> technologies:
>
> - GPG signatures for *static* assertions (yes, no revocation, but
> that's
>   just how it works and everyone understands that)
>   (Alternatively, one can use something other than GPG, like alpine's
>   use of simple ed25519 signatures)
> - pubkey-pinned TLS to a centralized (metadata) server
>
> Mostly addresses the TUF threat model.

Oh, wait, do you mean that we would have *unsigned* summaries, and
instead relying on TLS for MITM protection, and the metadata public-
facing server security (rather than the signature on the summaries) for
protecting the metadata? 

That strikes me as rather insecure, compared to signing the summary on
an non-public-facing server and then rsync:ing it to a public facing
http server.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a fiendish chivalrous photographer whom everyone believes is mad. 
She's a sharp-shooting insomniac vampire living homeless in New York's 
sewers. They fight crime!