27
$\begingroup$

There is a specification, in Informational(!) RFC 6091, for using PGP keys in TLS authentication, although I don’t think it has ever been implemented outside of GnuTLS (it’s certainly not in OpenSSL).

Yet the TLS 1.3 RFC 8446 §4.4.2 goes as far as to specifically prohibit this obscure extension with a must not. Normally an IETF document would use a should not to recommend against something that’s not fundamentally broken, but still a bad idea in most cases; and RFC 6091 doesn’t seem broken—it just provokes pointless bloat (given the current state of client support and PGP deployment).

What’s the point of such strong language?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
25
$\begingroup$

It seems that PGP certificates have the problem that they can be changed by the user. Furthermore, there were extensions for 1.2 that are incompatible for 1.3 (if they were secure in the first place):

I found this on the TLS mailing list from Ilari Liusvaara:

Ugh, the situation is way worse than what I thought.

Basically, all three assume they have full control of certificate message, worst of all being OpenPGP, which modifies it in more complex ways (it isn't a pure element or list anymore).

And even with RPK, which appiles least severe modifications, still modifies the structure in ways that are not obvious in implications w.r.t. TLS 1.3.

Oh, and turns out I had implemented RPK in TLS 1.2 wrong by assuming that it doesn't actually modify the certificate message format. Which turned out to be wrong assumption (I fixed this after discovering the format changes).

And then certificate types don't currently work sanely for client certs, even if you knew how those map to Certificate message.

Client_certificate_type and server_certificate type aren't the only problematic extensions w.r.t. TLS 1.3. The table of extensions has the following too (all marked as allowed, I added short reason I think those are problematic):

  • client_certificate_url: Replaces certificate message. Hardcodes SHA-1 (which is now provably broken).
  • user_mapping: Has extra handshake message.
  • cert_type: All the problems of CCertT and SCertT, combined with fixing both to be the same.

With user_mapping, applying similar trick as in status_request is not completely trivial because extensions that are answered in client Certificate are offered in CertificateRequest. Okay, except that extension is not an answer to ClientHello extensions, and the extension assumes offer-answer relationship between client and server extensions. Might need some special-casing.

...

Source: https://www.ietf.org/mail-archive/web/tls/current/msg22576.html

In other messages in the thread they talk about disabling OpenPGP until somebody comes up with an extension in a separate RFC. So it doesn't seem to be malice, just a whole bunch of compatibility reasons. In other words: as it is now it looks very broken - until somebody manages to fix it.

Improve this answer
$\endgroup$
6
  • 5
    $\begingroup$ Nice work on tracking down the original reason! TLS 1.3 really tried to clear out as much accumulated cruft in the protocol as possible (dark corners can hide nasty surprises), so I'm not surprised that they jettisoned the extensions for OpenPGP certs. $\endgroup$
    – kiwidrew
    Nov 14, 2018 at 8:21
  • $\begingroup$ @Maarten I’m a bit lost in the terminology here—let’s see if understand this correctly: TLS 1.3 declared a common format for the authentication data (what they call Certificate but is actually a list of X.509 certificates), but RFC 6091 overrides Certificate wholesale, and so is broken in TLS 1.3 protocol-wise even if its security was solid. $\endgroup$
    – Alex Shpilkin
    Nov 14, 2018 at 12:45
  • 1
    $\begingroup$ @kiwidrew That’s not the surprising part: an Informational RFC outside of the main spec is to begin with about as far as from an official IETF endorsement as it’s possible to get; the surprising part is the must not in the new main spec. But if it changed a part of the wire format the TLS 1.3 designers would like to see frozen, that would explain it. $\endgroup$
    – Alex Shpilkin
    Nov 14, 2018 at 12:48
  • 1
    $\begingroup$ There seems to be a list of messages or records to be changed below the mail message (which is represented by the ...) in my answer. However, it is not completely clear to me if this is the case and how much change would be required; feel free to have a look though (and the message is part of a thread, but I think this message sums it up nicely). $\endgroup$
    – Maarten Bodewes ♦
    Nov 14, 2018 at 14:36
  • 1
    $\begingroup$ @Demi I suppose so yes. After all, the only thing required for client authentication is trust of the public key and a signature. I think client authentication is the most useful as PGP is primarily used for providing privacy for individuals. Therefore client authentication is more important than server authentication in my opinion. Server authentication may be trickier to add as you have the additional issue of validating the server name, revocation etc. $\endgroup$
    – Maarten Bodewes ♦
    Nov 22, 2018 at 14:59
2
$\begingroup$

As well as the purely mechanical elements Maarten's excellent answer talks about (how should we send these certificates in the new data structures) there's also a change in TLS 1.3 that is relevant to OpenPGP too.

In prior TLS versions it was possible (and common) to negotiate a key exchange method in which the "master secret" used to create session keys is sent, encrypted, from client to server. This looks a lot like PGP's encrypted mail messages, a simple hybrid system in which bulk data is symmetrically encrypted and then only the symmetric key is encrypted using public key cryptography. This means that server authentication happens implicitly because only the authentic server could decrypt the message.

In TLS 1.3 only DH key exchange is permitted. Ephemeral symmetric keys will be chosen by the participants at random and used to encrypt a connection immediately. Authentication always happens explicitly, over this encrypted channel. After showing a certificate (now over an encrypted channel unlike TLS 1.2 and earlier) the peer signs a transcript of the steps so far, thus proving that they have the private key corresponding to the certificate AND they witnessed the exact same setup as you.

So this changes the key usage from encryption to signature which is pretty significant. Certainly worthy of completely fresh consideration from anyone who wants (for some reason) to do TLS with OpenPGP keys and certificates.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ True of course, but it is certainly possible to sign data using PGP private keys. So although it would certainly be an additional hurdle, it should not block PGP from being used (but you could say that of all the other issues as well, I suppose). $\endgroup$
    – Maarten Bodewes ♦
    Nov 14, 2018 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.