"Holland, Jake" <jholl...@akamai.com> writes:
> A few suggestions that I think might improve the doc:
Thanks for going through the document.
> 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.
This is a good catch. There used to be a requirement that
implementations MUST provide an API for getting the session ID that MUST
give an error if the connection is not TEP-encrypted, but I think this
got moved into the informational API draft. The natural place to
mention this would be section 9 (security considerations).
> 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.
This is mentioned in the second paragraph of section 9 ("applications
MAY use the application-aware bit to negotiate the inclusion of session
IDs in authentication.") However, if you think the point is worth
making more explicitly, maybe a place to do this would be in a new
subsection of 7 (design rationale).
> (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?)
Actually the point is to enable incremental steps towards security
legacy protocols. Let's say that today some protocol X sends plaintext
authentication cookie. With TCP-ENO, at least the cookie isn't
available to a passive eavesdropper, but it's still not very secure. So
you use the application-aware bit to signal that instead of a cookie,
you will send a MAC of the session ID under the cookie, thereby keeping
the cookie secret. Then in a few years, once everyone is always setting
the application-aware bit, you disable the old authentication behavior
or issue some warning, or provide some sort of application-aware pinning
mechanism to prevent rollback attacks.
The application-aware bit is what allows this incremental improvement in
security to happen without a flag day, because having a flag day would
be a show stopper for a lot of legacy protocols.
Does that make sense? And does it merit its own section 7.6 or
something?
> 3. All 3 instances of “manual(ly)” in the doc seem better if changed
> to “explicit(ly)” (sections 4.2 and 7.4)
That's an easy change.
> 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 agree that large SYN options seem like kind of a long shot, but if
they ever happen, ENO stands to benefit. So part of the point here is
to make it unambiguous that ENO would benefit from large SYN options and
is ready to take advantage of them, because A) it's true, and B) it
could potentially strengthen the case for current or future large option
designs.
Is there harm in doing this? E.g., is it bad practice to cite internet
drafts (non-normatively, of course) in an RFC?
David
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
