From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH 8/9] tls: Allow user to set custom list of cipher suites
Date: Fri, 14 Dec 2018 13:57:29 -0600 [thread overview]
Message-ID: <e6547197-e66e-6ab3-85dc-1d68b135feab@gmail.com> (raw)
In-Reply-To: <CAOq732Kz4kKcv7iB4wfaqswsZgy4rZNW55Hq0rycYPF5ONLbfg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
Hi Andrew,
>> Yes, but you also have to consider the audience for our TLS
>> implementation. It isn't browsers. It is just iwd and maybe eventually
>> ConnMan for the portals stuff. So can we optimize the API for those use
>> cases ?
>
> I don't think we should but ok. BTW we won't be Suite B compliant for
> a while still because of the DSA certificates and likely more things.
Right, I forgot SuiteB actually implies DSA. But we don't need SuiteB
anyway. WPA3 allows:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA38
ECDHE using the 384-bit prime modulus curve P-384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
So perhaps we just need a 'WPA3' selector. And once we have SuiteB
support, then we can add TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 to WPA3
selector as well.
> BTW since tls.c is pretty big we could split out all the cipher suite
> definitions and the functions used by them into tls-suites.c or
> similar. For ECDHE we'll need to add extensions support and I'm also
> thinking of defining the extensions in a new file tls-extensions.c
> (we'll support very few initially but the different specs actually
> define many).
Sure. At 3kloc tls.c isn't too bad, but we can break it up. Propose
something.
Regards,
-Denis
next prev parent reply other threads:[~2018-12-14 19:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 19:57 [PATCH 1/9] tls: Don't send Client Hello in l_tls_new Andrew Zaborowski
2018-12-13 19:57 ` [PATCH 2/9] unit: Call l_tls_start in tls tests Andrew Zaborowski
2018-12-13 19:57 ` [PATCH 3/9] tls: Add TLS version number printf macros Andrew Zaborowski
2018-12-14 15:53 ` Denis Kenzior
2018-12-14 18:48 ` Andrew Zaborowski
2018-12-13 19:57 ` [PATCH 4/9] tls: Implement l_tls_set_version_range Andrew Zaborowski
2018-12-14 15:55 ` Denis Kenzior
2018-12-13 19:57 ` [PATCH 5/9] unit: Test TLS 1.0, 1.1 and 1.2 Andrew Zaborowski
2018-12-13 19:57 ` [PATCH 6/9] unit: Move tls_cert_load_file to relevant unit tests Andrew Zaborowski
2018-12-14 16:01 ` Denis Kenzior
2018-12-13 19:57 ` [PATCH 7/9] tls, pem: Drop tls_cert_load_file, l_pem_load_certificate Andrew Zaborowski
2018-12-13 19:57 ` [PATCH 8/9] tls: Allow user to set custom list of cipher suites Andrew Zaborowski
2018-12-14 16:33 ` Denis Kenzior
2018-12-14 19:12 ` Andrew Zaborowski
2018-12-14 19:28 ` Denis Kenzior
2018-12-14 19:49 ` Andrew Zaborowski
2018-12-14 19:57 ` Denis Kenzior [this message]
2018-12-13 19:57 ` [PATCH 9/9] unit: Test many TLS cipher suite and version combinations Andrew Zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6547197-e66e-6ab3-85dc-1d68b135feab@gmail.com \
--to=denkenz@gmail.com \
--cc=ell@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.