Re: [tcpinc] AD review of tcp-eno

["Black, David" <[e-mail]>]

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

Thanks, --David


> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2017 4:36 PM
> To: Mirja Kühlewind <[e-mail]>; draft-ietf-tcpinc-
> [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, July 26, 2017 1:07 PM
> > To: [e-mail]
> > Subject: AD review of tcp-eno
> >
> > 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
> >