enable DTLS negotiation

[Nikos Mavrogiannopoulos]

On Fri, 2016-09-16 at 16:30 +0100, David Woodhouse wrote:
> On Fri, 2016-09-16 at 15:07 +0200, Nikos Mavrogiannopoulos wrote:
> > 
> > 
> > Ok. For openconnect client it would be fairly easy to handle this,
> > only send an extension with fairly static data, as it only sends a
> > username. However, there is a catch, we should do that for both
> > openssl and gnutls. Ocserv would require to be able to parse the
> > TLS
> > client hello since the extension data are in variable positions,
> > however that shouldn't be really hard. I could do the ocserv part
> > and
> > the gnutls part if you do the openssl part :)
> Have I got the actual payload of the extension right? I've done it as
> an ASN.1 SEQUENCE containing one or more (in our case just one) ASN.1
> OCTET-STRINGs each with an identity.


opaque psk_identity<1..2^16-1>;
psk_identity identity_list<1..2^16-1>;

That means that for id 'psk' you have:

|uint16(size of psk + 2)||uint16(size of psk)||psk|

or |uint16(5)||uint16(3)||psk|
      2-bytes  2-bytes    3-bytes

Where the uint16 is in big-endian order.


> (I note that TLS1.3 is different here, and each PskIdentity contains
> also a PskKeyExchangeMode and a PskAuthenticationMode. Is that likely
> to end up in the draft for 1.2 before it becomes final?)

Interesting. The draft-jay-tls-psk was simply a copy of the tls 1.3 psk
id. They seemed to introduce the PskIdentity thing on the latest
revision. I really doubt TLS 1.3 will be materialized any time at all.
Anyway maybe we should discuss with the authors of the psk-identity
extension. They will be probably as surprised as we, but may have some
proposal.

regards,
Nikos