[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. _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
