On Wed, May 3, 2017 at 7:31 PM, Martin Thomson
wrote:
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear. Otherwise, beware. The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactivel
On 4 May 2017 at 12:29, Salz, Rich wrote:
> That's kind of inflammatory. Apology accepted :)
Yep, a bit stronger than ideal, sorry.
> I don't want to make things hard. I want to make them clear and merging
> two sets of data with different security properties does not seem like it's
> help
> Because doing anything else makes it a lot harder for the application.
>
> I realize that you *want* that, but clearly we disagree about the
> utility of API hurdles. Given that the application already took
> extraordinary steps to enable 0-RTT, we don't think that adding
> artificial hurd
On 4 May 2017 at 11:41, Benjamin Kaduk wrote:
> A related question is whether NSS wants to be a general-purpose TLS library,
> or an HTTP-specific TLS library. I have mostly come to terms with the HTTP
> application profile for 0-RTT saying "combine the streams" (but still want
> to see it writte
On 05/03/2017 08:35 PM, Martin Thomson wrote:
> On 4 May 2017 at 11:31, Salz, Rich wrote:
>> Well, for example, Chrome/boringSSL should arguably know better but are
>> treating it all as one equivalent stream.
>>
>> Is FF/NSS doing the same thing?
> Yes.
>
>> Why?
> Because doing anything else ma
