Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt

[Michael Gray <[e-mail]>]

Paul Hoffman <[e-mail]> wrote on 07/10/2009 10:16:38 AM:

> At 9:35 AM +1000 10/7/09, Michael Gray wrote:
> >Comparing this with draft-rescorla-tls-extended-random-02.txt I see the
> >requirement for the size of Server response is missing and thus
undefined.
>
> Correct. Both sides send arbitrary-length values.
>
> >From 3.1 in the above we have:
> >
> >   If the server wishes to use the extended randomness feature, it MUST
> >   send its own "extended_random" extension with an
> >   extended_random_value equal in length to the client's
> >   extended_random_value
> >
> >Additionally, I think some limitation of the size/amount of data that
can
> >be requested from a server is needed as large sizes could pose an attack
on
> >a server by exhausting the entropy pool and/or causing server
performance
> >degradation.
>
> In this proposal, server never "requests" any particular size. The
> client offers its value in the extended_random extension, and the
> server offers its value in the reply.
>
> >  Our prototype implementation allows servers to ignore or
> >respond with error, depending on configuration, requests from clients
that
> >are larger than 256 octets.
>
> ...which is a good reason why we abandoned the "request a size"
semantics.

In this case should be this draft also indicate that the client MAY
generate a fatal "handshake_failure" alert in the event that the Server
provides insufficient data?

Would this again be true for the Server, if a Client sends insufficient
data? i.e. A Server MAY generate a fatal "handshake_failure" alert in the
event that the Client provides insufficient data?

Additionally, can the Server use the Client size as an indication of how
much the Server should send? else how does the Client convey a
minimum/desired requirement information to a Server?


Mick Gray
IBM

>
> --Paul Hoffman, Director
> --VPN Consortium