On 8/1/2014 12:41 PM, Nico Williams wrote:
On Fri, Aug 1, 2014 at 8:56 AM, Rene Struik <[email protected]> wrote:
This seems to make lots of sense: specifying the scope of which data is to
be encrypted and which is to be encrypted and authenticated with a specific
key and AEAD scheme should only occupy a few paragraphs and can be specified
almost independently from schemes as to how to arrive at the shared key. So,
time is best spent being creative on the latter now.
Well, obviously the entire ordered octet data stream (wither PSH?
URG?) needs protection,
Yes.
as does FIN handshaking
Why? Again, if this is to protect confidentiality, the control plane of
TCP isn't relevant.
and RST.
We've already discussed the limitations of this; it can be done during
an active connection, but needs to be 'weakened' for inactive ones or
TCP state can't be cleaned up (or we need to make TCP persistence the
default).
Port
numbers, for example, are of relatively little interest to protect (if
no peer authentication is afforded).
We can't hide the client source ports for NAT traversal.
We can't hide the server ports or we'll interfere reverse-NAT traversals.
I.e., some parts of the connection are open to the world - who we're
talking to and on what ports.
(note - this doesn't address what we protect from tampering, but
tampering doesn't seem to be the key focus).
> TCP options are of interest,
mostly in so far as protecting them may (or may not) be necessary to
protect the data stream.
"protect" from what? Again, if this is all focused on anti-tracking,
options aren't relevant.
Joe
Nico
--
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
