On 23/03/15 14:19, Jakob Bohm wrote:
> On 23/03/2015 14:48, Matt Caswell wrote:
>> On 23/03/15 13:45, Viktor Dukhovni wrote:
>>> On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:
>>>
>>>>> As Viktor states RFC 4492 says if the client sends no TLS extension
>>>>> containing the curves supported then the server can choose any
>>>>> supported
>>>>> curve. So your fix is to continue when we reach the second
>>>>> iteration if
>>>>> there are no curves in the second list rather than flag an error.
>>>> Essentially yes, although with the refinement that the first iteration
>>>> checks the list of available curves for this SSL. This may or may
>>>> not be
>>>> the same as the complete list of curves available in this *build* (e.g.
>>>> if SSL_set1_curves_list() has been used).
>>> I would expect that a client sending an *empty* list of supported
>>> curves means no curves are supported by the client, and the server
>>> would not enable EC. The case where the server is free to choose
>>> any curve is presumably when the client does not send a supported
>>> curves extension at all.
>> It is not valid to send an empty list. If the client uses the extension
>> then they *must* set at least one curve. Therefore if the client list is
>> empty then it can only be because the extension was not used.
> Is sending an empty list technically impossible in the
> protocol, or just not currently permitted.
The extension is defined in RFC4492 as a list of NamedCurves with at
least one entry in that list:
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;
It would be technically feasible to send a zero length list (although
that would be in violation of the RFC). If a client did so then OpenSSL
would reject it with a decode error alert.
Matt
