Subject: Re: [tcpinc] AD review of tcp-eno

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 27 Jul 2017 15:14:40 +0200

Resending because I just realized I forgot to cc the list…

> Am 26.07.2017 um 19:06 schrieb Mirja Kühlewind <[email-masked]>:
> 
> Hi all,
> 
> thanks for this very well written document and detailed shepherd write-up!
> 
> I’m afraid we need a new revision before IETF Last Call because the RFC should only specify the actually TCP option and not the experimental one. So you can simply remove the experimental one in Figure 1, 2 and 3 (as well as sec 4.8) and only note in the IANA section that this experimental assignment also exists, as it is already done.
> 
> Other minor comments:
> 
> 1) I would recommend to switch the last to paragraphs in section 4.5; I think that helps understanding.
> 
> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that the other end is likely to support tcp-eno and the tep (e.g. due to previous successful connections aka session resumption, or application knowledge).
> 
> 3) Sec 4.8 does not really specify what to do with the transcript. I guess that’s TEP specific but it sounds like there should be a requirement stated that a TEP has to check this or abort the connection…?
> 
> 4) sec 5:
> s/TEPs MUST protect TCP data streams with authenticated encryption./TEPs MUST protect TCP data streams with unauthenticated encryption./ ? Or do you mean must support both, authenticated and unauthenticated?
> 
> 5) section 6: Maybe
> OLD
> "Figure 9 shows a three-way handshake with a successful TCP-ENO
>   negotiation.  The two sides agree to follow the TEP identified by
>   suboption Y.“
> NEW
> "Figure 9 shows a three-way handshake with a successful TCP-ENO
>   negotiation. Host A includes two ENO suboptions with TEP identifiers X and Y. 
>   The two sides agree to follow the TEP identified by suboption Y.“ 
> 
> 6) Also looking at the example in Figure 11, I have to say that the spec does not clearly state anywhere that the first ACK has to have a ENO option (it’s only mention implicitly somewhere). Maybe that can be spelled out more clearly (in section 4.6)?
> 
> 7) Also based on this example. I guess it’s also possible that a middlebox does not strip the options in the SYN packets but only in the ACK. In this case host A would send encrypted data and host B would think they are not encrypted and deliver garbage to the application. I’m not sure how to avoid or even detect such a case but maybe it’s still good to mention this somewhere…?
> 
> 8) section 7.2: The following is a normative requirement thats should be stated normatively (MUST) somewhere in the main part of the specification:
> "To stay robust in the face of dropped segments, hosts must continue
>   to include non-SYN form ENO options in segments until such point as
>   they have received a non-SYN segment from the other side.“
> 
> 9) I would recommend to move 7.1 into an own section (not as part of section 7 on rational), or maybe rather as a subsection of section 8.
> 
> 10) From reading the text in the IANA section, I believe you rather what „RFC required“ as a policy (see https://tools.ietf.org/html/rfc8126#section-4.7). Early allocation are always possible and does not need to be noted separately (see https://tools.ietf.org/html/rfc8126#section-3.4).
> 
> 11) Do you want to specially note Andrea’s contribution to this work in the acknowledgements?
> 
> 12) RFC5226 (now RFC8126), RFC6994 (after removing the exp option from the body of the doc), and RFC7413 do not need to be normative references. Please move to informative.
> 
> 12) Finally, two tiny things from the nits check:
> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tcpinc-tcpeno-08.txt
> - There shouldn’t be reference in the abstract. You can just remove it; TLS is well known. You may want to add it in section 7.1 instead.
> - RFC 5226 is obsolete
> Both could be fixed by the editor but as you anyway have to make a new revision, so you can fix these as well.
> 
> Thanks!
> Mirja
> 
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 27 Jul 2017 13:20:05 +0000

And likewise resending this follow-up as draft shepherd ...

Thanks, --David

> -----Original Message-----
> From: Black, David [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2017 4:36 PM
> To: Mirja Kühlewind <[email-masked]>; draft-ietf-tcpinc-
> [email-masked]
> Subject: RE: AD review of tcp-eno
> 
> Hi Mirja,
> 
> Many thanks for your careful review and comments.
> 
> In section 5, I believe we are dealing with a terminology collision:
> 
> > 4) sec 5:
> > s/TEPs MUST protect TCP data streams with authenticated
> encryption./TEPs
> > MUST protect TCP data streams with unauthenticated encryption./ ? Or do
> > you mean must support both, authenticated and unauthenticated?
> 
> The original text is correct, so this change should not be made, but that
> original text is highly susceptible to being misread, and hence does need
> attention to improve clarity.   For reasons that only security experts will be
> able explain :-), "authenticated encryption" does not include or require
> endpoint authentication.  Here's the relevant definition from Section 1 of RFC
> 5116:
> 
>    Authenticated encryption [BN00] is a form of encryption that, in
>    addition to providing confidentiality for the plaintext that is
>    encrypted, provides a way to check its integrity and authenticity.
> 
> https://tools.ietf.org/html/rfc5116#section-1
> 
> I suggest adding text to section 5 of this draft to repeat or paraphrase this
> RFC 5116 definition, and informatively cite RFC 5116 as the source.
> 
> I'll also take a small mea culpa on the IANA Considerations - I should've
> caught that in WG Last Call.
> 
> Thanks, --David
> 
> 
> > -----Original Message-----
> > From: Mirja Kühlewind [mailto:[email-masked]]
> > Sent: Wednesday, July 26, 2017 1:07 PM
> > To: [email-masked]
> > Subject: AD review of tcp-eno
> >
> > Hi all,
> >
> > I’m afraid we need a new revision before IETF Last Call because the RFC
> > should only specify the actually TCP option and not the experimental one.
> So
> > you can simply remove the experimental one in Figure 1, 2 and 3 (as well as
> > sec 4.8) and only note in the IANA section that this experimental
> assignment
> > also exists, as it is already done.
> >
> > Other minor comments:
> >
> > 2) I’m wondering if it would make sense to specify at the beginning of
> section
> > 4.7 another requirement that TEPs SHOULD only specify the use of SYN
> data
> > if there is some a-priori knowledge that the other end is likely to support
> tcp-
> > eno and the tep (e.g. due to previous successful connections aka session
> > resumption, or application knowledge).
> >
> > 3) Sec 4.8 does not really specify what to do with the transcript. I guess
> that’s
> > TEP specific but it sounds like there should be a requirement stated that a
> > TEP has to check this or abort the connection…?
> >
> > 4) sec 5:
> > s/TEPs MUST protect TCP data streams with authenticated
> encryption./TEPs
> > MUST protect TCP data streams with unauthenticated encryption./ ? Or do
> > you mean must support both, authenticated and unauthenticated?
> >
> > 5) section 6: Maybe
> > OLD
> >    negotiation. Host A includes two ENO suboptions with TEP identifiers X
> and
> > Y.
> > 6) Also looking at the example in Figure 11, I have to say that the spec does
> > not clearly state anywhere that the first ACK has to have a ENO option (it’s
> > only mention implicitly somewhere). Maybe that can be spelled out more
> > clearly (in section 4.6)?
> >
> > 7) Also based on this example. I guess it’s also possible that a middlebox
> does
> > not strip the options in the SYN packets but only in the ACK. In this case
> host
> > A would send encrypted data and host B would think they are not
> encrypted
> > and deliver garbage to the application. I’m not sure how to avoid or even
> > detect such a case but maybe it’s still good to mention this somewhere…?
> >
> > 8) section 7.2: The following is a normative requirement thats should be
> > stated normatively (MUST) somewhere in the main part of the
> specification:
> > 9) I would recommend to move 7.1 into an own section (not as part of
> > section 7 on rational), or maybe rather as a subsection of section 8.
> >
> > 10) From reading the text in the IANA section, I believe you rather what
> „RFC
> > required“ as a policy (see https://tools.ietf.org/html/rfc8126#section-4.7).
> > Early allocation are always possible and does not need to be noted
> separately
> > (see https://tools.ietf.org/html/rfc8126#section-3.4).
> >
> > 12) RFC5226 (now RFC8126), RFC6994 (after removing the exp option from
> > the body of the doc), and RFC7413 do not need to be normative
> references.
> > Please move to informative.
> >
> > - There shouldn’t be reference in the abstract. You can just remove it; TLS is
> > well known. You may want to add it in section 7.1 instead.
> > - RFC 5226 is obsolete

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2017 07:25:27 -0700

On 7/27/2017 6:14 AM, Mirja Kuehlewind (IETF) wrote:
> ...
First, as an Experimental RFC, I don't think it would be appropriate to
assign a codepoint that requires a standards-track doc.

Second, regardless of whether the IESG decides to override that
requirement, this document needs to address how to handle packets with
the ExID values that have already been assigned if they are considered
to be part of the transition plan (though it would be better to describe
a transition plan). Per RFC6994, the authors do need to address this
issue, especially indicating that connections should *not* include both
variants in the same segment.

Finally, IMO, if a TCP option codepoint is assigned, I strongly
recommend not poisoning the codepoint space with a "fresh" assignment,
nor should the developers be rewarded for squatting on a value. The only
appropriate solution IMO, in that case, would be to assign this option
to a codepoint already squatted **by another party**. In that case,
their deployment would appropriately suffer from the impact of squatting.

>> Other minor comments:
...
>> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that th…
That section does not appear to address the case where non-user data in
the SYN is received by a legacy receiver, either because of first
contact or in contacting a host that has changed configuration since
last contact. In such cases, there is no way to support transparent
fallback as required by RFC 1122 -- which is why it is avoided at all
costs. AFAICT, this optimization is too hazardous to include at all.

Joe

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 27 Jul 2017 17:21:57 +0200

Hi Joe,

thanks for your feedback. See comments inline.

> Am 27.07.2017 um 16:25 schrieb Joe Touch <[email-masked]>:
> 

We have actually assigned quite a couple of option numbers to experimental RFCs lately, given it is very common to go for experimental first in transport. As this work is chartered for experimental, we will go with IESG approval in this case, however, maybe we should consider to change the policy to "IESG Approval or RFC Required“ instead.

> variants in the same segment.

That’s right. I though RFC6994 would make a general recommendation here. But I guess it’s anyway good to add one sentence that implementations that following this specification should actually not respond to the experimental option. Thanks for noting.

> their deployment would appropriately suffer from the impact of squatting.

While I know the problems with squatting that we have, I don’t think is a suitable option to enable good deployment for this or any new IETF protocols that we invested a lot of time in. I though we had this discussion already and concluded that the best viable option for this case is the number that they already squatted on. Let’s go for this path.

> costs. AFAICT, this optimization is too hazardous to include at all.

It does. The initiator must reset the connection in this case. It’s phrased slightly complicated but it is specified. Maybe this can be clarified a bit better/described earlier in the text.

Mirja

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2017 08:40:01 -0700

Hi, Mirja,

On 7/27/2017 8:21 AM, Mirja Kuehlewind (IETF) wrote:
> We have actually assigned quite a couple of option numbers to experimental RFCs lately, given it is very common to go for experimental first in transport. 
I have raised concerns with this practice in other cases, so I'll raise
it here. The whole point of experimental is for these cases. The TCP
option space is littered with failed experiments, and should not be --
that is exactly what the mechanism in RFC6994 is intended for.

> As this work is chartered for experimental, we will go with IESG approval in this case, however, maybe we should consider to change the policy to "IESG Approval or RFC Required“ instead.
The current requirement is "IESG approval or standards-track RFC
required" - an intentionally high bar. There's no good reason to lower
that bar, esp. for small codepoint spaces in core Internet protocols.

> That’s right. I though RFC6994 would make a general recommendation here. But I guess it’s anyway good to add one sentence that implementations that following this specification should actually not…
Actually, this RFC ought to clearly indicate this assignment and have
normative language for addressing segments with it and the IANA
instructions ought to indicate that the assignment should point to this
RFC. Otherwise we lose a documentation trail.

> While I know the problems with squatting that we have, I don’t think is a suitable option to enable good deployment for this or any new IETF protocols that we invested a lot of time in. 
Actually, I think this is EXACTLY the kind of option to do this - those
who create the problem of squatting should experience the impact of
their actions.

> I though we had this discussion already and concluded that the best viable option for this case is the number that they already squatted on. 
I don't know if we did, but I don't think that's appropriate - it
encourages squatting by rewarding it.
> It does. The initiator must reset the connection in this case.
I would assume then that NO TCP connection is possible to that endpoint
- i.e., by aborting the connection, you're saying that this endpoint is
not reachable because it's "ENO or nothing".

If so, that needs to be made very clear - especially that it is not
appropriate for the TCP layer to try another connection without ENO
(i.e., transparent fallback NEVER involves multiple connection attempts
- otherwise you're violating RFC1122).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2017 08:50:12 -0700

FWIW:

> - otherwise you're violating RFC1122).

The text does address this case, but still a bit too vague IMO. I'd
appreciate an explicit statement highlighting interaction with legacy
receivers, including a note that even a previously-visited ENO node
might be legacy upon next contact, and stating that the connection abort
MUST NOT include an automatic subsequent attempt at fallback, e.g.,
because BOTH this violates the nature of ENO (once the client wants ENO,
it's ENO-or-nothing) *and* because automatic fallback would violate TCP
semantics.

Joe

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 27 Jul 2017 18:58:13 +0200

Hi Joe,

replying separately to separate topics:

> Am 27.07.2017 um 17:40 schrieb Joe Touch <[email-masked]>:
> 

Yes, this is true. However in practice we use the experimental option for experimentation during draft status and have often assigned the code point at publication time of the RFC. 

In case of tcpinc/tcpeno I think this is qualified because there is agreement that this extension is value to TCP. This experiment is rather on figuring out if the specification is correct and comprehensive.

However, if you want to have this discussion in more general term, it should happen on the tcpm list instead.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:01:37 +0200

Hi again,

> encourages squatting by rewarding it.

I totally understand your viewpoint here. However, if you want to find a way to penalize squatting, this is not it. The squatting was induced by individuals before this proposal was brought to the IETF. TCP-eno will now be published as an IETF consensus document as as such we as a community should provide support to make its deployment successful.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 27 Jul 2017 19:05:05 +0200

Hi Joe again,

see below.

> Am 27.07.2017 um 17:50 schrieb Joe Touch <[email-masked]>:
> 
> FWIW:
> 
> 
>> not reachable because it's "ENO or nothing“.

No. SYN data is not used by default. As such they could anyway only be used by an tcp-eno aware host. Such a host could decide to retry tcp-eno without syn-data or even tcp with tcp-eno.

>> - otherwise you're violating RFC1122).

Again there is no transparent fallback. There is an error message to the application and the application can decide what to do.

> it's ENO-or-nothing) *and* because automatic fallback would violate TCP

Agreed. These are good points to note more explicitly.

Mirja

---

From: David Mazieres <[email-masked]>
Date: Thu, 27 Jul 2017 13:29:05 -0700

"Mirja Kuehlewind (IETF)" <[email-masked]> writes:

> I’m afraid we need a new revision before IETF Last Call because the
> RFC should only specify the actually TCP option and not the
> experimental one. So you can simply remove the experimental one in
> Figure 1, 2 and 3 (as well as sec 4.8) and only note in the IANA
> section that this experimental assignment also exists, as it is
> already done.

Thanks for the feedback.  Just to confirm, is this still what we should
do after the discussion?  Or are there other things we need to add (like
Joe's suggestion not to send both option types)?

> I think that helps understanding.

Good idea, but requires a little wordsmithing.  Here is the proposed new
language:

        A passive opener (which is always host B) sees the remote host's
        SYN segment before constructing its own SYN-ACK segment.  Hence,
        a passive opener SHOULD include only one TEP identifier in
        SYN-ACK segments and SHOULD ensure this TEP identifier is valid.
        However, simultaneous open or implementation considerations can
        prevent host B from offering only one TEP.

        To accommodate scenarios in which host B sends multiple TEP
        identifiers in the SYN-ACK segment, the _negotiated TEP_ is
        defined as the last valid TEP identifier in host B's SYN-form
        ENO option.  This definition means host B specifies TEP
        suboptions in order of increasing priority, while host A does
        not influence TEP priority.

> section 4.7 another requirement that TEPs SHOULD only specify the use
> of SYN data if there is some a-priori knowledge that the other end is
> likely to support tcp-eno and the tep (e.g. due to previous successful
> connections aka session resumption, or application knowledge).

This may be true for SYN-only segments, but doesn't necessarily hold for
SYN-ACK.  To my mind, the requirement that "To avoid unexpected
connection aborts, ENO implementations MUST disable the use of data in
SYN-only segments by default" is both stronger and more specific than
saying only with a-priori knowledge.  Essentially we are saying the
application has to request it.

So for now I haven't done anything with this feedback.  Let me know if
you have a more specific suggestion.

> 3) Sec 4.8 does not really specify what to do with the transcript. I
> guess that’s TEP specific but it sounds like there should be a
> requirement stated that a TEP has to check this or abort the
> connection…?

What to do with the transcript is highly TEP specific, but since every
TEP will need to reference a transcript to comply with the requirements
of section 5.1, it seemed simpler and less error prone to define one
explicitly as part of TCP-ENO.  The connection doesn't need to be
aborted, but the session IDs won't match.  Basically the transcript is
required for the following point in section 5.1:

  The session ID MUST depend in a collision-resistant way on all of
  the following (meaning it is computationally infeasible to produce
  collisions of the session ID derivation function unless all of the
  following quantities are identical):
    ...
    * The negotiation transcript specified in 4.8.

So for now I haven't done anything, but am open to more suggestions if
you think this still needs to be fixed.

> s/TEPs MUST protect TCP data streams with authenticated encryption./TEPs MUST protect TCP data streams with unauthenticated encryption./ ? Or do you mean must support both, authenticated and unauth…

As David Black pointed out, the language was correct but maybe
confusing.  Here is the new proposed language:

  TEPs MUST protect TCP data streams with authenticated encryption.
  (Note "authenticated encryption" designates the REQUIRED form
  encryption algorithm [@RFC5116]; it does not imply any actual
  endpoint authentication.)

>   The two sides agree to follow the TEP identified by suboption Y.“ 

Fixed.

> 6) Also looking at the example in Figure 11, I have to say that the
> spec does not clearly state anywhere that the first ACK has to have a
> ENO option (it’s only mention implicitly somewhere). Maybe that can be
> spelled out more clearly (in section 4.6)?

This was the intent of the first sentence of section 4.6:

        A host employing TCP-ENO for a connection MUST include an ENO
        option in every TCP segment sent until either encryption is
        disabled or the host receives a non-SYN segment.

Rather than fiddle with 4.6, I propose clarifying section 6 as follows:

        (1) A -> B:  SYN      ENO<X,Y>
        (2) B -> A:  SYN-ACK  ENO<b=1,X> [ENO stripped by middlebox]
        (3) A -> B:  ACK
        [rest of connection unencrypted legacy TCP]

        Figure 11: Failed TCP-ENO negotiation because of network filtering

        Figure 11 Shows another handshake with a failed encryption
        negotiation. In this case, the passive opener B receives an ENO
        option from A and replies. However, the reverse network path
        from B to A strips ENO options. Hence, A does not receive an ENO
        option from B, disables ENO, and does not include a non-SYN-form
        ENO option in segment 3 when ACKing B's SYN. Had A not disabled
        encryption, Section 4.6 would have required it to include a
        non-SYN ENO option in segment 3. The omission of this option
        informs B that encryption negotiation has failed, after which
        the two hosts proceed with unencrypted TCP.

> 7) Also based on this example. I guess it’s also possible that a
> middlebox does not strip the options in the SYN packets but only in
> the ACK. In this case host A would send encrypted data and host B
> would think they are not encrypted and deliver garbage to the
> application. I’m not sure how to avoid or even detect such a case but
> maybe it’s still good to mention this somewhere…?

I propose addressing this in section 8, as follows:

        Once TCP-ENO is deployed, we will be in a better position to
        gather data on two types of failure:
        ...
        2. Middleboxes causing TCP-ENO connections to fail
           completely. This can happen if middleboxes perform deep
           packet inspection and start dropping segments that
           unexpectedly contain ciphertext, or if middleboxes
           inconsistently strip ENO options from packets in the same
           direction.

>   they have received a non-SYN segment from the other side.“

I have deleted the word "must" from here.  Section 7 is not intended to
be normative, but rather describe the rationale for having made this
requirement elsewhere in the document.

> section 7 on rational), or maybe rather as a subsection of section 8.

Is this because you thought section 7.1 was trying to establish
normative requirements?  A lot of those details were previously more
closely intermingled with the specification, which the working group did
not like.  Now that we've got those points separated out into section 7
but still part of the document, I think it reads more cleanly.  Hence,
my inclination would be to leave 7.1 as is (other than deleting "must"),
but if you want to elaborate on why it should be moved, you can probably
change my mind.

> 10) From reading the text in the IANA section, I believe you rather
> what „RFC required“ as a policy (see
> https://tools.ietf.org/html/rfc8126#section-4.7). Early allocation are
> always possible and does not need to be noted separately (see
> https://tools.ietf.org/html/rfc8126#section-3.4).

The specification required was intentional, because we wanted to avoid
the same chicken-and-egg problem caused by the need for a TCP option.
Since the point of TCP-ENO is to make it significantly easier to develop
future TEPs than it would be to develop TCP encryption schemes from
scratch, and since the TCP option for tcpcrypt and TCP-ENO caused a fair
amount of friction in the TCPINC working group, I feel reasonably
strongly that it would be best to give out TEP identifiers well in
advance of RFC publication, provided there is a plausible draft
specification.

My strong preference would thus be to leave things as is, but of course
in the end I would defer to you if based on your experience you really
think it needs to be RFC required.

> 11) Do you want to specially note Andrea’s contribution to this work

Hmm... we definitely want to leave Andrea as first author the same as if
he hadn't died, reflecting the fact that he was the main person behind
the work.  If we put anything in the acknowledgments, it could diminish
his contributions by emphasizing the fact that other people had to
"finish" the document, when really what we are doing at this point is
just tiny little cleanups.

> references. Please move to informative.

Fixed.

> Both could be fixed by the editor but as you anyway have to make a new revision, so you can fix these as well.

Both fixed.

If you just confirm what to do about the TCP option kinds and obviously
voice any objections to my proposed fixes above, we can get a new draft
uploaded soon.

Thanks,
David

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:12:21 +0200

Hi David,

thanks for your quick reply!

See below.

> Am 27.07.2017 um 22:29 schrieb David Mazieres <[email-masked]>:
> 
> do after the discussion?  

Yes, in any case we should not have both in the RFC. Given we are fostering deployment with the current version but just don’t have enough deployment experience yet to go for standards track, we will request the option number with IESG Approval. So please remove the experimental option from the spec and just note it in the IANA section.

> Or are there other things we need to add (like

That would be good, too; also in the IANA section probably.

Just to confirm this. All comments below are simply comments that came to my mind as I reviewed the whole document. The only other thing I really like to have sorted out before we go to IETF Last call, is the question which IANA policy is the correctly. All other of these changes are not required to move the document forward. However, as we update anyway, it’s probably good to add those things that help clarification. But that’s on you to decide! 

>        not influence TEP priority.

Looks good!

> application has to request it.

Okay, your are actually right that what I phrased above is probably rather something to notice for the application that will use a TEP than a requirement for the TEP itself.

> you have a more specific suggestion.

If you want to and if you think that would help clarity, you can notice that an application that has a-priori knowledge about the other end could be a good use case.

> you think this still needs to be fixed.

Okay, you are right that is actually covered. So it’s more an editorial issue because at the time you are reading section 4.8, you basically have no idea why this is needed (beside that it logically makes sense to have it). Maybe add a forward reference?

>  endpoint authentication.)

Thanks. That was probably basically just me being not familiar enough with the terminology but adding this explanation certainly doesn’t hurt.

>        disabled or the host receives a non-SYN segment.

Yes, this is covered. However, this is was not fully obvious to me when I was reading it, even though it’s the only logical way to read this. I guess it wouldn’t hurt to make it slight more clear, e.g. by saying

"A host employing TCP-ENO for a connection MUST include a (non-SYN) ENO
      option in every TCP segment sent until either encryption is
      disabled or the host receives a non-SYN segment, starting this the 
      first ACK of the TCP 3-way handshake.“

Does that make sense?

>        the two hosts proceed with unencrypted TCP.

Also good!

>           inconsistently strip ENO options from packets in the same

I would even mention the case, where SYN Options are passed but non-SYN options are not, separately because in this case both hosts would have a different view if eno was negotiated or not. In this situation the host that believes that eno was negotiated should fail at some point and abort the connection because the crypto negotiation or, in case of resumption, decryption would fail. But in theory it can happen that the host that believe eno is not used, would deliver garbage data to the application. I think that’s the point that needs separate noting. Or am I misunderstanding something?

> requirement elsewhere in the document.

Actually the word must is fine. I didn’t realize that this is already normatively stated in section 4.6. Maybe put a reference… or not.

> normative requirements?  

No, it just that I think ‚future development‘ are not ‚design rationales‘. This comment is fully editorial though. The content is fine. I just think it be a better fit in section 8.

> A lot of those details were previously more

This is what early allocation is for. We could have also asked for early allocation for tcpinc as soon as the spec was reasonably stable but given there was no-one who was actually about to deploy this in the Internet, it was probably not necessary. 

Also I assume your intention here is that you still want to have an RFC at the end. If you go for „Specification required“ any kind of spec would be accepted and it doesn’t have to be an RFC. Therefor „RFC Required“ would be better.

Also, as I said it is not necessary to note explicitly that early allocation is possible (because that’s always possible), but you can still make a point that people are encourage to ask for early allocation (at wg adoption time?).

> think it needs to be RFC required.

Again, if I understand your intention correctly, the right policy still seems to be „RFC required“. Btw. RFC required does not mean IETF consensus required. This can also be an IRTF stream or ISE stream publication. (If you would like IETF consensus for the RFCs, the right policy would be „IETF Rewiew“; check RFC 8126 for more details).

> just tiny little cleanups.

Yes, he definitely is and should stay the main author! However, you can even say exactly this (he did all the work and others where just wrapping up) in the acknowledgments! I’m mainly saying that it is not uncommon to saying something in the acknowledgements, so please feel free to add whatever you think is appropriate and would underline his mayor contribution he provided!

> voice any objections to my proposed fixes above, we can get a new draft

Great! Please also check Joe’s comments on SYN data. There might be another few things to note to improve clarity on the usage. 

Let me know if you have any more questions!

Thanks!
Mirja

---

From: Kyle Rose <[email-masked]>
Date: Fri, 28 Jul 2017 11:58:55 -0400

It seems we've mostly hit on what needs to be done for the next draft, but
I wanted to address one item:

On Fri, Jul 28, 2017 at 9:12 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> This is what early allocation is for. We could have also asked for early
> allocation for tcpinc as soon as the spec was reasonably stable but given
> there was no-one who was actually about to deploy this in the Internet, it
> was probably not necessary.
>
> Also I assume your intention here is that you still want to have an RFC at
> the end. If you go for „Specification required“ any kind of spec would be
> accepted and it doesn’t have to be an RFC. Therefor „RFC Required“ would be
> better.
>
> Also, as I said it is not necessary to note explicitly that early
> allocation is possible (because that’s always possible), but you can still
> make a point that people are encourage to ask for early allocation (at wg
> adoption time?).
>

Does it make sense to allocate a few TEP IDs (e.g., 0x7c-0x7f) as explicit
"for testing purposes: not for production use" IDs that implementors can
use in testing? Another alternative is an explicit ExID-like mechanism, but
that seems far too heavy-weight for something like ENO. A range like this
would at least offer implementors a no-effort way to do their own
development and testing without poisoning other TEP IDs.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Fri, 28 Jul 2017 15:35:38 -0400

On Fri, Jul 28, 2017 at 2:17 PM, David Mazieres expires 2017-10-26 PDT <
[email-masked]>
wrote:

> Kyle Rose <[email-masked]> writes:
>
> The document already reserves 0x20 for experimental use.

Evidently, I must have glossed over that entry in table 2 a half-dozen
times over the past two years. Heh. I think we're good on that point.

>   I'm a little
> hesitant to go allocating the top end of the space, because in the
> unlikely event that ENO is so successful we project running out of code
> points, we might want to use the low two bits of 0x7c-0x7f or 0x78-0x7f
> as the first three bits of a 10- or 11-bit extended TEP Id.

Hopefully that's a lot of crypto evolution away. Certainly, if we make the
standard "RFC", then many documents would likely have to be published
before we were in danger of exhausting this space.

> Is one
> experimental TEP ID not enough?
>

I was thinking of implementors developing multiple TEPs simultaneously,
like you did with both of the NIST curves. Is this realistic? I don't know.
Will it be confusing to have two separate experimental ID spaces? Possibly.
Can implementors just encode their algorithm choices as suboption data?
Yes. So it's probably not a big deal.

> The intention with 0x20 is eventually to specify an ExID-like mechanism,
> but I think maybe we felt it was premature to do so in this document.
> We could also add vaguer language about how users of 0x20 should start
> options with two or more identifier bytes to leave open the possibility
> of interoperating with other experiments.
>

Without a registry of TEP ExIDs, conflicts between experimental TEPs are
likely to happen if this mechanism takes off and those experiments are
deployed on the public internet. Does it matter if it's just an experiment?
Possibly, if the TEP designer decides they need test results at scale
before even approaching the IETF. Maybe the guidance in this doc should be
for the first two bytes of the 0x20 suboption data to be 00 00, which
leaves us room in the future to create a TEP ExID standard with the hope
that the other 65535 values are unused.

Kyle

---

From: David Mazieres <[email-masked]>
Date: Fri, 28 Jul 2017 13:21:50 -0700

> development and testing without poisoning other TEP IDs.

The document already reserves 0x20 for experimental use.  I'm a little
hesitant to go allocating the top end of the space, because in the
unlikely event that ENO is so successful we project running out of code
points, we might want to use the low two bits of 0x7c-0x7f or 0x78-0x7f
as the first three bits of a 10- or 11-bit extended TEP Id.  Is one
experimental TEP ID not enough?

David

---

From: David Mazieres <[email-masked]>
Date: Fri, 28 Jul 2017 13:22:40 -0700

"Mirja Kuehlewind (IETF)" <[email-masked]> writes:

> This is what early allocation is for. We could have also asked for
> early allocation for tcpinc as soon as the spec was reasonably stable
> but given there was no-one who was actually about to deploy this in
> the Internet, it was probably not necessary.

Is there something I can put in the document to clarify that early
allocation should be the norm not the exception?  The think I like about
"Specification required" is that RFC7120 2a says:

       The code points must be from a space designated as "RFC
       Required", "IETF Review", or "Standards Action".  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC.

So I like the fact that the specification required allows early
allocation *if* an RFC is anticipated.

Basically I want something in this document to make it clearly easier to
get ENO TEP IDs than TCP option kinds.

On a related note, I think there might be an inconsistency in the draft
that I would appreciate some input in resolving.  Section 7.1 says:

        TLS can currently only be added to legacy applications whose
        protocols accommodate a STARTTLS command or equivalent.
        TCP-ENO, because it provides out-of-band signaling, opens the
        possibility of future TLS revisions being generically applicable
        to any TCP application.

Of course what, we really wanted to say was TCP-ENO was designed to
support TCP-use-TLS.  However, if I recall, there's a citation issue
because we aren't supposed to cite an internet draft in an RFC unless
the two will become RFCs at the same time, and TCP-use-TLS has been
delayed.  But then in 0x30, we still cite TCP-Use-TLS to assign it code
point 0x30.

Given the work invested in TCP-Use-TLS, should we indeed reserve TEP Id
0x30 for that effort in case anyone wants to pick up it up again, and if
so how should we do that without citing an expired internet draft?  Can
we just reserve TEP ID 0x30 for future use by TLS and cite TLS?  Or what
should we do?

Thanks,
David

---

From: "Black, David" <[email-masked]>
Date: Fri, 28 Jul 2017 20:56:37 +0000

> delayed.  But then in 0x30, we still cite TCP-Use-TLS to assign it code

This is not an actual problem, as the restriction is that one is not supposed to *normatively* cite an Internet-Draft in an RFC unless that draft is expected to become an RFC soon, otherwise the RFC-to-be spends a long time at the RFC Editor waiting for the normatively referenced draft to catch up to it (I've been there, done that).

Citing an Internet-Draft *informatively* is not a problem, will not cause any delays, and seems appropriate for this situation.

Thanks, --David

> From: Tcpinc [mailto:[email-masked]] On Behalf Of David Mazieres
> Sent: Friday, July 28, 2017 4:23 PM
> To: Mirja Kuehlewind (IETF) <[email-masked]>
> Cc: [email-masked]; tcpinc <[email-masked]>
> Subject: Re: [tcpinc] AD review of tcp-eno
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc