Subject: Re: [TLS] Comments on EndOfEarlyData

From: Markulf Kohlweiss <[email-masked]>
Date: Tue, 23 May 2017 11:50:01 +0000

Dear Eric, Britta,

I am paraphrasing a long thread on the issue that we had within
the miTLS development team, and I am primarily commenting on the
analysis aspects. I also hope that it will clarify any remaining
problems of understanding that I have on the issue.

If we see EOED as a stream termination signal, then there seems
to be a difference in performance for conservative servers that
want to wait until receiving all 0RTT data before responding to
the client's request in 0.5RTT communication.

Said otherwise, we want servers to be able to respond with application 
data based on application data from the client and know that that 
that data was not truncated.

==Scenario with EOED as Handshake message==

After the Client sends 0RTT data the Server gets 

CH, APP_C1, APP_C2

and typically responds with 

SH, ... SFIN, APP_S1

But wait, the server doesn't actually know that early data is
terminated. A conservative server would instead send only

SH,... SFIN and wait of EOED

The Client receives SH,... SFIN

Only now the Client knows that the server accepts 0RTT and he can
send and hash the EOED into the transcript hash.

The server receives EOED, CFIN

Only now such a conservative Server can send APP_S1. 

This results in an additional round trip for conservative
servers, and thus discourages the use of EOED as a stream
termination signal.  ---

==Scenario with EOED as Alert==

With an Alert based design for EOED we can instead have the
following flow, where the client immediately sends the EOED after
his request without waiting for the SFIN. Here the client makes the 
conscious choice not to send any additional early data.

The server gets 

CH, APP_C1, APP_C2, 
respond with SH,...SFIN

The server continues reading EOED and is notified about termination 
of 0RTT traffic .

The server can now immediately sends  APP_S1, ....

It is important that the server would send SH regardless of
receiving EOED to avoid deadlock due to clients that wait until
receiving SFIN before sending EOED.  ---

Maybe the implicit assumption is that applications, e.g., HTTP/2
have to do their own termination of requests, and that EED serves
a different purpose? What would be the justification for
providing such a mechanism for 1RTT traffic but not for 0RTT
traffic. And why not enable different usage profiles?

Overall, I find the design based on Alert messages cleaner and
more consistent. From colleagues I heard folklore that it would
also ease verification and reduce the implementation complexity
for modular implementations that want to separate Record Layer
and Handshake Layer concerns.

This is related to verifying the handshake without relying on 
encryption at all but I will let them comment on this if they deem 
it necessary.

--markulf

> On 16. mai 2017 23:28, Eric Rescorla wrote:
>
>> On Tue, May 16, 2017 at 2:41 PM, Britta Hale <[email-masked]> wrote:
>>
>> EOED signals the end of data encrypted with early traffic keys, yes, 
>> and the next message is the Finished message encrypted with the 
>> handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic 
>> key is signaled by the Finished message, not EOED. The Finished 
>> message, like a KeyUpdate message, are handshake messages, and both 
>> signal the start of a new key use for application data.
>>
>> In comparison, EOED signals the end of key use for application data - which
>> correlates
>> to alert behavior.
>
> This seems like a point where reasonable people can differ, especially as ultimately the motivation for this change 
> was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some analytic difficulty, or do you just find it > > unaesthetic?
>
> -Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 May 2017 12:34:44 -0500

My initial thoughts...

> that data was not truncated.

Thanks, the keyword of "truncated" caused me to understand the intended
point.

I think this question ends up tying into the more philosophical one of
whether early data and 1-rtt data are considered "separate streams" or
not -- if they are separate streams with distinct end/start, then of
course one wants to detect possible truncation as it happens.  But, if
they are conceptually the same stream and the boundary between them is
"just" a bookkeeping operation of key change, then there is no need to
be concerned about detecting truncation; the application just continues
reading in data and replying when complete application protocol requests
are received.

-Ben

---

From: Markulf Kohlweiss <[email-masked]>
Date: Tue, 23 May 2017 18:17:40 +0000

Given that 0-RTT and 1-RTT guarantees are very different, it seem important to distinguish the two streams and model them separately.

Of course that does not prevent applications that want to treat them as a single stream, but it is harder to understand the security one gets from such a mixed channel, e.g. some requests may have strong replay protection, others won’t.

--markulf

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: 23 May 2017 18:35
To: Markulf Kohlweiss <[email-masked]>; [email-masked]
Cc: Samin Ishtiaq <[email-masked]>; Antoine Delignat-Lavaud <[email-masked]>; Britta Hale <[email-masked]>
Subject: Re: [TLS] Comments on EndOfEarlyData

My initial thoughts...

Thanks, the keyword of "truncated" caused me to understand the intended point.

I think this question ends up tying into the more philosophical one of whether early data and 1-rtt data are considered "separate streams" or not -- if they are separate streams with distinct end/start, then of course one wants to detect possible truncation as it happens.  But, if they are conceptually the same stream and the boundary between them is "just" a bookkeeping operation of key change, then there is no need to be concerned about detecting truncation; the application just continues reading in data and replying when complete application protocol requests are received.

-Ben

---

From: David Benjamin <[email-masked]>
Date: Tue, 23 May 2017 18:36:33 +0000

On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <[email-masked]> wrote:

> whether early data and 1-rtt data are considered "separate streams" or not
> -- if they are separate streams with distinct end/start, then of course one
> wants to detect possible truncation as it happens.  But, if they are
> conceptually the same stream and the boundary between them is "just" a
> bookkeeping operation of key change, then there is no need to be concerned
> about detecting truncation; the application just continues reading in data
> and replying when complete application protocol requests are received.
>

Truncation detection is meaningful in both cases. We rely on KeyUpdate
being protected and tied to the immediately preceding record (by way of
sequence number). Otherwise an attacker could toss out chunks in the middle
of the stream immediately before a KeyUpdate.

David

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 May 2017 13:44:51 -0500

On 05/23/2017 01:36 PM, David Benjamin wrote:
> On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     I think this question ends up tying into the more philosophical
>     one of whether early data and 1-rtt data are considered "separate
>     streams" or not -- if they are separate streams with distinct
>     end/start, then of course one wants to detect possible truncation
>     as it happens.  But, if they are conceptually the same stream and
>     the boundary between them is "just" a bookkeeping operation of key
>     change, then there is no need to be concerned about detecting
>     truncation; the application just continues reading in data and
>     replying when complete application protocol requests are received.
>
>
> being protected and tied to the immediately preceding record (by way
> of sequence number). Otherwise an attacker could toss out chunks in
> the middle of the stream immediately before a KeyUpdate.
>

Right, but that's also provided for all TLS records by the same
mechanism.  The counterproposal here seems to be for the server
application to consider all the 0-RTT data as a coherent chunk and
provide a single reply to the self-contained application message
contained therein.  That is, it would not expect an application message
to span the 0-RTT/1-RTT boundary.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 May 2017 18:48:25 +0000

> Given that 0-RTT and 1-RTT guarantees are very different, it seem important to distinguish the two streams and model them separately.

Cool; is SChannel going to do that?

OpenSSL does.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 May 2017 20:25:46 +0000

Yes, it is my plan to make 0-RTT data opt-in only in the Windows TLS stack, with a clear distinction in the API.
It is possible, however, that certain middleware components above the TLS stack might choose to blur this distinction (which would be bad design, in my opinion).

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Tuesday, May 23, 2017 11:48 AM
To: Markulf Kohlweiss <[email-masked]>; Kaduk, Ben <[email-masked]>; [email-masked]
Cc: Antoine Delignat-Lavaud <[email-masked]>; Samin Ishtiaq <[email-masked]>; Britta Hale <[email-masked]>
Subject: Re: [TLS] Comments on EndOfEarlyData

OpenSSL does.
_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cdd3c1a8132a34d29c46908d4a20c5706%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636311621300870812&sdata=MXINz0jr8SWWW9GWOt3Ayrojidu3RdiK%2FkBffEZZ0Eo%3D&reserved=0