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. If it is just not currently permitted then one needs to contemplate whya client would (in a future "update" RFC for a backwards compatible TLS version) beallowed to send an empty list rather than simply not proposing any ECC cipher codes. One possible interpretation could be "Not only don't I support any of the currentlypublished ECC ciphers, I will not accept ECC signatures in the cert chain either". Another possible interpretation could be "I support arbitrary curves, both thoseenumerated in the standards and those explicitly specified". The second interpretation happens to match what the proposed patchdoes implicitly, while the first interpretation does not. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
