Re: [saag] On PKI vs. Pinning (SAAG 108 preview)

[Benjamin Kaduk <[e-mail]>]

Hi Stephen,

Thanks for the quick response :)

On Tue, Jul 28, 2020 at 08:36:33PM +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> Good topic.
> 
> On 28/07/2020 20:13, Benjamin Kaduk wrote:
> > Can we make a classification of what types of protocols are naturally
> > suited for PKI scenarios and what types of protocols are naturally suited
> > for pinning?
> 
> FYI, in our survey of covid-tracing Apps most but not all
> of them do pin. When those apps are uploading keys, it'd
> not be good for that to be logged in an enterprise security
> appliance. That seems to generalise to any applications
> where the relevant entities would not like their data to
> end up logged like that (by accident or design), and where
> the application not working when behind a MITM is ok, or
> where one can expect the application to be whitelisted by
> such MITMs. ISTM that may be a fairly broad class of
> applications, certainly enough to be of interest. I'd
> guess some of the operators of MITMs might prefer to not
> be able to see some of that application data too.

There does seem to be something significant here, yes.
I gave an example of a banking app that would pin, and it's not entirely
clear to me whether "the application not working when behind a MITM is ok"
applies to such an example.  So there's some classification work left to
do.

> > 
> > If you're going to pin, how does it matter if you pin a (raw) public key, a
> > self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA,
> > etc?
> 
> Raw public key seems too much a foot-gun. Even with
> pinning, you still need to depend on a CA for TLS, so
> it seems to make sense to pin to your currently
> preferred CA(s) plus one other independent CA. We've
> seen that in at least one of the above apps.
> 
> I'd guess the choice of root vs. intermediate might
> depend, not sure there's an obviously correct choice
> for that, for all cases.
> 
> > 
> > Is there benefit in arranging for a description of the system where the
> > ability to pin is just a degenerate case of a PKI, with a single trust
> > anchor and no real hierarchy?
> 
> I don't get the question sorry.

Sorry for the clumsy description.  Basically, if you squint hard, you could
claim that at least some types of pinning are actually a PKI, just a
degenerate PKI.  E.g., in a PKI I have to pin at least one trust anchor as
the root of the PKI, and if that pinned trust anchor just happens to also
be the certificate directly used in the protocol, it's still a PKI, just a
tree of height one.
What's not clear to me is whether it's useful to force this kind of
thinking on anyone, or to try to insist that all pinning is just a
degenerate PKI.

> > Do we want all protocols that specify one to be usable with the other (and
> > document it that way)?
> > 
> > Is there utility in writing a document to cover any of the above topics?
> 
> I think such a document would be useful. If it doesn't
> already exist then doing that as an informational RFC or
> BCP would be useful. If one exists already that's good
> enough then pointing at that may be fine.

Thanks,

Ben