[TLS] Cached-info substitution

[Stefan Santesson <[e-mail]>]

Brian and Adam,

On 10-02-18 7:45 PM, "Brian Smith" <[e-mail]> wrote:

>> 4) results from the fact that I don't think the current draft is clear
>> enough about how the substitution occurs. Making new handshake types
>> means that everything is very explicit and I prefer that. However, I
>> can't think of anything technically wrong with just memcmp()ing for
>> the hash values in the existing handshake messages, if it was
>> precisely specified.
>>    
> I would say the message flow should just go something like this: If the
> server doesn't send a Certificate message, then use the cached
> certificate. If the server sends a CertificateRequest with an empty
> (zero-length) certificate_authorities then use the cached
> certificate_authorities. Then nobody has to do any substitution, it's
> much easier to specify, and much easier to implement than the
> substitution mechanism from the current draft or introducing new
> handshake messages would be. Note that this is how RFC5088 works (you
> have to infer what the server is saying based on what handshake messages
> it skips; for example, if the server doesn't send a Certificate right
> after its ServerHello then you have to infer that it's doing a
> resumption based on the given ticket).

Breaking out this question in a separate thread.

I do not like the though of defining new handshake messages. We have a very
small name space for handshake messages with very strict rules for defining
new ones.

I like in principle your suggested simplification to omit whole handshake
messages to indicate substitution. However, this works only if the cached
parameter is the only parameter of the handshake message. I.e. It works for
the server Certificate message but not for the certificate_authorities
parameter of the CertificateRequest message.


I do however absolutely agree that the current document is underspecified as
to how the substitution is done. It also offers an alternative syntax for
the handshake message with hash substitution which may be a bit problematic.


As I see it we have two choices.

1) To define a format for the handshake message which include the hash
substitution using a syntax that alters the defined syntax of the handshake
message. (current draft approach)

2) To define a format which preserves the original handshake message syntax.


In practice this would look something like this:


Certificate handshake message:

Original syntax:
      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;


Substitution syntax, choice 1 (current draft):
      struct {
          CachedInformationHash certificate_list<0..2^24-1>;
      } Certificate;


Substitution syntax, choice 2 (preserving original syntax):
      CachedInformationHash CachedCertList<1..2^24-1>;

      struct {
          CachedCertList certificate_list<0..2^24-1>;
      } Certificate;



The corresponding syntax for CertificateREquest;

Original syntax:
      opaque DistinguishedName<1..2^16-1>;

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;


Substitution syntax, choice 1(current draft):
      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          CachedInformationHash certificate_authorities<0..2^16-1>;
      } CertificateRequest;


Substitution syntax, choice 2 (preserving original syntax):
      CachedInformationHash Cached_authorities<1..1^16>

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          Cached_authorities certificate_authorities<0..2^16-1>;
      } CertificateRequest;



I think I prefer choice 2 as it reduce the possibility for problems when
parsing handshake messages using legacy code.

Comments suggestions?

/Stefan