Public Key Checking Protocol

[[Text in double square brackets (like this) is commentary. So far this is just an outline. I'll do more if there's interest. I'm also happy to get some help if someone wants to.]] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Recent publications have found yet again that some asymmetric key generation implementations do not use sufficient randomness giving rise to a number of bad public keys, estimated to be of the order of 0.2% of tested keys, being used on the Internet. Nonetheless, this small percentage maps to some tens of thousands of bad keys. And the distribution of bad keys is likely to be concentrated on specific devices or devices used in specific ways, so that their Pesudo Random Number Generators (PRNG) for one reason or another have not produced sufficient randomness at key generation time. The publications referred to above involved acquiring large (in millions) sets of keys and then analysing those for example looking for common factors. While that is a computationally expensive process, once done, it should be much quicker to incrementally check if for example a single new RSA public key has one of the already known common factors or if any public key is an exact match for a known-bad key. Thus if a responder were to store and analyse many public keys it could assist key generators in knowing if they have inadvertently produced a bad key. Note that such a responder cannot, (especially in real-time), determine that a public key is good, but only whether the public key is known to be bad. The entire set of known-bad keys cannot however be made available to all, as some of those keys are in real use and simply publishing their values could put Internet users at risk. However, if we have a responder with the bad keys and a protocol that only allows the relevant private key holder to make requests then we may be able to provide a useful service. In addition to requiring that only private key holders can query the responder, we must also ensure that eavesdroppers cannot tell whether the answer to the query is that the key is known to be bad or not known to be bad. For example, response packet sizes could expose this information. Servers implementing this protocol are REQUIRED to store the public keys presented to them for offline analysis. (Though they may also acquire public keys for analysis in many other ways.) Thus, the answer that a requestor receives might change from not-known-bad to known-bad in a matter of minutes or hours. Some requestors could take advantage of this and not actually use a key until they have gotten not-known-bad answers for a configured period. Note also that my public key may be good now but might become known to be bad after someone else has posted e.g. a public key with a common factor. In other words, every private key holder could benefit from periodically checking with a responder for this protocol. While a responder may take hours to find new bad keys, once a responder has a set of e.g. factors of RSA moduli, then it can easily check if a supplied public key has one of those as a factor, and this is one of the bad-key patterns seen in the wild. This will not detect all bad keys however, a process that does reqiure more computation. Similarly, if there are blacklists of bad keys (e.g. as happened in the Debian case ) then those can be spotted immediately. So the responder can in such cases give quick and accurate answers. Ultimately, the responder can do anything it wants for any algorithm - the specific checks are not a part of this protocol. While a responder here could lie and say that a key is not-known-bad even if it is in fact known-bad, using more than one responder could mitigate that and reduce the level of trust required in the responder's honesty. Clients can also test any responder for this kind of dishonesty by occasionally generating and sending bad keys to check if the responder is honest. This is why we REQUIRE the responders to store and analyse the keys presented to it. [[Could be interesting games to play here.]] If a responder considers a public key to be known bad, then the responder might know the corresponding private key in which case it can produce a proof that it know this, e.g by signing a hash of the request message or otherwise. Note that responders MUST ensure that the inclusion or omission of such proofs is done so as not to expose the responder's opinion of the status of the public key - in otherwords, keep all response messages the same length for a given public key length. Note also that this protocol does not tell the requestor what to do with a known-bad public key. Presumably they'd stop using it but the best action to take will depend on the application using the public key so is out of scope here. This is an experimental specification for at least two good reasons. Firstly, it is not yet clear that it would be broadly adopted by private key holders. Secondly, it is not clear that responders with access to the data about known-bad keys will make that information available via this protocol, or at all. If responders for this protocol with significant data sets appear on the Internet and private key holders adopt this protocol then the experiment will have been successful and a future version of this could be considered for the IETF standards track.

[[The protocol below requires the private key be usable for signing. We could extend it to e.g. D-H public values if we put more structure into the ChalResp. Not sure if that's worthwhile for now since the overwhelming majority of keys will be ok for signing.]] The abstract protocol is simple: ChalReq: the requestor sends a message asking for a challenge ChalResp: the responder replies with a challenge CheckReq: the requestor sends a signed query containing the public key and challenge CheckResp: the responder replies saying the public key is known to be bad, or not known to be bad In addition there is an ErrorMsg defined. This protocol MUST be run over a responder-authenticated TLS session using a TLS ciphersuite that provides strong confidentiality. In order to ensure confidentiality even in the face of traffic analysis, we ensure that all messages containing the responder's result are the same size (for a given public key algorithm and size). This can involve the responder sending random bits to the requestor, and those MUST be of sufficient quality to be useful as input to key generation. For additional privacy, a requestor might choose to run this protocol over some onion routing network such as Tor. The protocol is designed to allow for such use-cases. [[not sure yet how to do that though, help appreciated]] Note that the challenge has no strucure from the requestor perspective but might have for the responder. For example, a responder could include encrypted values in order to ensure that the challenge is valid and or fresh. [[we might want to make that a MUST but its probably only useful if done so I could test it from outside.]]

In this section we describe the messages used in this protocol. [[The concrete encoding is TBD. Maybe JSON or just binary, dunno.]] [[Would it be worthwhile REQUIRING that all messages be randomly padded out to some particular length that's longer than all real messages for the key length in question? Not sure.]] All multi-octet values MUST be sent in network byte order.

This message is sent from a requestor to a responder asking for a fresh challenge.

This message has the following fields: Type: 0x01, 1-octet, meaning that this is a ChalReq Flags: TBD, 4-octets

This message is sent from a responder and contains a fresh challenge. Type: 0x02, 1-octet, meaning that this is a ChalResp Flags: TBD, 4-octets ChalId: 4-octets, a value chosen by the responder to index the challenge ChalLen: 4-octets, the length of the challenge in octets Chal: NN octets, the octets of the challenge [[Maybe ChalId should be a transaction ID? figure out later. With the ChalId you could do all this over DTLS/UDP maybe. Probably not worth it though.]]

This message is sent from a requestor to a responder and contains a public key, challenge and signature over those. Type: 0x03, 1-octet, meaning that this is a CheckReq Flags: TBD, 4-octets ChalId: 4-octets, a value chosen by the responder to index the challenge ChalLen: 4-octets, the length of the challenge in octets Chal: NN octets, the octets of the challenge PKAlg: public key algorithm identifier and format (details TBD) PKLen: 4-octets, the length of the public key in octets PK: NN octets, the octets of the public key Sigalg: signature algorithm identifier and format (details TBD) Siglen: 4-octets, the length of the signature in octets Sig: NN octets, the octets of the signature

This message is sent from a responder to a requestor and contains the status of the public key according to the responder. . Type: 0x04, 1-octet, meaning that this is a CheckReq Flags: TBD, 4-octets ChalId: 4-octets, a value chosen by the responder to index the challenge Status: 1-octet, an even numbered value means the key is not known to be bad; an odd numbered value means the key is known to be bad (says the responder!) ProofType: 2-octets, proof algorithm identifier and format (details TBD) Prooflen: 4-octets, the length of the proof in octets Proof: NN octets, the octets of the proof In order to keep response to the same length, a ProofType value of zero (0) means that the Proof field contains the relevant number of octets of random values.

Error messages all have the following format. Type: 0x00, 1-octet, meaning that this is an ErrorMsg Flags: TBD, 4-octets ChalId: 4-octets, a value chosen by the responder to index the challenge or zero if no relevant ChalId is known ErrType: 2-octets, the specific error (values TBD) Errlen: 4-octets, the length of the error string in octets ErrorString: NN octets, the octets of the error string [[There will be i18n silliness needed here, maybe.]]

In this section we define the signature operation and define proof types.

The requestor has to sign some data for the CheckReq. The input to the signature is the following values, concatenated. A fixed string "CHECKING A PUBLIC KEY" Type: 0x03, 1-octet, meaning that this is a CheckReq Flags: TBD, 4-octets ChalId: 4-octets, a value chosen by the responder to index the challenge ChalLen: 4-octets, the length of the challenge in octets Chal: NN octets, the octets of the challenge PKAlg: public key algorithm identifier and format (details TBD) PKLen: 4-octets, the length of the public key in octets PK: NN octets, the octets of the public key Sigalg: signature algorithm identifier and format (details TBD) Siglen: 4-octets, the length of the signature in octets This is essentially the fixed string (to prevent cross-protocol attacks) followed by the CheckReq message minus the Sig field but including the length.

We define two types of proof here, a signature scheme (ProofType 1) and a random scheme (ProofType 0) to be used when the public key is not known to be bad. For ProofType 0, the responder just includes the same number of random octets as it would have used for ProofType 1 had the status been known-bad. As with the challenge value those random octets MUST be good enough to use as a PRNG seed. Note that a responder can use ProofType 0 even if it says that the public key is known-bad. Not all kinds of badness result in the responder being able to demonstrate that it knows the private key. ProofType 1 involves the responder signing a sha-256 hash of the CheckReq message with the private key corresponding to the public key submitted in the CheckReq. This signature demonstrates to the private key holder that their key is toast. [[At some stage think about this some more to see what's best to use as proof.]]

Regardless of the scheme used to generate the challenge, a responder's challenge MUST be a good random value, suitable for a requestor to use as an additional seed for a PRNG and the challenge MUST be at least 256 bits long. A fresh challenge value MUST be used for all transactions. Attempts to re-use a challenge MUST result in an error (BadChal). [[Not sure this is needed but we should say something and this is the easiest to say, if not to implement;-)]] If the responder wishes to remain stateless then it can emit challenge values that are a symmetically encrypted form (with integrity!) of the current responder time and/or a sequence number of some sort. This would allow the responder to detect attempts to use stale challenges.

Responders need to ensure that simple timing attacks are not possible. The processing of CheckReq messages MUST take the same amount of time regardless of errors, known-bad status and of the ProofType used in the corresponding CheckResp. For clarity: the time between receipt of a CheckReq and emission of a CheckResp or ErrroMsg corresponding to that CheckReq MUST be a constant for any given public key algorithm and key size. When a responder recevives a message that does not decode properly it SHOULD return an ErrorMsg with an ErrType value of BadMessage (1). An example where an ErrorMsg might not be returned would be if the responder considered itself as being under a Denial-of-Service (DoS) attack. When a responder receives a ChalReq message, it MUST generate a fresh ChalRep message. When a responder receives a CheckReq message it MUST do all of the following: Verify that the ChecReq challenge value meets whatever are the server's criteria. If it does not then the responder MUST return an ErrorMsg with ErrType BadChal (2). Verify that the public key from the message verifies the signature from the message. If the signture check fails then the responder SHOULD an ErrorMsg with ErrType BadSig (3). The responder might not send an ErrorMsg if it considered that some attack was under way, e.g. if many bad signatures were received for the same public key. Store the public key for later analysis. The responder MUST NOT store any other information about the requestor, for example, its IP address. Determine whether to answer that the key is known-bad or not-known-bad based on whatever local criteria are used. Construct a corresponding CheckResp message and return that to the requestor.

[[Still TBD, but fairly obvious]]

[[You MUST be able to do RSA, prooftypes 0 (random bits) and 1 (signature), signatures MUST use rsa-sha256 with OAEP or pkcs1v1.5 maybe. What else?]]

[[Maybe just right over TLS over TCP, maybe via HTTP, with a .well-known URL, dunno.]]

[[You'd have to imagine there are:-)]]

[[None yet, there will be a bunch with registries for many of the fields in the messages defined above.]]

Steve Bellovin proposed the main idea here independently , I only saw that after the -00 was out. Thanks for Paul Hoffman for some off-list discussions that didn't quite convince him this is worth some effort;-)

This section describes the various versions of this draft and is to be removed later when/if this becomes an RFC. -00: just a sketch of the protocol -01: sketch -> fairly detailed outline