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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
