Re: [TLS] Extensions and session resum ption

[Eric Rescorla <ekr at networkresonance.com>]

At Sat, 10 May 2008 17:58:54 +0200 (CEST),
badra at isima.fr wrote:
> 
> > 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
> 
> 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
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls