Yes, I definitely think it's feasible. It hasn't been my intention to
suggest that channel binding is infeasible or that building support for
it into the protocol would be a bad idea. I've really just been trying
to figure out what the implications might be (if any) for a certain type
of middleware.
It's still my opinion that binding TCP header integrity/authentication
to either data stream or application layer security would most likely
prevent this type of middleware from using the protocol, and so I would
prefer to see the protocol allow but not require such integration.
For example, hooks that allow tcp-ao keys to be used by tcpinc would
provide the capability to prevent an unauthorized MITM while at the same
time allowing for an authorized transport layer MITM to be used. I think
that such an approach would meet your proposed channel binding support
goal with sacrificing the flexibility the system I'm concerned about
would require.
--Brandon
On 08/19/2014 07:39 PM, Nico Williams wrote:
On Tue, Aug 19, 2014 at 04:20:44PM -0400, Brandon Williams wrote:
On 08/19/2014 12:07 PM, Nico Williams wrote:
[...]
If the octet stream has nested framing (basically a length an
authentication tag) then the properties you want can be had and you
can still have CB and the proxy needn't be trusted.
Agreed, provided that the authentication on the nested framing
doesn't extend to the TCP headers themselves, as in some of the
proposals.
Right. This is really like TLS-over-TCP, really, at least as to the
"record layer".
It costs more overhead, but not because of CB but because what you
want + integrity protection pretty much requires extra overhead
(unless I'm missing something).
Agreed, though the extra overhead for framing shouldn't be too bad.
Right. The authentication tag you need anyways, so it's really just a
length field, which needn't be that long since it often doesn't pay to
encrypt in large chunks (for cache effect reasons, but this applies
mainly to general purpose CPUs). Two bytes should suffice; its size
could always be negotiated.
Or are you thinking of overhead from something more than just the
effort of framing the octet stream?
No, just that.
If you want encryption without integrity protection, then I'm afraid
that's a bad idea.
Agreed. That's definitely not something I would suggest.
Alright, so you agree that CB is feasible then, yes?
Nico
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
