Re: [TLS] Separate APIs for 0-RTT

[Loganaden Velvindron <[e-mail]>]

On Tue, Jun 13, 2017 at 2:54 PM, Ilari Liusvaara
<[e-mail]> wrote:
> On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote:
>> The current text says:
>>
>>    0-RTT data has very different security properties from data
>>    transmitted after a completed handshake: it can be replayed.
>>    Implementations SHOULD provide different functions for reading and
>>    writing 0-RTT data and data transmitted after the handshake, and
>>    SHOULD NOT automatically resend 0-RTT data if it is rejected by the
>>    server.
>>
>> I think the second piece of guidance (about automatic re-send) is still
>> good but it seems like implementations are mostly converging on a single
>> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have
>> a single API and OpenSSL's use of two APIs is an outlier. I don't think
>> it's helpful to have a SHOULD that a lot of people violate, especially when
>> this also indicates we don't have consensus on this SHOULD.
>>
>> I propose we remove this recommendation in favor of one which simply says
>> that implementations should need applications to opt-in to 0-RTT. That
>> would allow implementations to have either API.
>
> I think it is VERY bad idea for TLS client library to do 0-RTT without
> application explicitly opting in to that (e.g., via setting a special
> setting, or using API call sequences that didn't work at all for
> n-RTT).
>

I also agree here.