Hello tcpinc members, I’m new to the group, and joined at Kyle and David’s invitation to give a review of this draft before the WGLC expires: "TCP-ENO: Encryption Negotiation Option" https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
The doc mostly looks pretty good to me. I couldn’t find anything that would make it impossible to transport data and opportunistically encrypt it with ENO where available, nor anything inherently dangerous for an app that doesn’t use any ENO-specific API extensions, but which is running on a network stack that silently turns on ENO underneath. A few suggestions that I think might improve the doc: 1. There should be a MUST for an API that an application can use to discover whether a connection ended up encrypted, unless it’s there and I missed it. I couldn’t find one in the doc, but it seems a likely vital point for anything that satisfies the application-aware definition. 2. I’d like to see a section that lists a use case or 2 that can be solved by knowing the remote host’s a-bit (or with the mandatory application-aware mode), and how the a-bit solves them. I assume I’m missing something obvious, but I haven’t been able to come up with a use case that does anything useful with the remote a-bit. (An example guess: is the whole point so that you can avoid sending sensitive data if the remote app itself hasn’t done anything to become secure? And if so, is there some reason the application-layer protocol shouldn’t be in charge of determining that?) 3. All 3 instances of “manual(ly)” in the doc seem better if changed to “explicit(ly)” (sections 4.2 and 7.4) 4. In section 7.1, the hopes of increasing TCP’s SYN option space seem exaggerated. EDO does not apply to SYN, and of the other 2 cited drafts, one is expired over a year ago and the other looks, I guess I’d call it "tricky", in addition to being experimental. It might be better to remove the second and third paragraphs of section 7.1, or at least reduce to just the one example of a live and applicable draft (and maybe noting that it’s experimental). I hope that helps. - Jake _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
