Re: ktls-utils and gnutls

Re: ktls-utils and gnutls

[Chuck Lever III]

> On Jan 12, 2024, at 3:41 AM, Daiki Ueno <ueno@gnu.org> wrote:
> 
> Hello Chuck,
> 
> I am Daiki from the GnuTLS team; nice to meet you.
> 
> We are currently collecting project ideas for GSoC[1] and I wonder if we
> could include something related to ktls-utils (tlshd), as it currently
> uses GnuTLS as the backend and I thought students may be interested in
> getting hands-on experience with both kernel and security.
> 
> A couple of things that come to my mind are:
> 
> 1. make use of the GnuTLS handshake API to bypass record layer
>   interaction as mentioned at [2]
> 
> 2. provide some experimental mechanism (kernel module?) to allow
>   userspace applications to use that facility sorely with the POSIX
>   networking API (as in tlssock[3]), though I know that it's explicitly
>   marked as out of scope of the project
> 
> Before adding those to the ideas page I would like to hear your opinion;
> any suggestions would be appreciated.
> 
> Footnotes:
> [1]  https://gitlab.com/gnutls/gnutls/-/wikis/Projects-for-newcomers
> 
> [2]  https://bugzilla.redhat.com/show_bug.cgi?id=2182151#c61
> 
> [3]  https://github.com/enarx-archive/tlssock

Hello Daiki -

I've copied a mailing list with my ktls-utils collaborators.
Maybe Hans has a suggestion?

--
Chuck Lever

Re: ktls-utils and gnutls

[Hannes Reinecke]

On 1/12/24 15:06, Chuck Lever III wrote:
> 
> 
>> On Jan 12, 2024, at 3:41 AM, Daiki Ueno <ueno@gnu.org> wrote:
>>
>> Hello Chuck,
>>
>> I am Daiki from the GnuTLS team; nice to meet you.
>>
>> We are currently collecting project ideas for GSoC[1] and I wonder if we
>> could include something related to ktls-utils (tlshd), as it currently
>> uses GnuTLS as the backend and I thought students may be interested in
>> getting hands-on experience with both kernel and security.
>>
>> A couple of things that come to my mind are:
>>
>> 1. make use of the GnuTLS handshake API to bypass record layer
>>    interaction as mentioned at [2]
>>
>> 2. provide some experimental mechanism (kernel module?) to allow
>>    userspace applications to use that facility sorely with the POSIX
>>    networking API (as in tlssock[3]), though I know that it's explicitly
>>    marked as out of scope of the project
>>
>> Before adding those to the ideas page I would like to hear your opinion;
>> any suggestions would be appreciated.
>>
>> Footnotes:
>> [1]  https://gitlab.com/gnutls/gnutls/-/wikis/Projects-for-newcomers
>>
>> [2]  https://bugzilla.redhat.com/show_bug.cgi?id=2182151#c61
>>
>> [3]  https://github.com/enarx-archive/tlssock
> 
> Hello Daiki -
> 
> I've copied a mailing list with my ktls-utils collaborators.
> Maybe Hans has a suggestion?
> 
There are some issues which could've been addressed:

1. Multiple PSK keys per ClientHello: the RFC allows for multiple
    PSKs to be sent with each ClientHello, yet gnutls implements
    only support for a single PSK. This is getting interesting
    when several cipher suites with different lengths or different
    scopes are supported, and the server could pick the appropriate
    one instead of having the client to retry a ClientHello with
    every available PSK.

2. Support for SPDM device attestation certificates: SPDM has defined
    the use of X.509 certificates for device attestation. But as these
    certificates are not bound to a network instance SPDM makes use
    of 'Subject Alternative Name' with a distinct OID. It would be
    good to implement support for SPDM X.509 certificates as chances
    are they will become more prevalent.
    And any implementor will need to generate valid SPDM certificates
    to test out the implementation ...

Cheers,

Hannes

Re: ktls-utils and gnutls

[Daiki Ueno]

Hannes Reinecke <hare@suse.de> writes:

> There are some issues which could've been addressed:
>
> 1. Multiple PSK keys per ClientHello: the RFC allows for multiple
>    PSKs to be sent with each ClientHello, yet gnutls implements
>    only support for a single PSK. This is getting interesting
>    when several cipher suites with different lengths or different
>    scopes are supported, and the server could pick the appropriate
>    one instead of having the client to retry a ClientHello with
>    every available PSK.
>
> 2. Support for SPDM device attestation certificates: SPDM has defined
>    the use of X.509 certificates for device attestation. But as these
>    certificates are not bound to a network instance SPDM makes use
>    of 'Subject Alternative Name' with a distinct OID. It would be
>    good to implement support for SPDM X.509 certificates as chances
>    are they will become more prevalent.
>    And any implementor will need to generate valid SPDM certificates
>    to test out the implementation ...

Thank you.  I've added both ideas to the list.

Regards,
-- 
Daiki Ueno