Support TLS False Start

[daurnimator]

As described in RFC 7918

BoringSSL has the flag SSL_MODE_ENABLE_FALSE_START (to be passed to SSL_CTX_set_mode and friends), it seems reasonable to use the same interface.

[anirudhvr]

@richsalz - Hi, is someone working on this?

[richsalz]

As far as I know, nobody is.

[daurnimator]

What are we doing with early-data in TLS 1.3? Any API changes?

[richsalz]

yes there will be API additions for early-data.

[daurnimator]

Have proposed APIs been outlined somewhere? I wonder if there is something that can be shared between false start and early data.

[mattcaswell]

I am still concentrating on the core TLS1.3 implementation. I've not really given early data much thought yet - so, no, I have not outlined an API anywhere.

[richsalz]

And false start isn't the same as early data; the security properties are different: false start can't be replayed, early data can, for example.

[NeetishPathak]

Hi Rich,
As you said, early data can be replayed while false start can't. False start application data is sent after the first round trip is completed during the handshake while early data goes along with the clientHello message specifically for 0-RTT in TLS 1.3 when PSK is available. My doubt is if the application data sent during the early data mode present as clear text?

Is false start API available ? I can see the enable early data API in the TLS 1.3 draft 20 master branch.

[richsalz]

Github pull requests are a bad place to have ongoing discussions. Consider joining the openssl-users mailing list and posting there; https://mta.openssl.org

[daurnimator]

Github pull requests are a bad place to have ongoing discussions. Consider joining the openssl-users mailing list and posting there; https://mta.openssl.org

As someone only keeping a casual eye on things, github pull requests are a much easier place to monitor and post. Once the discussion has concluded, could you post a summary here?

[nhorman]

Marking as inactive, to be closed at the end of 3.4 dev barring further input