Re: [tcpinc] Review of draft-ietf-tcpinc-api-03

[Kyle Rose <[e-mail]>]

On Sat, Sep 30, 2017 at 12:48 AM, David Mazieres
<[e-mail]> wrote:
>> * I don't understand the rationale behind the last bullet in the
>> tcpcrypt section. Is the presumption that an application will
>> authenticate the first connection and then resume without
>> authentication? If so, then it's more than prudent: it MUST purge that
>> session from the cache.
>
> I just got rid of that point.  The idea was that if you somehow
> connected to a man in the middle and think you can avoid it by trying
> again, then you want to flush the cache.  But in practice if you have an
> interception proxy or something that is implementing tcpcrypt, then
> probably trying again isn't going to work.  The point is kind of arcane
> anyway, so no need to try to make it.

SGTM.

> So some BSD have such a sysctl.  For example:
>
>         http://man.openbsd.org/sysctl
>
> I was just trying to be as compatible as possible with that mechanism
> since it exists already.

Sounds good. This was just an informational clarification for me
because for some reason I couldn't find anything about it.

> I didn't understand this comment at the time.  Now I think you just mean
> I used TCP_ENO_LOCAL_NAME which is not a thing.  I've already submitted
> too many drafts tonight, but I fixed this in the git repo, so once we
> settle on everything else I need to fix, the final draft can have this
> fix.

Yes, that's what I meant. I'm not sure why I put it precisely the way I did.

>> * Can you describe for me an attack that would be possible using an
>> authenticator taken out of context? I'm assuming that both ends of the
>> connection with the unique session ID already have the cookie, and
>> that the authenticator would be useless on any other tcpinc connection
>> because of the uniqueness property. Is the issue that the session ID
>> used in the PRF could collide with an entirely distinct (i.e.,
>> non-tcpinc) use? Something similar applies to 5.2, as well.
>
> Yes, say you have a peer-to-peer system where nodes authenticate
> themselves by signing the session ID but not the role.  Then you can
> connect to a server and convince it that it is talking to itself by just
> echoing back the signed message.

Right. This also looks good.

>> * It might be worth pointing out that, in unilateral authentication,
>> the side that does not validate an authenticator relies on the peer
>> ending the connection if validation fails to prevent man-in-the-middle
>> attacks.
>
> I don't really understand this comment.  In unilateral authentication
> one side does not care about whom it is talking to, so why would it need
> to rely on the unknown other side for anything?

What I mean is maybe best illustrated by example. Server-only auth in
TLS provides protection against MitM attacks because the client
authenticates the output of a derivation from some secret that cannot
be engineered by an adversary to be the same on two connections:
modulo a compromise of the signing key or collusion by one of the two
endpoints, this is a proof that with overwhelming probability only the
server and the client know the symmetric key material protecting the
connection. But the server's protection in this case relies on the
client taking action: that is, authenticating the server's certificate
and hanging up if the cert check fails. If not, the MitM can pretend
to be the server to the client, and the server would never know. This
is not true with mutual authentication based on a channel binding, as
either endpoint would be able to distinguish a legit connection from a
broken one.

Kyle