enable DTLS negotiation

[David Woodhouse]

On Sat, 2016-09-17 at 13:01 +0200, Nikos Mavrogiannopoulos wrote:
> >   uint16 10015 // provisional extension ID
> >   uint16 extlen // all extensions have a length of their payload

> These you shouldn't normally care about (at least in the gnutls api
> if I remember well)

Right. In the OpenSSL add_cb() for the custom extension I do actually
have to provide the length of the data block I've generated for the
payload, of course. But I don't care what it looks like on the wire.
> > 
> > ... then the payload contains what you talked about above...
> >   uint16 entirely_redundant_payload_len_again == extlen-2
> >     uint16 ident1_len
> >     char "dave"
> >     uint16 ident2-len
> >     char "nikos"
> >     ...
> right.
> 
> > 
> > Can we ditch the first uint16 in payload, given that it is entirely
> > redundant? Or am I misreading the spec to put it there in the first place,
> > and the formal language is supposed to *include* what I called 'extlen'
>
> According to the protocol tt has to be there.

OK, thanks for confirming that. So that brings me to my next question,
which is... given that the protocol is just a draft, should we propose
*changing* it not to include that redundant length?


-- 
dwmw2


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160917/054c39f8/attachment.bin>