Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Eric,

Eric Rescorla wrote:
| At Sun, 27 Jul 2008 23:38:32 -0700,
| Joe Touch wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi, Eric (et al.),
|>
|> We'll have time to discuss these issues in detail later today at the
|> TCPM meeting. Here is some potential context for that...
|
| I'm not in Dublin.

We can continue on the list in that case...

|> Eric Rescorla wrote:
|> | $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr
|> Exp $
|> |
|> | I've reviewed the latest version of this document and while it
|> | seems to incorporate some improvements over the -00 version,
|> | I still have a number of concerns:
|> |
|> | - The document seems to assume an (unspecified) external key management
|> | mechanism. That seems less than maximally useful
|>
|> The split of this work into separate key management and TCP extension
|> documents was a prerequisite to the design team's output. The WG chairs
|> and/or ADs can speak to it more directly.
|
| That may be so, but it seems to me that it's unwise regardless.  As I
| indicated in PHL, this protocol as it stands isn't really useful in
| the absence of a key management protocol.  Since no such protocol
| appears to be on the horizon... With that in mind, I've elided the
| detailed comments below relative to that.

My understanding is that this document will not move forward without a
companion keying document. Let's assume that and press on...

|> | S 1.1.
|> | I don't see a lot of value in pre-specifying two MAC algorithms
|> | as MTI. There's no reason to believe one isn't plenty, as used
|> | in other protocols.
|>
|> The need for two required algorithms mirrors the intent of RFC4305's
|> "SHOULD+", which requires one, but suggests that two algs may be
|> required in the future. The design team suggested that requiring two
|> algorithms now would be prudent, notably so that if one were compromised
|> (either entirely, or effectively weakened due to computational
|> exploits), the other would be pre-deployed. The two could also trade
|> strength for performance, depending on which algorithms are recommended
|> by SAAG.
|
| Yes, as I've now said several times, this strikes me as massive
| overkill. If SHA-1 is ever weakened to the point where HMAC-SHA1
| is implicated, we'll have problems far, far, more serious than
| the occasional attack on TCP AO.

It's trivial to resolve this via WG feedback and SAAG input. If one is
sufficient, so be it.

|> | S 2.2.
|> | Figure 2 is kind of hard to read since the length of the kind
|> | field is 16 bits, but kinds are 8 bits, rigth?
|>
|> The length of the field is wide due to the text; that will be fixed to
|> be proportional to the bit width (8 bits, as you note).
|>
|> | S 3.
|> |                >> At least one direction (inbound/outbound) SHOULD have
|> |                a non-NONE MAC in practice, but this MUST NOT be
strictly
|> |                required by an implementation.
|> |
|> | 1. This seems like a bad idea. It's very hard to analyze the security
|> | properties of a connection when only one side is protected. To take
|> | one case that is obviously bad, if you're worried about DoS attacks
|> | and you use TCP-AO, then forging packets in either direction can
|> | bring it down. I would reverse this and require MACs in both
directions.
|> |
|> | 2. Even if we stipulate that this might be an OK idea, it's not
|> | appropriate to require implementations to support it.
|>
|> We discussed the utility of asymmetry in Philadelphia last March. The
|> point is to require implementations to allow the user to request
|> connections configured this way; we can add that connections MUST
|> default to using a real MAC in both directions by default. Does that
|> address your concern?
|
| Well, as I recall, you asserted it the value of it and I disagreed.

I asserted the value of keeping it in for potential future use.

| As I recall, the example you offered was the one-way authentication in
| TLS, which is really not that apropos, since it only applies to the
| key management protocol, not to the data, which is authenticated in
| both directions.

We discussed that in Phila. I recall that we agreed that this wasn't
exactly like TLS. However, I preferred leaving it in for future use.

| Perhaps you could restate your rationale for this?

About 10 minutes into that future ;-), we were discussing (as I recall)
channel binding and connection latching, at which point someone (?)
suggested TCP-AO could start in NULL in one direction, and escalate via
enabling a new KeyID (and thus configuration) via in-band exchange. I
recall your noting that this was a good reason for asymmetry.

We could update the doc to include that rationale...

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiN1sQACgkQE5f5cImnZrs1EwCgn+BB/umHsrKOWGDI9fJi2/zL
LBYAn3tPQq57MNV+kIZV87gT9dGEIhWq
=K5o/
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm