On 07/29/2014 05:13 PM, Bodo Moeller wrote: > I think that *optional* protection against further attacks is desirable > (allowing applications to request further protection, which will > potentially be detrimental to interoperability -- but won't hinder > widespread deployment of default encryption, because it only applies when > applications opt in).
It sounds like several people have made this suggestion (or similar ones).
As a clarification, do you think that one side should be able to
unilaterally opt in to this protection, or should both sides need to
explicitly negotiate it? at what granularity? are they opting into
protection of their own traffic, or of their peer's traffic?
more concretely: consider a tcpinc-aware web server and a non-tcpinc
aware web browser, both running on hosts that support tcpinc (whatever
that ends up being).
the web server says to its tcpinc API "i want protection of parts X and
Y of the TCP header -- do not accept packets where those parts appear to
be tampered with" (what else could it say?)
But of course the browser says nothing, as it is not tcpinc-aware.
The browser's machine's networking stack goes ahead and negotiates a
tcpinc connection to the server - does it know what parts of the header
it needs to MAC into whatever protected operation, without being told
what to do by the browser itself? should it also reject packets from
the server where X and Y are either unprotected or fail validation?
saying "optional protection" implies a bunch of complexity that bears on
interoperability and negotiation issues; those really need to be nailed
down to be evaluated properly.
To be clear, I'm not opposed to "optional protection" of parts of the
TCP header in principle, but i think we need to be much more explicit
about what kinds of tradeoffs are worth making here.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
