comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Daniel Kahn Gillmor]

On 01/15/2013 06:18 AM, Stef Walter wrote:
> Since there is obviously a lot of new ideas and work being done in the
> area of key pinning and TLS trust in general, 

I'm very happy to see folks considering the various pinning schemes and
how they fit into this model; i think that's the right thing to do.

I have a terminology concern though, which i tried to raise initially,
but i don't think i did very successfully: the current
sharing-trust-policy draft uses the term "pinning" as a sort of
additional accepted key (the way it's used in RFC 6125).

The newer models all use the term "pinning" to refer to an allowlist --
that is, if a pin exists, nothing else is acceptable.

These are actually radically different concepts, and i think we do this
document (and whatever software or protocols we build from it) a
disservice by continuing to use the same term for them.

It's pretty unfortunate that the pre-existing work contains this
confusion, but we have an opportunity to try to help clarify it for
implementers and users.  Alas, i'm not sure how to do it.  Any suggestions?

> FWIW, I'm not super sure about the focus on dialogs and UI. Any scheme
> which expects its users to play janitor or security guard on their own
> computer unfortunately won't get the widespread pickup desired.
> 
> But that's orthogonal to modeling the trust policy storage.

I agree that specifying a particular UI should probably be beyond the
scope of this project.  But I hope people will discuss the UI's they
envision which might be useful (even those that are admin- or
poweruser-only), because i think considering what is a sensible UI for a
knowledgeable user is often helpful in terms of deciding what needs to
be in the underlying data model.

>> Instead of just the hostname, this could be the hostname+protocol+port
>> together, to be able to store different keys for different services of
>> the same host.
> 
> Interesting. That's a key point. OOI, why did you define protocol as
> part of this? Wouldn't hostname+port be enough? Is it a nice to have, or
> do you think it's really truly part of the primary-key (so to speak)?

fwiw, from my perspective i think the protocol is *more* important than
the port, for the same reason that the hostname is more important than
the IP address.

This work is about helping users properly bind human concepts to
cryptographic primitives.  While some users are thoroughly confused
about what they're doing, many of them can at least distinguish whether
they're using a web browser or an e-mail client.

Those who know whether they're using port 443 or port 143 or port 993
are much fewer (let alone knowing whether a given connection is
IMAP-over-TLS or IMAP-with-STARTTLS).

If a certificate is used for connecting to mail.example.org via
IMAP-over-TLS (port 993), it should have the same semantics when used
for IMAP-with-STARTTLS (port 143) on the same host.

so the relevant test for how these should be considered (to my mind)
"does this seem like a distinct use from the user's point of view?"

> So for key pinning, I've been thinking along the lines of defining
> something along similar lines to the stapled extensions.
> 
> So for key pinning pinning you would the 'peer' as a primary-key. One of
> the main forms for a peer is a hostname+port (and perhaps protocol).

hm, do you mean "not use the 'peer' as a primary-key"?  i think the
first sentence of the paragraph above is unclear.

For websec key pinning, for example, the pin belongs to the host (and
the protocol, which is presumed to be the web i guess), not to a key
belonging to that host in particular.

> FWIW, correcting myself here ... the more I think about it blacklists
> are specific to the X.509 trust model. X.509's reliance on blacklists
> can be seen as the deficiency that these other mechanisms are trying to
> solve. Therefore we need not generalize the blacklist to cover key
> pinning. Key pinning is a form of whitelist, there are (and should be)
> ways to remove pins, and we need not confuse this with the concept a
> blacklist.

i'm not sure i'm convinced.  If a public key is blacklisted in any form
(e.g. if it has been marked as compromised in an OpenPGP packet, or
found and factored in one of the recent GCD sweeps [0]), i think i want
that key blocked no matter whatever form it shows up in.

Why shouldn't that be relevant to all models?

	--dkg

[0] http://www.loyalty.org/~schoen/rsa/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20130115/b6882192/attachment.pgp>