Re: [TLS] Extensions and session resum ption

[badra at isima.fr]

>> 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?
>
> Best regards,
> Badra
>

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