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

[Eric Rescorla <[e-mail]>]

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. I plan to make some attempt to follow via audio
and Jabber but I don't know if I'll actually be able to make that
work, both for technical and logistical reasons (i.e., I'm at a
conference at the same time and I don't know how well the network
will work or if I'll have to do something else).


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


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



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

So, no, this does not address my concern. I think the world would
be far simpler if you simply required both sides to generate MACs.
(and certainly I can't imagine why you would *require* implementations
to allow neither side to do so). 

Perhaps you could restate your rationale for this?

-Ekr





_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm