Subject: Re: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 5 Feb 2017 06:57:09 +0000

[CCing TCPM for the part that matters to TCPM]

> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this?  E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
> 
> 4.a. Citing drafts does go against the current BCP, as I understand it.
> 
> From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box:
> “Under no circumstances should an Internet-Draft be referenced by any paper,
> report, or Request-for-Proposal, nor should a vendor claim compliance with an
> Internet-Draft.”
> 
> There’s a partial exception right afterward, which I’m not sure how well it
> applies in this case:
> “
>    Note: It is acceptable to reference a standards-track specification
>    that may reasonably be expected to be published as an RFC using the
>    phrase "Work in Progress" without referencing an Internet-Draft.
>    This may also be done in a standards track document itself as long
>    as the specification in which the reference is made would stand as a
>    complete and understandable document with or without the reference to
>    the "Work in Progress".
> “
> 
> 4.b. the moral case for truth in advertising:
> 
> That said, I do think it’s reasonable to make the point that extending SYN
> option space would benefit ENO, and to point to evidence of ongoing work in
> that direction, even if it’s a long shot.
> 
> I also agree that one of the cited drafts is legitimately attempting something
> that would help ENO in this way if it continues to move forward
> (https://tools.ietf.org/html/draft-touch-tcpm-tcp-syn-ext-opt-06). In my
> original comment, one of the 2 alternatives I suggested as an edit was to
> continue to cite that draft, but to point out that it’s experimental.
> 
> However, I think 2 of the citations currently used as evidence are misleading,
> one of them because it shows no signs of moving forward toward any form of
> adoption (https://tools.ietf.org/html/draft-briscoe-tcpm-inspace-mode-tcpbis-
> 00), and the other because it does not apply to SYN or SYN-ACK
> (https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-07), and therefore
> wouldn’t help ENO’s use case. That is why I suggested cutting them out. (Or
> alternatively, if this weakens the point by so much it’s not worth making, to
> cut out the paragraphs that rely on it.)
> 
> My underlying concern here is that someone might take hope from this section
> and try to push their luck by putting keys into the SYN option with a length
> near the lower edge of what’s OK for security, in hopes that by the time it’s
> a real problem they’ll get an extension on the option space, rather than
> wrestling with the likely-harder problem of sending the keys in the payload.
> 
> But in practice, the option space in SYN is likely to be even less than what’s
> pointed out in this draft, because if you leave window-scale, timestamps, and
> sack-permitted out of your SYN, you’re likely to lose more on performance than
> any gains you might have made by getting a key into the SYN.
>
> In my experience, this is exactly the kind of subtle early misunderstanding
> that can lead a team to spend 6+ months developing something, then abort the
> project once they discover it cannot be made both performant enough and secure
> enough under the constraints of an early design decision.
> 
> Therefore, I would prefer this doc not to present a rosier-than-reality
> picture of the likelihood that a future development will make large SYN
> options available.

While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.

Michael
 
> To take that a little further, I’d almost rather see an explicit warning that
> provides clear support for a claim like “You cannot fit a cryptographically
> secure key into the SYN option unless and until further standards work makes
> it possible to have more space there. Don’t try, you’ll regret it.”
> 
> It’s kind of a minor point to get this much discussion, but that’s a more
> complete explanation of my objection.

---

From: David Mazieres <[email-masked]>
Date: Sun, 05 Feb 2017 05:26:42 -0800

"Scharf, Michael (Nokia - DE)" <[email-masked]> writes:

> While TCPM discusses large SYN options (for a long time already), all
> known solutions have downsides. I do not believe that a non-TCPM
> document should speculate on the feasibility solutions.

Michael, what do you think of the new proposed wording?

   Various proposals exist to increase the maximum space for options in
   the TCP header.  Though these proposals are highly experimental--
   particularly those that apply to SYN segments--TCP-layer encryption
   could significantly benefit from the availability of increased SYN
   option space.  In particular, if future TEPs can perform key
   agreement by embedding public keys or Diffie-Hellman parameters
   within suboption data, it will simplify protocols and reduce the
   number of round trips required for connection setup.  With large
   options, the 32-byte limit on length bytes could prove insufficient.
   This draft intentionally aborts TCP-ENO if a length byte is followed
   by an octet in the range 0x00-0x9f.  Any document updating TCP's
   option size limit can also define the format of larger suboptions by
   updating this draft to assign meaning to such currently undefined
   byte sequences.

Our goal is not to second-guess TCPM, but rather to provide TCPM with a
data point that they have a "customer" for large SYN options in the
unlikely event that some proposal is ever deemed realistic.  I could
make the wording even stronger, as in:

   These proposals are highly experimental--with those that apply to SYN
   segments particularly unlikely to be adopted any time soon--but
   TCP-layer encryption could significantly benefit from the
   availability of increased SYN option space.

But that could be seen as second-guessing TCPM in the other
direction--telling TCPM we *don't* expect them to standardize large SYN
options anytime soon.  (Of course, it's true that I don't expect them to
do that, but it might not be my place to say so in an RFC unless you
sign off on the language...)

As always, concrete suggestions on wording are appreciated.

Thanks,
David

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Feb 2017 08:24:51 -0800

>> report, or Request-for-Proposal, nor should a vendor claim compliance with an

FWIW, Internet Drafts are cited when it is appropriate to refer
non-normatively to a concept.

Additionally, RFC20236 was published when Internet Drafts actually
expired; that's a fantasy these days, as they are archived by the ISOC.

>>    complete and understandable document with or without the reference to
That would be exactly the exception that does apply here.  If you want
to talk about using extended option space, then it's better to cite a
known discussion thereof and provide a summary than to speculate about
it or give the impression that it is not an investigated topic.
...
> While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.

Agreed, but the point is that this doc probably SHOULD state that all
known solutions have deployment difficulties. An option (such as this)
that has SYN space limitations and does not address this issue is (IMO)
giving a misleading impression about its own limitations.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Feb 2017 08:34:33 -0800

FWIW:

>    the TCP header.  Though these proposals are highly experimental--
The non-SYN extension is currently a WG document and intended for
standards-track.
>    particularly those that apply to SYN segments
The SYN extension proposals all have significant known issues and are
both highly experimental and difficult to deploy.

> --TCP-layer encryption
>    option space.
It might be useful to differentiate between the potential use of non-SYN
vs. SYN space.

You should be more explicit that "Although this protocol could benefit
from extended SYN space, e.g., to support in-band key coordination,
future TEPs should expect to use only the currently available space."

IMO, the following is speculative and not useful:

>   In particular, if future TEPs can perform key
>    by an octet in the range 0x00-0x9f.
The following appears to direct TCPM docs to update this doc, which is
not appropriate. If there is a SYN extension, it is much more likely to
be a stand-alone doc to update RFC793 and other docs would individually
update protocols that might benefit from that space.

>   Any document updating TCP's

...
>    availability of increased SYN option space.
Actually, the above is much more useful (IMO), but most of the rest of
the paragraph can be omitted.

Joe

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 7 Feb 2017 06:53:35 +0000

I'd agree to Joe's proposal "Although this protocol could benefit from extended SYN space, e.g., to support in-band key coordination, future TEPs should expect to use only the currently available space."

Michael (chair hat off)

________________________________________
From: Joe Touch <[email-masked]>
Sent: Monday, February 6, 2017 17:34
To: David Mazieres expires 2017-05-06 PDT; Scharf, Michael (Nokia - DE); Holland, Jake; [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno

FWIW:

...

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 14 Feb 2017 23:06:25 +0000

+1 with WG chair hat on - I think Joe's text sets the right expectation.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Scharf, Michael
> (Nokia - DE)
> Sent: Tuesday, February 07, 2017 1:54 AM
> To: Joe Touch; David Mazieres expires 2017-05-06 PDT; Holland, Jake;
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno
> 
> I'd agree to Joe's proposal "Although this protocol could benefit from extended
> SYN space, e.g., to support in-band key coordination, future TEPs should expect
> to use only the currently available space."
> 
> Michael (chair hat off)
> 
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc