Subject: Open-source TLS 1.3 with an API suitable for QUIC?

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 3 May 2017 08:37:09 +0000

Hi,

I've been looking at https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft and wondering which open-source TLS implementations are suitable for providing the required TLS 1.3 functionality over UDP. Specifically, for a C implementation.

(There is a list of implementations at https://github.com/tlswg/tls13-spec/wiki/Implementations, but it's not clear which - if any - expose an API that would be suitable for operating over UDP, for use with a QUIC stack.)

Any pointers?

Thanks,
Lars

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 3 May 2017 18:06:59 +0900

Just FYI,

I maintain picotls (one of the pure-C TLS 1.3 implementations listed
on the wiki) which I have designed with QUIC in mind. The API of
picotls is designed like a codec (rather than an abstraction layer on
top of the sockets API) so that it can be naturally integrated with
UDP-based protocols.

Actually, I have started working on to implement QUIC using the
library and have a dedicated branch for adding the missing parts that
are required for QUIC[1]. I believe that the only piece that is
missing at the moment is the Exporter.

[1] https://github.com/h2o/picotls/tree/kazuho/quic

-- 
Kazuho Oku

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 May 2017 12:28:49 +0000

> wondering which open-source TLS
> implementations are suitable for providing the required TLS 1.3 functionality
> over UDP. Specifically, for a C implementation.

If there are API's that OpenSSL would need to provide, please let me know (ideally within a month) and we will work to provide them.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 May 2017 07:32:37 -0700

I believe that NSS already has essentially what you would need, but if it
doesn't,
please file bugs.

-Ekr

On Wed, May 3, 2017 at 1:37 AM, Eggert, Lars <[email-masked]> wrote:

> Hi,
>
> I've been looking at https://github.com/quicwg/base-drafts/wiki/First-
> Implementation-Draft and wondering which open-source TLS implementations
> are suitable for providing the required TLS 1.3 functionality over UDP.
> Specifically, for a C implementation.
>
> (There is a list of implementations at https://github.com/tlswg/
> tls13-spec/wiki/Implementations, but it's not clear which - if any -
> expose an API that would be suitable for operating over UDP, for use with a
> QUIC stack.)
>
> Any pointers?
>
> Thanks,
> Lars
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 3 May 2017 14:47:53 +0000

The biggest one (and I don't know if OpenSSL has it) is the ability to get the actual bytes that TLS wants to send, rather than having the library own the socket and try to send by itself.  With NSS, apparently you need to pass it a fake socket and grab the bytes that it tries to send, which is a bit of a pain.  SChannel's model just returns byte buffers to the caller, and it's their job to then transport them, which is mostly what's needed here.

Then there's the ability to add an extension for the QUIC parameters.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Wednesday, May 3, 2017 5:29 AM
To: Eggert, Lars <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC?

> implementations are suitable for providing the required TLS 1.3 
> functionality over UDP. Specifically, for a C implementation.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 May 2017 15:23:22 +0000

> The biggest one (and I don't know if OpenSSL has it) is the ability to get the
> actual bytes that TLS wants to send, rather than having the library own the
> socket and try to send by itself.  With NSS, apparently you need to pass it a
> fake socket and grab the bytes that it tries to send, which is a bit of a pain.
> SChannel's model just returns byte buffers to the caller, and it's their job to
> then transport them, which is mostly what's needed here.

Yes, it  can be done using a "fake BIO" which is the OpenSSL I/O abstraction; you can read/write memory.  It's also not terrible convenient.
 
> Then there's the ability to add an extension for the QUIC parameters.

This we have, and it's in better shape :)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 May 2017 09:07:12 -0700

On Wed, May 3, 2017 at 7:47 AM, Mike Bishop <[email-masked]>
wrote:

> The biggest one (and I don't know if OpenSSL has it) is the ability to get
> the actual bytes that TLS wants to send, rather than having the library own
> the socket and try to send by itself.  With NSS, apparently you need to
> pass it a fake socket and grab the bytes that it tries to send, which is a
> bit of a pain.

Yeah, but it's pretty straightforward. See:
http://searchfox.org/nss/source/gtests/ssl_gtest/test_io.h#53

SChannel's model just returns byte buffers to the caller, and it's their
> job to then transport them, which is mostly what's needed here.
>

Right. We would need to add that. We haven't added that to NSS, but it's
not cpmplicated

-Ekr

> If there are API's that OpenSSL would need to provide, please let me know
> (ideally within a month) and we will work to provide them.
>
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 4 May 2017 06:08:44 +0000

Hi,

On 2017-5-3, at 16:47, Mike Bishop <[email-masked]> wrote:
> The biggest one (and I don't know if OpenSSL has it) is the ability to get the actual bytes that TLS wants to send, rather than having the library own the socket and try to send by itself.

exactly. And - since I'm trying to reduce memory copies - I'd like to pass TLS the buffers and have it operate on them, ideally in place.

Lars