Re: [tcpm] Comments on TCP-AO Draft

At Tue, 18 Nov 2008 15:34:10 -0600,
LANGE Andrew wrote:
> (position 2 - "don't include") Including this information is BAD
> because it can expose information about the security parameters.  It
> doesn't aid in debugging of configuration because operators still
> have to call each other in order to read off and verify keys.
> 
> Elaboration: Originally I was also of this position.  However, I
> came around when I considered the operational impacts.  We need to
> make this protocol as operator-friendly as possible.  That is why it
> is being created to begin with.  We shouldn't lose sight of
> deployability and maintainability in the quest to shorten an option
> by a byte (especially when we gain 3 from MD5 to start with.)  Also,
> we have had many strong security experts, such as ekr and Brian Weis
> (gentlemen, correct me if I'm misquoting you) say that putting
> algorithm ID in the packet does very little to make it harder for a
> bad guy to attack the session.  To be specific, the attacker has to
> be a man-in-the-middle to see the ALG ID to start with (whereas
> blind attacks are probably more likely).  In addition, the search
> space would be extended by a single bit.  We're already using very
> strong algorithms, and have the agility to add more.  Search is
> already infeasible with known state, and if that changes the right
> approach, and the secure approach is to introduce another algorithm.

I don't think there's any real security value to hiding the identity
of the MAC algorithm. I leave the question of whether shaving the
byte is worth doing to the TCP experts.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm