0-RTT stuff

[mwelzl]

5.3. Handling of data for fast-open protocols

The text needs to clarify how 0-RTT data is handled by the API.
Naively, I would expect that 0-RTT data must be supplied with the
connection request, since it is sent with the handshake, after all.
However, sec. 5.3 para. 3 sent. 2 suggests that 0-RTT data that is
provided to the API needs to be marked with specific properties that
all 0-RTT would have to be marked with, implying that the API is
provided with the data in a separate call from the connection request
call. How 0-RTT data is provided in API call(s) should be made clear
at the beginning of para. 3, as that is the background for everything
following.

An implementation can set this property
according to the protocols that it will race based on the given
Selection Properties when the application requests to establish a
connection.

How is the zeroRttMsgMaxLen value derived from the zeroRttMsgMaxLen
properties of the individual protocols that will potentially be used by
connection establishment? I'd guess that it is the minimum of them,
but in that case, if both a fast-open and a non-fast-open protocol
might be used, then zeroRttMsgMaxLen will be 0 and the application
will never get the benefit of fast-open. OTOH, if zeroRttMsgMaxLen is

0, what happens if it is the non-fast-open protocol that succeeds?

In any case, if zeroRttMsgMaxLen is returned by the connection
establishment API request, how does the application provide the 0-RTT
data before the first connection request is sent?

In another aspect, the set of protocols that will be raced will only
be determined during the connection establishment process. E.g. the
usable protocols may depend on the host addresses. There is no way in
general for the API call to know which protocols might be used unless
either the API call finishes after the needed information is known, or
if the API call assumes that all protocols the implementation supports
might be used.

It is also possible for Protocol Stacks within a particular leaf node
to use 0-RTT handshakes without any safely replayable application
data if a protocol in the stack has idempotent handshake data to
send. For example, TCP Fast Open could use a Client Hello from TLS
as its 0-RTT data, shortening the cumulative handshake time.

This should be clarified. The data in question isn't 0-RTT data from
the application's perspective, and so that name shouldn't be applied
here without qualification. Perhaps

It is also possible for a protocol implementation in a Protocol
Stack for a particular leaf node to use 0-RTT data in a lower-level
protocol to carry its own handshakes; in such cases, whether the
data involved is safely replayable is determined by the protocol
implementation that generates the handshake data, not the
application (which does not generate the data). For example, TCP
Fast Open could use a Client Hello from TLS as its 0-RTT data,
shortening the cumulative handshake time.

---

From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.

[tfpauly]

• Mention how to provide zeroRttMsgMaxLen. It's going to be based on previous state for resumable connections (the min of the ones where you can actually attempt 0-RTT), otherwise it's some max value

[mwelzl]

This needs a change to API 8.1.11.1: it is no longer a readable "Connection" property but a readable "Preconnection" property.