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
