[Freedombox-discuss] TLS handshake client credential/identity exposure [was: Re: Software as Data, Transformation as a Service]

[Daniel Kahn Gillmor]

Hi Michael--

On 01/09/2013 10:48 AM, Michael Rogers wrote:
> Does the openpgp2x509 script use the NullSignatureUseOpenPGP signature
> type you described in an earlier email?
> 
> https://lists.riseup.net/www/arc/monkeysphere/2011-03/msg00027.html

yes, it does.

> My concern with that approach is that the sigature type is sent in
> plaintext during the handshake, making it simple to identify/block
> OpenPGP-authenticated connections.

I agree that this is a problem, but it's an issue with the TLS
handshake more generally, not with NullSignatureUseOpenPGP -- TLS is
guaranteed to leak the proposed certificate of the server, and the
current handshake leaks the certificate of the client (and all other TLS
extensions), even to a passive eavesdropper.

Folks on the IETF TLS WG are aware of this, and there have been several
proposals to try to address it:

  https://tools.ietf.org/html/draft-ray-tls-encrypted-handshake

  https://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

and the "encrypted extensions" section of:

 https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04#section-3

and there's also:

  https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-5
 (this addresses sending some of the handshake data encrypted)

There might be other proposals as well; unfortunately, there doesn't
seem to be a consensus at the moment as to the right way to achieve the
goal of ensuring that the client-provided data can only be read by the
expected host.  If i had to be on anything, it'd probably something from
agl, since google is the 800-pound gorilla and they can just decide to
deploy something in their infrastructure to make it a defacto standard
anyway.

There is a way to avoid the leak entirely with in the current TLS spec,
though!  But it requires server and client to cooperate, and it adds an
additional set of round-trips to session setup.  It looks like this:

 0) initial handshake happens with client providing no interesting
information beyond the secure-renegotiation extension.

 1) immediately after initial handshake completes successfully, the
session is renegotiated over the established channel.  In this
renegotiated handshake, the client can be confident that the server is
who they expect it to be, and this "inner" handshake is protected from
eavesdropping because it's negotiated within the encrypted outer channel.

does this make sense?

> But I have to admit that I can't think of a way for the endpoints to
> signal to each other that OpenPGP keys should be used to authenticate
> the connection, without signalling the same to an eavesdropper. Any
> thoughts?

Note that the NullSignatureUseOpenPGP extension is an X.509 extension,
not a TLS extension.  From the TLS point of view, the certs passed are
just X.509 certificates, and no signalling is given in the TLS handshake
itself to indicate which kind of certificates are preferred.

this is distinct from RFC 6091 (where the peers negotiate what
certificate type to use explicitly) and from
https://tools.ietf.org/html/draft-ietf-tls-oob-pubkey (which is looking
likely to replace RFC 6091 from my perspective, but with the added
advantage of separate negotiations for each peer).

	--dkg

-------------- 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.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130110/2f99eb0a/attachment.pgp>