Brandon Williams wrote this message on Fri, Aug 15, 2014 at 10:36 -0400:
> On 08/08/2014 12:47 PM, Nico Williams wrote:
> >On Fri, Aug 08, 2014 at 12:09:37PM -0400, Brandon Williams wrote:
> >>I have concerns (expressed in an earlier post to the list) about
> >>binding the authenticators used for the data stream with
> >>authenticators used for TCP. If I've understood the earlier
> >>discussion on this thread and the content of RFC5056, you are
> >>suggesting that such bindings should be supported but not required.
> >>Is that correct?
> >
> >Well, I think the TCP security protocol should have to support channel
> >binding in that it should support outputting CB data for applications to
> >use. Use of CB should be optional, of course.
> >
> >Note that for any protocol using key agreement it's trivial to produce
> >channel bindings. We're not talking about an onerous requirement.
> >
> >There's only a relatively minor considerations, which is that the
> >implementations can't keep large public keys around, so they need to be
> >hashed as soon as possible and the hashes used for the construction of
> >CB data -- like TLS Finished messages, for example. Of course, with
> >ECDH this isn't much of a concern anyways.
> >
> >>Also, I'm curious about how you would envision this working in the
> >>case of, for example, a TCP optimization proxy where the endpoints
> >>of the TCP connections are not the same as the endpoints of the
> >>secure data stream. Do you think it's possible to design a channel
> >
> >Each end-point has to trust its proxy and the proxy has to communicate
> >the correct CB to the local end-point.
>
> Well, yes, it's clear that would be necessary. I don't see how that
> would be accomplished if the proxy doesn't have direct access to the
> data stream security context. Doesn't the CB have to be delivered on an
> encrypted data channel in order to prevent an unauthorized MITM from
> seeing and misusing it?
How can they misuse it?
If you're thinking someone MITM's the connection, well, then they'd
have to be using a trusted key to sign the CB data, and then the
failure is w/ the authentication, not w/ the CB, or are you thinking
of another misuse?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
