Re: [TLS] RFC 5878 - why?

[Trevor Perrin <[e-mail]>]

On Tue, Sep 17, 2013 at 6:08 AM, Martin Rex <[e-mail]> wrote:
> Martin Rex wrote:
>> Marsh Ray wrote:
>> > > Trevor Perrin
>> > > Sent: Monday, September 16, 2013 9:16 PM
>> > > Subject: [TLS] RFC 5878 - why?
>> > >
>> > > Does anyone know of a reason to use RFC 5878?  Extension data can already
>> > > be sent in TLS handshakes:
>> >
>> > But probably the bigger reason is that some percentage of TLS servers
>> > in the wild will crash or (worse) hang when they receive a Client Hello
>> > with too much data. Nobody is really sure how much data is safe to send
>> > in the Client Hello, so getting preapproved with a small extension is
>> > safest.
>>
>> I hope that, rather than crashing, the most widespread behaviour among
>> servers will be to simply abort the handshake with a fatal Handshake
>> failure alert when the ClientHello handshake message exceeds some
>> reasonable size (maybe 16 KByte).  Ours does.
>
>
> Actually, another reason that comes to mind when looking at the
> handshake message flowchart here:
>
>   http://tools.ietf.org/html/rfc5878#page-4
>
> taking into account the last sentence before that chart:
>
>    Successful session resumption uses the same authorization information
>    as the original session.
>
> and compare it with the handshake message flowchart for the
> abbreviated TLS handshake (aka session resume):
>
>   http://tools.ietf.org/html/rfc2246#page-32
>
>
> For a potentially large TLS extension that carries fairly static data,
> you might not want to have to send it on every proposed TLS session resume.


Like I said to Marsh, see the flowchart in my first message.

It's trivial to exchange "authorization data" - or any sort of
extension data - in the ServerHello extension, and also in a 4680
SupplementalData message sent by the client after receiving
ServerHelloDone.

5878 is not needed to avoid sending large items in ClientHello.


Trevor