Subject: [therightkey] Why the focus on The?

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 27 Jan 2012 13:02:24 -0800 (Pacific Standard Time)

All,

Why are we focusing on 'the' anything?

Key pinning and CA pinning don't work with only One True Key.  The only usable way to do that kind of thing is to present multiple options.  As certificate chains expire or are discovered to be revoked, those keys would be removed from the list of acceptable keys.

We have multiple data paths to the user, and everything that isn't security-related in IETF is recommended as highly redundant.  Why is the security area different, where everything is so singular and brittle?

We should be providing multiple TXT records with hashes of multiple acceptable SPKIs, and cross-referencing them with the SPKIs we receive in the TLS handshake.  We should not, however, rely on this as 'the' way to get information around.  That information should be advisory unless no certificate chain is presented by the server.  (i.e., you can be advised that you should look for certain keys, and you can also be willing to trust a certifier.  These are not mutually exclusive.)

We do indeed need certification, and certification does provide a useful service.  It just doesn't do it right now.  The problem is the way it's implemented, preventing it from being useful.  Implementors don't want to spend the time and make the changes to make it more useful, or are too stubbornly attached to an unworkable model to realize that they need to change.

We should also provide more than one certificate chain in our handshakes.  This would permit maintenance of the certificates on the webservers to be moved to a scheduled maintenance window instead of "OMG our CA is about to be delisted we have to act NOW".  It would also permit different certificate chains to be presented for different applications without having to define a new TLS extension.

Why is everything so single-point-of-failure in the Security working area?  Does it really have to be?

-Kyle H

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 27 Jan 2012 16:26:28 -0500

> area?  Does it really have to be?

You seem to be suggesting that we should be considering redundant,
corroborative certification techniques to ensure that the key offered by
the peer really does belong to the peer.

I agree that any solution which actually improves on the status quo will
have to include this sort of approach.

I don't think that it follows from this that you'd need to encourage
people to use multiple keys per entity, though.

The best argument i've seen for using multiple keys is the material
Chris Palmer (i think) wrote about how to deploy public key pinning,
where having a (presumably offline) backup key per managed entity gives
you some flexibility if you discover a compromise of pinned key material
that's currently in use.

Anyway, i agree with you that the question we're hoping our tools can
ask and answer is "is this key (offered by this peer) a legitimate key
for the entity we think the peer is?", not "...*the* legitimate key..."

Note that there are some contexts (e.g. sending an e-mail) where the
peer doesn't have a chance to present you with a key for you to
evaluate.  in those contexts, your tools will actually need to select a
single key from the various (hopefully redundant, corroborative)
discovery mechanisms available to them.  So in those contexts, "the" is
a legitimate article to use.

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Jan 2012 23:10:09 -0500

Interesting point.

The mailing list name came about because everyone thought my
suggestion sucked, including me. We don't need to restrict ourselves
to one key.

Incidentally, I don't want to get hung up on just doing public key
either. We could have easily made XKMS support public and symmetric
key from the start. But we didn't think about it and that led to two
groups doing what amounted to a re-do.

I think we should focus on identifying problems at this stage.

On Fri, Jan 27, 2012 at 4:02 PM, Kyle Hamilton <[email-masked]> wrote:
> Key pinning and CA pinning don't work with only One True Key.  The only
> usable way to do that kind of thing is to present multiple options.  As
> certificate chains expire or are discovered to be revoked, those keys would
> be removed from the list of acceptable keys.
>
> We have multiple data paths to the user, and everything that isn't
> security-related in IETF is recommended as highly redundant.  Why is the
> security area different, where everything is so singular and brittle?
>
> We should be providing multiple TXT records with hashes of multiple
> acceptable SPKIs, and cross-referencing them with the SPKIs we receive in
> the TLS handshake.  We should not, however, rely on this as 'the' way to get
> information around.  That information should be advisory unless no
> certificate chain is presented by the server.  (i.e., you can be advised
> that you should look for certain keys, and you can also be willing to trust
> a certifier.  These are not mutually exclusive.)
>
> We do indeed need certification, and certification does provide a useful
> service.  It just doesn't do it right now.  The problem is the way it's
> implemented, preventing it from being useful.  Implementors don't want to
> spend the time and make the changes to make it more useful, or are too
> stubbornly attached to an unworkable model to realize that they need to
> change.
>
> We should also provide more than one certificate chain in our handshakes.
>  This would permit maintenance of the certificates on the webservers to be
> moved to a scheduled maintenance window instead of "OMG our CA is about to
> be delisted we have to act NOW".  It would also permit different certificate
> chains to be presented for different applications without having to define a
> new TLS extension.
>
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

-- 
Website: http://hallambaker.com/

---

From: Jon Callas <[email-masked]>
Date: Tue, 31 Jan 2012 16:31:00 -0800

On Jan 27, 2012, at 1:02 PM, Kyle Hamilton wrote:

> * PGP - S/MIME Signed by an unverified key: 01/27/2012 at 01:02:24 PM
> 
> All,
> 

Bravo. +2^{n-1}

	Jon