Re: [TLS] Extensions and session resumption

[Eric Rescorla <ekr at networkresonance.com>]

At Sat, 03 May 2008 08:32:57 -0700,
Eric Rescorla wrote:
> 
> At Sat, 03 May 2008 08:03:15 -0700,
> 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.
> > > 
> > > In [RFC4366] section 3:
> > 
> > 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.
> 
> Doh.
> 
> 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.

   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
   resumption.	

   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
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls