Subject: [TLS] Extensions and session resumption

From: Mike <[email-masked]>
Date: Sat, 03 May 2008 03:39:11 -0700

It's late, so I might be missing something, but I
can't find any information about what clients and
servers should put into hello extensions when they
intend to resume a previous session.  It is implied
that all that is necessary is for the session ID to
match that of the previous session (and the client
MUST include the particular cipher suite and
compression algorithm), but nothing is said about
whether the client needs to specify the same list
of extensions (with the same values presumably),
or if the server must include them in the server
hello response.

My code wants at least the server name extension
to be in the client hello in order for the server
to easily find the cached session (since you can
set up multiple session caches).  But it also makes
some sense to require the inclusion of truncated
HMAC, for example.

Mike
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked]
Date: Sat, 3 May 2008 13:09:03 +0200 (CEST)

> intend to resume a previous session.

In [RFC4366] section 3:

      If the resumption request is denied, the use of the extensions is
      negotiated as normal.

      If, on the other hand, the older session is resumed, then the
      server MUST ignore the extensions and send a server hello
      containing none of the extension types.  In this case, the
      functionality of these extensions negotiated during the original
      session initiation is applied to the resumed session.

> some sense to require the inclusion of truncated

I think this is not possible with the current specifications (the *MUST*
in the text above). Instead, this could be done using a local mapping.

Best regards,
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 03 May 2008 07:00:42 -0700

> in the text above). Instead, this could be done using a local mapping.

Yes. Put an indicator in the session_id of which cache you wish to
use if you ahve more than one.

-Ekr

---

From: Mike <[email-masked]>
Date: Sat, 03 May 2008 08:03:15 -0700

>> intend to resume a previous session.

I should have been more clear -- I was looking at the
latest drafts, draft-ietf-tls-rfc4346-bis-10.txt and
draft-ietf-tls-rfc4366-bis-02.txt.  The text you cite
is not included in either.  Somehow it got dropped.

Thanks for finding it though.

Mike

---

From: Mike <[email-masked]>
Date: Sat, 03 May 2008 08:06:23 -0700

> Put an indicator in the session_id of which cache you wish to

Thanks, I hadn't thought of that; it should work fine.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 03 May 2008 08:32:57 -0700

At Sat, 03 May 2008 08:03:15 -0700,
> is not included in either.  Somehow it got dropped.

Doh.

You caught that just in time, since this is in auth 48.

Thanks,
-Ekr

---

From: <[email-masked]>
Date: Mon, 5 May 2008 12:31:10 +0300

Mike wrote:
> 
> It's late, so I might be missing something, but I can't find any
> information about what clients and servers should put into hello
> extensions when they intend to resume a previous session.  It is
> implied that all that is necessary is for the session ID to match
> that of the previous session (and the client MUST include the
> particular cipher suite and compression algorithm), but nothing is
> said about whether the client needs to specify the same list of
> extensions (with the same values presumably), or if the server must
> include them in the server hello response.
> 
> My code wants at least the server name extension to be in the client
> hello in order for the server to easily find the cached session
> (since you can set up multiple session caches).  But it also makes
> some sense to require the inclusion of truncated HMAC, for example.

Since the client can't know whether the server will actually resume
the session, or start a full handshake, it needs to include all the
extensions in the Client Hello to achieve correct behavior.

For example, if the client omitted server_name (although it had
included it previously), the full handshake might fail because
the server might pick a different identity (certificate).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 5 May 2008 12:36:13 +0300

[email-masked] wrote:

> In [RFC4366] section 3:
> 
>       If the resumption request is denied, the use of the extensions
>       is negotiated as normal.
> 
>       functionality of these extensions negotiated during the
>       original session initiation is applied to the resumed session.

The preceeding paragraph is quite important in this context:

        Note also that all the extensions defined in this section are
        relevant only when a session is initiated.  When a client
        includes one or more of the defined extension types in an
        extended client hello while requesting session resumption:

Thus, it's possible to define extensions that are relevant also 
when resuming a session, and the text "server MUST ignore..." 
does not apply to those. (We already have one such extension,
RFC 5077).

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Mon, 5 May 2008 21:53:25 +0200 (MEST)

> some sense to require the inclusion of truncated

The (always server-generated) SSL session ID is 32 Bytes,
so it is long enough to accomodate hints for the server
side SSL session cache management.

However, very few SSL stacks seem to take advantage of that.

The server could assign certain Bits/Bytes in the SSL session ID
for specific purposes, one possible _example_:

   - 128 bits (16 Byte) to carry a cryptographic random nonce
     (to make it difficult for attackers to guess SSL session IDs

   -  64 bits to create a per-SSL-cache unique session identifer
      (e.g. increasing counter value).  Just make sure the
      old sessions are expunged from the SSL session cache before
      the 64-bit counterspace completes a full cycle.

   -  64 bits in custom slicing to distinguish/recognize individual
      servers of a server farm (or multiple virtual hosts or both)

When done this way, you no longer have to search the SSL session
cache for a collision when creating a new SSL session ID, and
rather than caclulating a hash value on the SSL session ID when
looking up in the session cache, you could use bits from your
session ID (e.g. from the strong random bits) directly, they
should have a pretty even distribution.

The _client_ can not do this optimization on his SSL session cache
since it must accept whatever session ID the server issues.

-Martin

---

From: Mike <[email-masked]>
Date: Fri, 09 May 2008 17:25:37 -0700

One typo:

>    Finally, note that extensions can be sent both when starting a new
>    session and when requesting session resumption.  Indeed, a client
>    that requests session resumption does not in general know whether
>    the server will accept this request, and therefore it SHOULD send
>    the same extensions as it would send it not attempting
                                      ^^^^^^^ if it were
>    resumption.	

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 09 May 2008 12:40:32 -0700

At Sat, 03 May 2008 08:32:57 -0700,
> You caught that just in time, since this is in auth 48.

Here's my proposed fix for this text (thanks to Pasi for a bunch
of this):

In 7.4.1.4, after "as described in Section 12" and before "There are
subtle":

   An extension type MUST NOT appear in the ServerHello unless the
   same extension type appeared in the corresponding ClientHello.  If
   a client receives an extension type in ServerHello that it did not
   request in the associated ClientHello, it MUST abort the handshake
   with an unsupported_extension fatal alert.

   Nonetheless, "server-oriented" extensions may be provided in the
   future within this framework.  Such an extension (say, of type x)
   would require the client to first send an extension of type x in
   ClientHello with empty extension_data to indicate that it supports
   the extension type.  In this case, the client is offering the
   capability to understand the extension type, and the server is
   taking the client up on its offer.

   When multiple extensions of different types are present in the
   ClientHello or ServerHello messages, the extensions MAY appear in
   any order. There MUST NOT be more than one extension of the same
   type.

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption. Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello. However, some extensions may
   specify different behavior during session resumption.

Note: this relaxes the behavior of RFC 4366, which forbid extensions
to have effects during resumption.

Also, we should add to end of Section 7.4.1.4.1:

   When performing session resumption, this extension is not included
   in Server Hello, and the server ignores the extension in Client
   Hello (if present).

Comments?
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 May 2008 09:13:14 -0700

At Sat, 10 May 2008 17:58:54 +0200 (CEST),
[email-masked] wrote:
> The text is perfect.
> BTW, I don't know if the following could happen or not; can the server
> select different parameters values of an extension when requesting session
> resumption? e.g. If, during the initial handshake, the client sent the
> following fragment length {2^10, 2^12, 2^14} and that the server replied
> with the value 2^10, can the server select a different value (e.g. 2^12)
> during the resumption?

That's supposed to be forbidden.

The only extension I know of what is different with resumption
is the ticket (RFC 5077), which itself is tightly bound with
resumption.

-Ekr

---

From: [email-masked]
Date: Sat, 10 May 2008 17:58:54 +0200 (CEST)

The text is perfect.

Best regards,
Badra

---

From: [email-masked]
Date: Sat, 10 May 2008 18:06:29 +0200 (CEST)

> with the value 2^10, can the server select a different value (e.g. 2^12)

Sorry to don't be clear.

I take the example of fragment length extension, which hasn't the above
behaviour; I am talking about extensions that are relevant when resuming a
session.

Badra

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 May 2008 09:02:34 -0700

Here's my lightly revised version of this text post comments
from Mike and Pasi. 

Joe, can you pls. issue a last call for comments on this text?

Thanks,
-Ekr

   the same extensions as it would send if it were not attempting
   resumption.