Subject: Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Oct 2018 13:08:52 -0400

Mirja, just checking in.

The most recent version satisfied Benjamin, and I *think* it satisfies your
comment too.

W

On Thu, Sep 27, 2018 at 12:57 AM Ted Lemon <[email-masked]> wrote:

> Mirja, I notice that you are still holding a discuss on this document.   I
> believe that we addressed the concerns you raised in your discuss.   Could
> you please let us know if there is still work to do on this, and if not,
> clear the discuss?
>
> Thanks!
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Tue, 9 Oct 2018 10:51:52 -0400

Mirja -- checking in again.

W

On Tue, Oct 2, 2018 at 1:08 PM Warren Kumari <[email-masked]> wrote:

> Mirja, just checking in.
>
> The most recent version satisfied Benjamin, and I *think* it satisfies
> your comment too.
>
> W
>
>> Mirja, I notice that you are still holding a discuss on this document.
>>  I believe that we addressed the concerns you raised in your discuss.
>>  Could you please let us know if there is still work to do on this, and if
>> not, clear the discuss?
>>
>> Thanks!
>>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Wed, 10 Oct 2018 11:15:54 +0200

Hi Warren, hi Ted,

sorry I was on holidays a couple of days last week and am completely behind everything. Will try to have a look as soon as possible. Maybe Friday or next week…

Mirja

> Am 09.10.2018 um 16:51 schrieb Warren Kumari <[email-masked]>:
> 
> Mirja, just checking in.. 
> 
> The most recent version satisfied Benjamin, and I *think* it satisfies your comment too.
> 
> W
> 
> Mirja, I notice that you are still holding a discuss on this document.   I believe that we addressed the concerns you raised in your discuss.   Could you please let us know if there is still work to do on this, and if not, clear the discuss?
> 
> Thanks!
> 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Oct 2018 16:04:54 -0400

On Wed, Oct 10, 2018 at 5:15 AM "Mirja Kühlewind (IETF)" <
[email-masked]> wrote:

> Hi Warren, hi Ted,
>
> sorry I was on holidays a couple of days last week and am completely
> behind everything. Will try to have a look as soon as possible. Maybe
> Friday or next week…
>

Ok, thank you.
Not sure i you know, but your mail client has suddenly started putting
bunny ears ( " ) around your name...
W

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 15 Oct 2018 15:21:36 +0200

One minor comment (as I’m reviewing the updated version…)

> Am 02.08.2018 um 08:35 schrieb Ted Lemon <[email-masked]>:
> 
> 4) sec 5.1 "It is a common
>    convention that protocols specified to run over TLS are given IANA
>    service type names ending in "-tls"."
> Not sure this is true. Isn't it usually just an "s" at the end? Or with
> registry are you talking about?
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
> 
> I think the "s" suffix is more for URIs and /etc/services (which is informal).   I've added a reference to the registry.

Actually both is commonly used, -tls or just an s at the end… anyway, not important I guess.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 15 Oct 2018 16:02:26 +0200

Hi Ted,

sorry for the delay, however, as you performed a couple of changes it took me a while to re-review. I believe I’m unfortunately not fully ready to release my discuss at this point, but close..

Regarding my first discuss point (delayed ACKs aso.) I think the text improved and  I would like to seem my minor wording question (comment 2) below addressed before I finally release the discuss here. However, I still think the extensive discussion as provided in section 9.5 now, does not necessarily belong in this document. Therefore I would rather would have preferred to move this text in a real appendix, or removed it completely and maybe document in an own informational RFC (in tcpm).

Regarding my second discuss point (keep-alives), the text seems still not quite right yet, or I’m really confused. Please also see also further below (comment 3).

Anyway here are my comments on the edited/new text in the order they appear in the draft:

1) I think the following text in section 3 is not fully correct:

"Fast Open message: A TCP SYN packet that begins a DSO connection and
   contains early data ([RFC8446] section 2.3).  Fast Open is only
   permitted when using TLS encapsulation: a TCP SYN message that does
   not use TLS encapsulation but contains early data is not permitted.“
If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will „just“ be send at the same time as the TLS handshake is performed (but after the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is used, data can also be sent in the TCP SYN. I guess you mainly need to fix the reference here, or maybe name both mechanisms separately.

2) In section 5.5.1:
   "With a DSO request message, the TCP implementation waits for the
   application-layer client software to generate the corresponding DSO
   response message, which enables the TCP implementation to send a
   single combined IP packet containing the TCP acknowledgement, the TCP
   window update, and the application-generated DSO response message.
   This is more efficient than sending three separate IP packets.“

The phrasing here is a bit confusing, to me at least. It sounds a bit like there is a special TCP for DSO… maybe the following is a bit better:
   "With a DSO request message, TCP delayed acknowledge timer will usually
   make the implementation wait for the
   application-layer client software to generate the corresponding DSO
   response message before it sends out an TCP acknowledgment
   This will generate a 
   single combined IP packet containing the TCP acknowledgement, the TCP
   window update, and the application-generated DSO response message and
   is more efficient than sending three separate IP packets.“

(Note that the deplayed ack timer can be configured to a very small value as well, and as such it depends on the processing time and the value of the timer if a TCP implementation will wait or not.)

3) Section 6.5.2
"For example, a (hypothetical and unrealistic)
   keepalive interval value of 100 ms would result in a continuous
   stream of ten messages per second or more, in both directions, to
   keep the DSO Session alive.  And, in this extreme example, a single
   packet loss and retransmission over a long path could introduce a
   momentary pause in the stream of messages of over 200 ms, long enough
   to cause the server to overzealously abort the connection.“
I think this example is still not correct (and the changes might made have it worse: how can there be more then 10 messages?)

So the point here is that there is a dependency on the RTT. Only if the RTT is smaller than 200ms this can happen, otherwise the connection is closed anyway after two keep-alives. However, if the RTT is much smaller than 100ms and e.g. TLP is used, it would still work even if one packet is lost.

In any case, I don’t think this example is actually very helpful. The point is that the keep-alives interval should always be much larger than the RTT to make this work appropriately. However, the point about keeping the network load is, is rather independent to the question of when the mechanism actually breaks. I would recommend to simply remove this example and just say that the interval MUST not be smaller than 10 sec to keep the network load reasonably low.

However, having read this and the previous section again, I think your implementation of the keep-alives mechanism could also be improved. Usually, there should be two intervals. One defines, how long the connection can be idle before an keeps-live is sent and one that defines when a keeper-lives should be retransmitted if it is deemed to be lost, where the first one just usually be larger than the second one (and both timers should always be larger than the RTT). That would enable faster failure if the connection is actually lost. 

4) Section 6.6.2.2. (Reconnecting After an Unexplained Connection Drop)
  "It is also possible for a server to forcibly terminate the
   connection; in this case the client doesn't know whether the
   termination was the result of a protocol error or a network outage.
   The client could determine which of the two is occurring by noticing
   if a connection is repeatedly dropped by the server; if so, the
   client can mark the server as not supporting DSO.“
How often should the client try and in which interval?

5) Section 9.2:
   "In principle, anycast servers could maintain sufficient state that	
    they can both handle packets in the same TCP connection.“
Really? I mean in theory yes but has this ever been done in practice? I would think that sharing TCP state is even harder than sharing DSO state.

Thanks!
Mirja

> Am 27.09.2018 um 06:57 schrieb Ted Lemon <[email-masked]>:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 15 Oct 2018 16:56:18 +0200

Sorry, one more comment on section 11.1:
"DSO permits zero round-trip operation using TCP Fast Open [RFC7413]	
with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in	
session establishment.“

This sounds like TCP Fast Open and TLS 0-RTT can only be used together. However these are to different mechanism with different properties/problems and I don’t think they should be mixed up.

Data that is send with with TLS 0-RTT must be idempotent as for this data an reply attack is possible which is not the case for the rest of the TLS data. However with TCP without TLS (but maybe TFO) reply attacks are always possible, so that’s not an additional problem if TFO.

With TFO however, a server could start processing without having a return routability proof, however, such a problem can also be addressed on the server-side by simply not stat processing large request before the TCP connection is fully established and that is actually safer than leaving the decisions to the client.

Please clarify that TLS 0-RTT can be used without TFO (or TFO can be used without TLS) and I would also recommend to discuss the respective issue separately.

Mirja

> Am 15.10.2018 um 16:02 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Ted,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Oct 2018 09:51:09 -0500

> This sounds like TCP Fast Open and TLS 0-RTT can only be used together. However these are to different mechanism with different properties/problems and I don’t think they should be mixed up.

If I remember correctly, it was intended in the rev to only use TFP
together with TLS 1.3 0-RTT and disallow using just one, though I forget
exactly how this came out of the discussion from my Discuss point about
specifying the TLS 1.3 0-RTT application profile.

-Benjamin

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Oct 2018 15:51:49 -0400

On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> sorry for the delay, however, as you performed a couple of changes it took
> me a while to re-review. I believe I’m unfortunately not fully ready to
> release my discuss at this point, but close..
>

No worries—it's a busy time.

> Regarding my first discuss point (delayed ACKs aso.) I think the text
> improved and  I would like to seem my minor wording question (comment 2)
> below addressed before I finally release the discuss here. However, I still
> think the extensive discussion as provided in section 9.5 now, does not
> necessarily belong in this document. Therefore I would rather would have
> preferred to move this text in a real appendix, or removed it completely
> and maybe document in an own informational RFC (in tcpm).
>
> Regarding my second discuss point (keep-alives), the text seems still not
> quite right yet, or I’m really confused. Please also see also further below
> (comment 3).
>
> If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will
> „just“ be send at the same time as the TLS handshake is performed (but
> after the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is
> used, data can also be sent in the TCP SYN. I guess you mainly need to fix
> the reference here, or maybe name both mechanisms separately.
>

If you look at the table on p. 18 of RFC8447, it shows early data being
sent in the first packet.  What am I missing here?

> The phrasing here is a bit confusing, to me at least. It sounds a bit like
> there is a special TCP for DSO… maybe the following is a bit better:
> (Note that the deplayed ack timer can be configured to a very small value
> as well, and as such it depends on the processing time and the value of the
> timer if a TCP implementation will wait or not.)
>

I think using the passive voice here makes the text harder to follow, but I
see what you are saying.   How about this:

With a bidirectional exchange over TCP, as for example with a DSO request
message, the operating system TCP implementation waits for the
application-layer client software to generate the corresponding DSO
response message.   It can then send a
single combined packet containing the TCP acknowledgement, the
TCP window update, and the application-generated DSO response message.
This is more efficient than sending three separate packets, as would occur
if
the TCP packet containing the DSO request were acknowledged immediately.

3) Section 6.5.2
> I think this example is still not correct (and the changes might made have
> it worse: how can there be more then 10 messages?)

> So the point here is that there is a dependency on the RTT. Only if the
> RTT is smaller than 200ms this can happen, otherwise the connection is
> closed anyway after two keep-alives. However, if the RTT is much smaller
> than 100ms and e.g. TLP is used, it would still work even if one packet is
> lost.
>

Remember that keepalives are not synchronous.   That is, if we send a
keepalive, we don't wait for the response.   So it's perfectly possible for
there to be several keepalives in flight in this situation, if the RTT is
>200ms.

> In any case, I don’t think this example is actually very helpful. The
> point is that the keep-alives interval should always be much larger than
> the RTT to make this work appropriately. However, the point about keeping
> the network load is, is rather independent to the question of when the
> mechanism actually breaks. I would recommend to simply remove this example
> and just say that the interval MUST not be smaller than 10 sec to keep the
> network load reasonably low.
>
> However, having read this and the previous section again, I think your
> implementation of the keep-alives mechanism could also be improved.
> Usually, there should be two intervals. One defines, how long the
> connection can be idle before an keeps-live is sent and one that defines
> when a keeper-lives should be retransmitted if it is deemed to be lost,
> where the first one just usually be larger than the second one (and both
> timers should always be larger than the RTT). That would enable faster
> failure if the connection is actually lost.
>

A possible point of confusion is that these are not TCP keepalive packets.
 These are DSO messages being sent over the TCP transport.   So it's not
possible for a keepalive to be lost.   If we don't get a response to a
keepalive during the keepalive interval, this means that the TCP connection
has stalled, or that the remote end is no longer reachable.   There is no
retransmission.   Is that where the confusion lies, or am I
misunderstanding?

> How often should the client try and in which interval?

I've added the following text to address this question:

### Misbehaving Clients

A server may determine that a client is not following the protocol
correctly.  There may be no
way for the server to recover the session, in which case the server
forcibly terminates the
connection.  Since the client doesn't know why the connection dropped, it
may reconnect
immediately.  If the server has determined that a client is not following
the protocol
correctly, it may terminate the DSO session as soon as it is established,
specifying a long
retry-delay to prevent the client from immediately reconnecting.

and

#### Reconnecting After an Unexplained Connection Drop {#dropreconnect}

It is also possible for a server to forcibly terminate the connection; in
this case the client doesn't know whether the termination was the result
of a protocol error or a network outage.   When the client notices that
the connection has been dropped, it can attempt to reconnect immediately.
However, if the connection is dropped again without the client being
able to successfully do whatever it is trying to do, it should mark the
server as not supporting DSO.

These two bits of advice, in combination with the surrounding text, should
address the problem you're pointing to.

> Really? I mean in theory yes but has this ever been done in practice? I
> would think that sharing TCP state is even harder than sharing DSO state.
>

I've just deleted this paragraph—I think we were trying to address a
hypothetical scenario here and got a little carried away. :)

> Please clarify that TLS 0-RTT can be used without TFO (or TFO can be used
> without TLS) and I would also recommend to discuss the respective issue
> separately.

As Benjamin said, I took out support for TCP Fast Open without TLS 1.3
because I didn't think it was practical to address the potential issues
with it.   However, in looking back at what I wrote, it's easy to see why
this was confusing.   I've substantially tightened up the text about this:
all cases where terms like "TCP Fast Open" and "0-RTT" are used now refer
to "early data."   The changes are relatively small, but sprinkled over a
whole section, so I don't think it's practical to enumerate them here, but
they should show up nicely in the diffs.   I believe these changes address
your concern, but please let me know if they do not.

https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-17

Thanks!

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 26 Oct 2018 15:35:26 +0200

Hi Ted,

please see below.

> Am 23.10.2018 um 21:51 schrieb Ted Lemon <[email-masked]>:
> 
> On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> If you look at the table on p. 18 of RFC8447, it shows early data being sent in the first packet.  What am I missing here?

I guess you mean RFC8446 :-)

The table there on p.18 shows only the TLS handshake, there is a TCP handshake before that.

> I think using the passive voice here makes the text harder to follow, but I see what you are saying.   How about this:
> 

"the operating system’s TCP implementation will usually wait for"

or even better

„the deplayed acknowledgments timer in TCP will usually wait for"

> TCP window update, and the application-generated DSO response message..
> This is more efficient than sending three separate packets, as would occur if
> Remember that keepalives are not synchronous.   That is, if we send a keepalive, we don't wait for the response.   So it's perfectly possible for there to be several keepalives in flight in this situation, if the RTT is >200ms.

Yes, I misunderstood that initially, however btw. why did you decide to design it that way?
> A possible point of confusion is that these are not TCP keepalive packets.   These are DSO messages being sent over the TCP transport.   So it's not possible for a keepalive to be lost.   If we don't get a response to a keepalive during the keepalive interval, this means that the TCP connection has stalled, or that the remote end is no longer reachable.   There is no retransmission.   Is that where the confusion lies, or am I misunderstanding?

Right, I got actually confused here. So you send data frequently and if something goes wrong the connection will be closed at sender-side. Hm... it seems like if you want to test transport liveness with this (and not application liveness), you might maybe rather want use the existing keep-alive mechanism in TCP…? Why don’t you just recommend to use that?

> A server may determine that a client is not following the protocol correctly.  There may be no
> way for the server to recover the session, in which case the server forcibly terminates the
> connection.  Since the client doesn't know why the connection dropped, it may reconnect
> immediately.  If the server has determined that a client is not following the protocol
> correctly, it may terminate the DSO session as soon as it is established, specifying a long
> These two bits of advice, in combination with the surrounding text, should address the problem you're pointing to.

Yes, I think this is fine now.

> I've just deleted this paragraph—I think we were trying to address a hypothetical scenario here and got a little carried away. :)

Good. Thanks!
> As Benjamin said, I took out support for TCP Fast Open without TLS 1.3 because I didn't think it was practical to address the potential issues with it.

Not sure why you think that/which issues you mean? rfc7413 actually discusses all kind of issues extensively.

>   However, in looking back at what I wrote, it's easy to see why this was confusing.   I've substantially tightened up the text about this: all cases where terms like "TCP Fast Open" and "0-RTT" are used now refer to "early data."   The changes are relatively small, but sprinkled over a whole section, so I don't think it's practical to enumerate them here, but they should show up nicely in the diffs.   I believe these changes address your concern, but please let me know if they do not.
> 

Okay, I believe this is fine now. I guess you could further clarify somewhere that „early data“ is always 0-RTT TLS with or _WITHOUT_ TFO.

Thanks!
Mirja

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Oct 2018 09:59:30 -0400

> I guess you mean RFC8446 :-)
Yup, sorry.

> The table there on p.18 shows only the TLS handshake, there is a TCP

I don't believe this is correct, and given your comment at the end maybe
I'm just misunderstanding.   Are you saying that the TLS handshake is never
included in the SYN packet with TFO, or are you saying that it *might not* be
in the SYN packet?   If the TLS handshake doesn't come in the TFO packet,
there's a round trip, so we have some assurance that we are not being
flooded with TCP SYN packets by an off-link spoofer faking its source
address.   So it's only in the case that TLS 1.3 early data *in the TFO
packet* is an issue.   I suppose because of the way that early data is
handled, if it were present in the third packet there might be some risk,
but to be honest I do not know what the risk would be, and that was not
part of the threat analysis that Benjamin asked us to do (or at least if it
was, I didn't notice, and Benjamin seems okay with the outcome).   If you
think we've missed something here, it would help to get clarity on that.
 I do not claim to be an SME!   If there is an issue, I think the fix would
be to just make the text about early data apply whether it's in a TFO or
not.

> > The phrasing here is a bit confusing, to me at least. It sounds a bit
> like there is a special TCP for DSO… maybe the following is a bit better:
> > (Note that the deplayed ack timer can be configured to a very small
> value as well, and as such it depends on the processing time and the value
> of the timer if a TCP implementation will wait or not.)
> >
> > I think using the passive voice here makes the text harder to follow,
> but I see what you are saying.   How about this:
> >

Is there an error in the text as proposed?   I understand that the way the
text expresses this point is not how you would express the point, but this
feels like a nitpick, not an actual problem in the text.

> > A possible point of confusion is that these are not TCP keepalive
> packets.   These are DSO messages being sent over the TCP transport.   So
> it's not possible for a keepalive to be lost.   If we don't get a response
> to a keepalive during the keepalive interval, this means that the TCP
> connection has stalled, or that the remote end is no longer reachable.
>  There is no retransmission.   Is that where the confusion lies, or am I
> misunderstanding?
>
> Right, I got actually confused here. So you send data frequently and if
> something goes wrong the connection will be closed at sender-side. Hm... it
> seems like if you want to test transport liveness with this (and not
> application liveness), you might maybe rather want use the existing
> keep-alive mechanism in TCP…? Why don’t you just recommend to use that?
>

You mean just use TCP keepalive?   It takes (I think) 90 seconds for a TCP
keepalive to time out the connection.   In some cases this is fine; in
others possibly not.   Doing it at the app layer gives us more flexibility,
and also conveys more information.

> > Please clarify that TLS 0-RTT can be used without TFO (or TFO can be
> used without TLS) and I would also recommend to discuss the respective
> issue separately.
> >
> with it.
> Not sure why you think that/which issues you mean? rfc7413 actually
> discusses all kind of issues extensively.
>
> >   However, in looking back at what I wrote, it's easy to see why this
> was confusing.   I've substantially tightened up the text about this: all
> cases where terms like "TCP Fast Open" and "0-RTT" are used now refer to
> "early data."   The changes are relatively small, but sprinkled over a
> Okay, I believe this is fine now. I guess you could further clarify
> somewhere that „early data“ is always 0-RTT TLS with or _WITHOUT_ TFO.
>

Hm, okay.   As I said earlier, I'm not an SME here.   If there is an issue
with 0-RTT in the third packet of a TCP three-way handshake that didn't use
TFO, I can clarify.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 26 Oct 2018 16:32:55 +0200

Hi Ted,

please see below.

> Am 26.10.2018 um 15:59 schrieb Ted Lemon <[email-masked]>:
> 
> On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> I don't believe this is correct, and given your comment at the end maybe I'm just misunderstanding.   Are you saying that the TLS handshake is never included in the SYN packet with TFO, or are you saying that it might not be in the SYN packet?  

None of both. If TFO is NOT used, there is first a normal TCP handshake and then eventually TLS 0-RTT. TLS 0-RTT only means that you can send data at then same time then the TLS handshake is performed.

If TFO is used, there can be data in the SYN. If TLS is used usually the TLS initial packet would be in that SYN data, however, there might not be enough space to send any other 0-RTT data in that packet because it is really just one packet.

So the answer is that I actually don’t how TFO with TLS 0-RTT is implemented in practice. But for sure without TFO there is the TCP handshake first (one RTT) and then any TLS traffic happens.

Does that help, or was that confusing again?

> If the TLS handshake doesn't come in the TFO packet, there's a round trip, so we have some assurance that we are not being flooded with TCP SYN packets by an off-link spoofer faking its source address.  

No flooding can happen, however, there are migration techniques. E.g. if you are overloaded, don’t process the data immediately or TCP could even drop the data and it would be retransmitted. Yes, this causes additional latency but you would only do that in an attack situation. I believe this is discussed in the TFO RFC7413.

> So it's only in the case that TLS 1.3 early data in the TFO packet is an issue.   I suppose because of the way that early data is handled, if it were present in the third packet there might be some risk, but to be honest I do not know what the risk would be, and that was not part of the threat analysis that Benjamin asked us to do (or at least if it was, I didn't notice, and Benjamin seems okay with the outcome).

There is a replay attack for 0-RTT data in TLS which is independent of use of TFO or not. This is why you should not send none idempotent data in 0-RTT. However, I think this is correctly addressed in the draft.

>   If you think we've missed something here, it would help to get clarity on that.   I do not claim to be an SME!   If there is an issue, I think the fix would be to just make the text about early data apply whether it's in a TFO or not.

Yes, I think the case with and with TFO must be discussed separately.

> Is there an error in the text as proposed?   I understand that the way the text expresses this point is not how you would express the point, but this feels like a nitpick, not an actual problem in the text.

I think it would be important to add the „usually" because the TCP delayed acknowledgement timer is configurable and it depends on it value and the exact timing of the application if what you write is true or not. 

> You mean just use TCP keepalive?   It takes (I think) 90 seconds for a TCP keepalive to time out the connection.   In some cases this is fine; in others possibly not.   Doing it at the app layer gives us more flexibility, and also conveys more information.

The TCP keep-alives is also configurable. (Or at least should be in most implementations.)

> Hm, okay.   As I said earlier, I'm not an SME here.   If there is an issue with 0-RTT in the third packet of a TCP three-way handshake that didn't use TFO, I can clarify.

As I said above, there is a replay attack that is described in RFC8446 (and which I think is sufficiently addressed in your doc). However, it would be good to clarify that both cases are possible, with and without TFO.

Mirja

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Oct 2018 10:58:22 -0400

Okay, I'm going to update the document to add a clarification about the
handling of early data outside of TFO.   I think the keepalive issue is a
matter of judgment, and we would almost have to rewrite the document to
change how that works now.   Looking at the MacOS documentation, I can see
ways that I might be able to get the behavior we want, but I don't know how
available this API is, and I think it's reasonable not to assume that it is
available in all cases.   So unless you absolutely insist, I am not going
to change this.

As for the delayed ack timer implementation, the point of this is to call
the implementor's attention to this.   If they are setting values for the
delayed ack timer, then they already know about this issue; if not, the
default behavior is as described.   Furthermore, one of the goals of this
text is to avoid having the implementor override TCP settings that are
actually correct.   For example, we don't *want *TCP_NODELAY here.   We
don't *want* to disable the delayed ack timer, or to mess with its
duration.   What we want is for normal TCP processing to happen, but for
the app to signal to the tcp stack that it's not going to send a response.
 This is new behavior, which is already available in some commercial
stacks, but not in all stacks, and we want the implementor to use it if
it's there.   That's why this text is here.

On Fri, Oct 26, 2018 at 10:32 AM Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> included in the SYN packet with TFO, or are you saying that it might not be
> in the SYN packet?
>
> None of both. If TFO is NOT used, there is first a normal TCP handshake
> and then eventually TLS 0-RTT. TLS 0-RTT only means that you can send data
> at then same time then the TLS handshake is performed.
>
> If TFO is used, there can be data in the SYN. If TLS is used usually the
> TLS initial packet would be in that SYN data, however, there might not be
> enough space to send any other 0-RTT data in that packet because it is
> really just one packet.
>
> So the answer is that I actually don’t how TFO with TLS 0-RTT is
> implemented in practice. But for sure without TFO there is the TCP
> handshake first (one RTT) and then any TLS traffic happens.
>
> > If the TLS handshake doesn't come in the TFO packet, there's a round
> trip, so we have some assurance that we are not being flooded with TCP SYN
> packets by an off-link spoofer faking its source address.
>
> No flooding can happen, however, there are migration techniques. E.g. if
> you are overloaded, don’t process the data immediately or TCP could even
> drop the data and it would be retransmitted. Yes, this causes additional
> latency but you would only do that in an attack situation. I believe this
> is discussed in the TFO RFC7413.
>
> > So it's only in the case that TLS 1.3 early data in the TFO packet is an
> issue.   I suppose because of the way that early data is handled, if it
> were present in the third packet there might be some risk, but to be honest
> I do not know what the risk would be, and that was not part of the threat
> analysis that Benjamin asked us to do (or at least if it was, I didn't
> notice, and Benjamin seems okay with the outcome).
>
> There is a replay attack for 0-RTT data in TLS which is independent of use
> of TFO or not. This is why you should not send none idempotent data in
> 0-RTT. However, I think this is correctly addressed in the draft.
>
> >   If you think we've missed something here, it would help to get clarity
> on that.   I do not claim to be an SME!   If there is an issue, I think the
> fix would be to just make the text about early data apply whether it's in a
> TFO or not.
>
> > Is there an error in the text as proposed?   I understand that the way
> the text expresses this point is not how you would express the point, but
> this feels like a nitpick, not an actual problem in the text.
>
> I think it would be important to add the „usually" because the TCP delayed
> acknowledgement timer is configurable and it depends on it value and the
> exact timing of the application if what you write is true or not.
>
> >
> > You mean just use TCP keepalive?   It takes (I think) 90 seconds for a
> TCP keepalive to time out the connection.   In some cases this is fine; in
> > Hm, okay.   As I said earlier, I'm not an SME here.   If there is an
> issue with 0-RTT in the third packet of a TCP three-way handshake that
> didn't use TFO, I can clarify.
>
> As I said above, there is a replay attack that is described in RFC8446
> (and which I think is sufficiently addressed in your doc). However, it
> would be good to clarify that both cases are possible, with and without TFO.
>
> Mirja
>
>
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 26 Oct 2018 17:09:26 +0200

Hi Ted,

see inline.

> Am 26.10.2018 um 16:58 schrieb Ted Lemon <[email-masked]>:
> 
> Okay, I'm going to update the document to add a clarification about the handling of early data outside of TFO.   I think the keepalive issue is a matter of judgment, and we would almost have to rewrite the document to change how that works now.   Looking at the MacOS documentation, I can see ways that I might be able to get the behavior we want, but I don't know how available this API is, and I think it's reasonable not to assume that it is available in all cases.   So unless you absolutely insist, I am not going to change this.

I don’t insist. My initial comment was actually about the concrete text and the example you give (less about the mechanism). The point is that there is a dependency on the RTT and in your text you don’t say anything about the RTT which makes it hard to follow. I’m still not sure if that example is needed at all but if you want to keep it, it should be right. 

Also now that I understood what you do, I don’t think it’s the best choice but usually it should be fine.

Still, I would recommend two additional things maybe: 1) Maybe a short discussion that tcp keep-alives could be used if available and configurable instead. And 2) make very clear that it doesn’t make sense to have a keep alive time out that is smaller than the RTT. 

> 
> As for the delayed ack timer implementation, the point of this is to call the implementor's attention to this.   If they are setting values for the delayed ack timer, then they already know about this issue; if not, the default behavior is as described.

Actually different systems have different default values and given this is a sysctl not all people deploying this, maybe be the same ones configuring the system, or might not even have the right to configure the system.

>   Furthermore, one of the goals of this text is to avoid having the implementor override TCP settings that are actually correct.   For example, we don't want TCP_NODELAY here.   We don't want to disable the delayed ack timer, or to mess with its duration.   What we want is for normal TCP processing to happen, but for the app to signal to the tcp stack that it's not going to send a response.   This is new behavior, which is already available in some commercial stacks, but not in all stacks, and we want the implementor to use it if it's there.   That's why this text is here.

Understood. Still the text should be correct :-)

Mirja

> 
> On Fri, Oct 26, 2018 at 10:32 AM Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> Hi Ted,
> 
> please see below.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Oct 2018 11:12:18 -0400

Definitely the text should be correct!   :)

We can't suggest using TCP keepalives as an alternative of app layer
keepalives without breaking interop.   But I will make another pass at the
document later today to try to address the other points we've discussed.
 The discussion about the TCP delayed ack text and the TFO text has been
helpfully clarifying, so thanks for that (not to say the keepalive
discussion wasn't clarifying too—I just don't think I can quite do what
you're asking there).

On Fri, Oct 26, 2018 at 11:09 AM Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> I don’t insist. My initial comment was actually about the concrete text
> and the example you give (less about the mechanism). The point is that
> there is a dependency on the RTT and in your text you don’t say anything
> about the RTT which makes it hard to follow. I’m still not sure if that
> example is needed at all but if you want to keep it, it should be right.
>
> Still, I would recommend two additional things maybe: 1) Maybe a short
> discussion that tcp keep-alives could be used if available and configurable
> instead. And 2) make very clear that it doesn’t make sense to have a keep
> alive time out that is smaller than the RTT.
>
> >
> > As for the delayed ack timer implementation, the point of this is to
> call the implementor's attention to this.   If they are setting values for
> the delayed ack timer, then they already know about this issue; if not, the
> default behavior is as described.
>
> Actually different systems have different default values and given this is
> a sysctl not all people deploying this, maybe be the same ones configuring
> the system, or might not even have the right to configure the system.
>
> >   Furthermore, one of the goals of this text is to avoid having the
> implementor override TCP settings that are actually correct.   For example,
> we don't want TCP_NODELAY here.   We don't want to disable the delayed ack
> timer, or to mess with its duration.   What we want is for normal TCP
> processing to happen, but for the app to signal to the tcp stack that it's
> not going to send a response.   This is new behavior, which is already
> available in some commercial stacks, but not in all stacks, and we want the
> implementor to use it if it's there.   That's why this text is here.
>
> > > I don't believe this is correct, and given your comment at the end
> maybe I'm just misunderstanding.   Are you saying that the TLS handshake is
> never included in the SYN packet with TFO, or are you saying that it might
> not be in the SYN packet?
> >
> > > So it's only in the case that TLS 1.3 early data in the TFO packet is
> an issue.   I suppose because of the way that early data is handled, if it
> > There is a replay attack for 0-RTT data in TLS which is independent of
> use of TFO or not. This is why you should not send none idempotent data in
> > >   If you think we've missed something here, it would help to get
> clarity on that.   I do not claim to be an SME!   If there is an issue, I
> think the fix would be to just make the text about early data apply whether
> it's in a TFO or not.
> >
> > > > The phrasing here is a bit confusing, to me at least. It sounds a
> bit like there is a special TCP for DSO… maybe the following is a bit
> better:
> > > > I think using the passive voice here makes the text harder to
> follow, but I see what you are saying.   How about this:
> > > >
> > I think it would be important to add the „usually" because the TCP
> delayed acknowledgement timer is configurable and it depends on it value
> and the exact timing of the application if what you write is true or not.
> >
> > >
> > > > Remember that keepalives are not synchronous.   That is, if we send
> a keepalive, we don't wait for the response.   So it's perfectly possible
> for there to be several keepalives in flight in this situation, if the RTT
> is >200ms.
> > >
> > > > In any case, I don’t think this example is actually very helpful.
> The point is that the keep-alives interval should always be much larger
> than the RTT to make this work appropriately. However, the point about
> keeping the network load is, is rather independent to the question of when
> the mechanism actually breaks. I would recommend to simply remove this
> example and just say that the interval MUST not be smaller than 10 sec to
> keep the network load reasonably low.
> > > >
> > > > However, having read this and the previous section again, I think
> your implementation of the keep-alives mechanism could also be improved.
> > > Right, I got actually confused here. So you send data frequently and
> if something goes wrong the connection will be closed at sender-side. Hm...
> it seems like if you want to test transport liveness with this (and not
> > > > As Benjamin said, I took out support for TCP Fast Open without TLS
> 1.3 because I didn't think it was practical to address the potential issues
> with it.
> > >
> > > >   However, in looking back at what I wrote, it's easy to see why