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

[David Mazieres <[e-mail]>]

Kyle Rose <[e-mail]> writes:

> (Keepalive before list timeout.)
>
> This is a review of draft-ietf-tcpinc-api-03. Chair hat off.

Okay, thanks for the review.  I stupidly somehow thought your email
ended halfway through and uploaded a draft addressing half your
comments.  That's now been fixed, but you will want to diff version 5
against version 3.  The latest is here:

        https://datatracker.ietf.org/doc/draft-ietf-tcpinc-api/

Most of your points were straight-forward and should now be addressed.
I'll just comment on ones that might be marginally more complicated.

> * 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.

> * What is "baddynamic"? A Google search was unrevealing. Does this
> need a reference?

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.

> 5.1:
>
> * TCP_ENO_LOCAL_NAME conflicts with SELF_NAME.

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.

> * 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.

> * 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?

Thanks,
David