Re: [TLS] =?utf-8?b?wqDCoEV4dGVuc2lvbnPCoGFuZMKgc2Vzc2lvbsKgcmVzdW0g?==?utf-8?q?_ption?=

[badra@xxxxxxxx]

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