[TLS] Cached-info substitution

Stefan Santesson <stefan@aaa-sec.com> Fri, 19 February 2010 15:12 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2408028C119 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 07:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db1msUwt+mwi for <tls@core3.amsl.com>; Fri, 19 Feb 2010 07:12:02 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 8539A3A7CE8 for <tls@ietf.org>; Fri, 19 Feb 2010 07:12:01 -0800 (PST)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3601938277D for <tls@ietf.org>; Fri, 19 Feb 2010 16:01:56 +0100 (CET)
Received: (qmail 34521 invoked from network); 19 Feb 2010 15:01:50 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 19 Feb 2010 15:01:50 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 19 Feb 2010 16:01:49 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, Adam Langley <agl@google.com>, <tls@ietf.org>
Message-ID: <C7A4666D.8663%stefan@aaa-sec.com>
Thread-Topic: Cached-info substitution
Thread-Index: AcqxdHYlusTY3ZghHkKpSFP6omKzhw==
In-Reply-To: <4B7D8AAD.80204@briansmith.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [TLS] Cached-info substitution
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2010 15:12:04 -0000

Brian and Adam,

On 10-02-18 7:45 PM, "Brian Smith" <brian@briansmith.org>; 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