Draft: draft-ietf-taps-interface

Commentary: This replaces a previous PR for the same issue , which I deleted : in this PR , I just the definition of idempotency from RFC 7231 , but this is n't good enough . We ca n't guarantee that these Messages would only consecutively arrive as duplicates , so these should be called " safely replayable " instead . See the discussion in . 
 Sorry , I do n't understand the point here . Why is it important that messages arrive " consecutively as duplicates " ? 
 See the discussion in ; the issue is explained in the last message there from 
 From  : idempotency ! = replay - safe . DELETE is idempotent , but not safe for replay because someone might have done a PUT or POST in the meantime . What I mean is maybe best illustrated by  in TLS or QUIC . If a user sends a 0RTT DELETE /object , followed by a PUT /object , then within the replay window and without any replay prevention at the application layer , an attacker could replay the 0RTT DELETE /object and cause the object to be deleted again . DELETE is idempotent but it 's not safe to replay . 
 This seems to me to be a case of arrival of Message X , followed by Message Y , followed by Message X. I do n't think that TFO , TLS or QUIC would by themselves do this - it 's always about immediate repetition of the first Message only , is n't it ? Maybe we should just clarify that idempotency in our case means that a Message may arrive multiple times with nothing in between on the same Connection . Thoughts ? 
 I do n't know if the draft should get into defining what " idempotent " means : it has a well - defined mathematical definition , but one that seems to be less well - defined in protocol design . IMO , just use less ambiguous phrasing . 
 True , that . s / idempotent / repeatable ? 
 I would go with " safely replayable " to emphasize the attack aspect . 
 For what it 's worth : RFC 7231 , Section 4.2.2 of HTTP defines idempotent clearly : " A request method is considered " idempotent " if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request . " " safely repayable " - would need a little more context to explain why it is safe .. maybe you could copy part of this definition . 
 Can we cite that section of RFC 7231 for idempotency , perhaps even quote the meaning that has copied here , and be done with this ? 
 I think I 'm not being clear about my objection here . I know what idempotent means , and agree that RFC 7231 captures it . ( " A request method is considered " idempotent " if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request . " ) The issue is with an idempotent request that is repeated with a different request in between . DELETE , for instance , will do the same thing if multiple identical requests are performed , but if a PUT or POST occurs in between , the second DELETE will remove a different object than the one from the first DELETE . Let 's say the user does this : PUT /object ( with content 1 ) DELETE /object PUT /object ( with content 2 ) The state of /object after this sequence is that it exists with content 2 . Idempotency admits the following : PUT /object ( with content 1 ) DELETE /object PUT /object ( with content 2 ) REPLAY : DELETE /object The state of /object after this sequence is that it does not exist . Similarly : PUT /object ( with content 1 ) PUT /object ( with content 2 ) REPLAY : PUT /object ( with content 1 ) The state of /object after this sequence is that it exists with content 1 . Replay safety would mean that the state after a sequence including a replayed request is identical to the state without the replayed request . 
 Then this is what I thought you meant in the first place ! Then I agree about " safely replayable " and will make a PR that explains what this is , and replaces idempotent with " safely replayable " everywhere . 
 This seems to me to be a layering - perspective . I think we know how to fix this by using uniquely identifiable transactions e.g. delete " last " is never idempotent ; whereas delete " " is because executing it twice has no effect ; however ordering still has effect - because if " " does n't exist when asked to delete this has no effect . As for me , I think we do n't teach how to use datagrams / messages here . So I do n't mind what words are used - or where this refers to the transport service offered or the use of the transport service . A proposed change is likely good for me . 
 I have no objection to the new choice of term . Thanks ! Noted one nit , otherwise LGTM !
Paragraph (version A):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times (i.e.,
multiple copies of the message data may be passed to the Remote
Endpoint).  See also msg-idempotent.  Note that disabling this
property has no effect for protocols that are not connection-oriented
and do not protect against duplicated messages, e.g., UDP.
Paragraph (version B):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times (i.e.,
multiple copies of the message data may be passed to the Remote
Endpoint).  See also msg-safelyreplayable.  Note that disabling this
property has no effect for protocols that are not connection-oriented
and do not protect against duplicated messages, e.g., UDP.
Paragraph (version A):
Once Initiate is called, the candidate Protocol Stack(s) may cause
one or more candidate transport-layer connections to be created to
the specified remote endpoint.  The caller may immediately begin
sending Messages on the Connection (see sending) after calling
Initiate(); note that any idempotent data sent while the Connection
is being established may be sent multiple times or on multiple
candidates.
Paragraph (version B):
Once Initiate is called, the candidate Protocol Stack(s) may cause
one or more candidate transport-layer connections to be created to
the specified remote endpoint.  The caller may immediately begin
sending Messages on the Connection (see sending) after calling
Initiate(); note that any data marked "Safely Replayable" that is
sent while the Connection is being established may be sent multiple
times or on multiple candidates.
Paragraph (version A):
Note that for protocols that do not protect against duplicated
messages, e.g., UDP, all messages MUST be marked as Idempotent.  In
order to enable protocol selection to choose such a protocol,
Idempotent MUST be added to the TransportProperties passed to the
Preconnection.  If such a protocol was chosen, disabling Idempotent
on individual messages MUST result in a SendError.
Paragraph (version B):
Note that for protocols that do not protect against duplicated
messages, e.g., UDP, all messages MUST be marked as "Safely
Replayable".  In order to enable protocol selection to choose such a
protocol, "Safely Replayable" MUST be added to the
TransportProperties passed to the Preconnection.  If such a protocol
was chosen, disabling "Safely Replayable" on individual messages MUST
result in a SendError.
Paragraph (version A):
Whenever possible, a messageContext should be provided to declare the
message passed to InitiateWithSend as idempotent.  This allows the
transport system to make use of 0-RTT establishment in case this is
supported by the available protocol stacks.  When the selected
stack(s) do not support transmitting data upon connection
establishment, InitiateWithSend is identical to Initiate() followed
by Send().
Paragraph (version B):
Whenever possible, a messageContext should be provided to declare the
Message passed to InitiateWithSend as "Safely Replayable".  This
allows the transport system to make use of 0-RTT establishment in
case this is supported by the available protocol stacks.  When the
selected stack(s) do not support transmitting data upon connection
establishment, InitiateWithSend is identical to Initiate() followed
by Send().
Paragraph (version A):
In some cases it may be valuable to know whether data was read as
part of early data transfer (before connection establishment has
finished).  This is useful if applications need to treat early data
separately, e.g., if early data has different security properties
than data sent after connection establishment.  In the case of TLS
Thus, receivers may wish to perform additional checks for early data
to ensure it is idempotent or not replayed.  If TLS 1.3 is available
and the recipient Message was sent as part of early data, the
corresponding metadata carries a flag indicating as such.  If early
data is enabled, applications should check this metadata field for
Messages received during connection establishment and respond
accordingly.
Paragraph (version B):
In some cases it may be valuable to know whether data was read as
part of early data transfer (before connection establishment has
finished).  This is useful if applications need to treat early data
separately, e.g., if early data has different security properties
than data sent after connection establishment.  In the case of TLS
Thus, receivers may wish to perform additional checks for early data
to ensure it is safely replayable.  If TLS 1.3 is available and the
recipient Message was sent as part of early data, the corresponding
metadata carries a flag indicating as such.  If early data is
enabled, applications should check this metadata field for Messages
received during connection establishment and respond accordingly.
Paragraph (version A):
This property represents the maximum Message size that can be sent
before or during Connection establishment, see also msg-idempotent.
It is given in Bytes.
Paragraph (version B):
This property represents the maximum Message size that can be sent
before or during Connection establishment, see also msg-
safelyreplayable.  It is given in Bytes.
Paragraph (version A):
Idempotent: when this is true, it means that the Message can be
used by mechanisms that might transfer it multiple times - e.g.,
as a result of racing multiple transports or as part of TCP Fast
Open.
Paragraph (version B):
Safely Replayable: when this is true, it means that the Message
can be used by mechanisms that might transfer it multiple times -
e.g., as a result of racing multiple transports or as part of TCP
Fast Open.
Paragraph (version A):
If the application has 0-RTT data to send in any protocol handshakes,
it needs to provide this data before the handshakes have begun.  When
racing, this means that the data should be provided before the
process of connection establishment has begun.  If the application
wants to send 0-RTT data, it must indicate this to the implementation
by setting the Idempotent send parameter to true when sending the
data.  In general, 0-RTT data may be replayed (for example, if a TCP
SYN contains data, and the SYN is retransmitted, the data will be
retransmitted as well), but racing means that different leaf nodes
have the opportunity to send the same data independently.  If data is
truly idempotent, this should be permissible.
Paragraph (version A):
It is also possible that protocol stacks within a particular leaf
node use 0-RTT handshakes without any idempotent application data.
For example, TCP Fast Open could use a Client Hello from TLS as its
0-RTT data, shortening the cumulative handshake time.
Paragraph (version B):
If the application has 0-RTT data to send in any protocol handshakes,
it needs to provide this data before the handshakes have begun.  When
racing, this means that the data should be provided before the
process of connection establishment has begun.  If the application
wants to send 0-RTT data, it must indicate this to the implementation
by setting the "Safely Replayable" send parameter to true when
sending the data.  In general, 0-RTT data may be replayed (for
example, if a TCP SYN contains data, and the SYN is retransmitted,
the data will be retransmitted as well), but racing means that
different leaf nodes have the opportunity to send the same data
independently.  If data is truly safely replayable, this should be
permissible.
Paragraph (version B):
It is also possible that protocol stacks within a particular leaf
node use 0-RTT handshakes without any safely replayable application
data.  For example, TCP Fast Open could use a Client Hello from TLS
as its 0-RTT data, shortening the cumulative handshake time.
Paragraph (version A):
CONNECT.TCP with parameter "user message".  Early idempotent data
is sent on a TCP Connection in the SYN, as TCP Fast Open data.
Paragraph (version B):
CONNECT.TCP with parameter "user message".  Early safely
replayable data is sent on a TCP Connection in the SYN, as TCP
Fast Open data.
Paragraph (version A):
Early idempotent data is supported by TLS 1.3, and sends encrypted
application data in the first TLS message when performing session
resumption.  For older versions of TLS, or if a session is not
being resumed, the initial data will be delayed until the TLS
handshake is complete.  TCP Fast Option can also be enabled
automatically.
Paragraph (version B):
Early safely replayable data is supported by TLS 1.3, and sends
encrypted application data in the first TLS message when
performing session resumption.  For older versions of TLS, or if a
session is not being resumed, the initial data will be delayed
until the TLS handshake is complete.  TCP Fast Open can also be
enabled automatically.