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

[Michael Gray <mickgray at au1.ibm.com>]

Paul Hoffman <paul.hoffman at vpnc.org> wrote on 07/10/2009 12:36:47 PM:

> At 11:33 AM +1000 10/7/09, Michael Gray wrote:
> >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?
>
> Either side MAY decide for many reasons to stop when they see the
> other sides's extension. I can add something to this effect to the next
draft.
>
> >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?
>
> It doesn't. This is really a different set of semantics than the
> previous draft. We realized that there was too many expectations
> being signalled, and decided to simplify.

IMHO the previous draft was easier from a Server configuration point of
view.  We want our Server configuration to be as simple and accommodating
as possible to minimize the number of configuration options our consuming
products need to deal with, which also simplifies things for our customers.
Thus in the previous draft version we needed  no Server configuration by
default in that the Server comes preconfigured with a default safe maximum
value.  Thus what ever the Client asks for, the Server will both accept and
provide, up until it’s maximum default configuration without needing a
configuration update from a customer.

We ended up with two optional configuration values for a Server: A optional
value for the Maximum amount of random data it will provide on request, and
an optional value for Minimum amount that the Server will accept from a
Client i.e. the Server MUST receive this minimal amount of additional PRF
input.

In this draft we could have the Server always respond with it’s Maximum
safe value or force the customer to always set a configuration value which
immediately causes customer pain.  Sending the maximum safe value seems an
over kill if the client does not need or want it; the client is after all
indicating how much it wants to add on it's side to the PRF and it seems
intuitive IMO for the Server to play ball and respond in kind.  If the
customer then makes the Server configuration value too small we could have
handshake fails with certain clients, reducing Server availability, a
situation that will require problem determination to resolve, and related
customer annoyance.

Mick Gray
IBM

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