Security review of 
A YANG Model for Transmission Control Protocol (TCP) Configuration
                draft-ietf-tcpm-yang-tcp-07

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

(This is a re-review, post -06, perhaps long overdue).

The document describes a YANG module for TCP connection attributes,
including authentication.

The TCP AO hash algorithms are described in RFC5926.  They include
a SHA-1 scheme and an AES scheme.  SHA-1, like MD5, is a broken
algorithm.  Although SHA-1 can still be used safely in the keyed
hash constructions of RFC5925, it is a security liability to
maintain it in a code base.  Similarly for MD5, and particularly the
way it is used per RFC2385.

While I realize that my recommendations amount to windmill tilting,
this is a security review, and bad algorithms in a code base are a
security issue, deriving new drafts based on flawed earlier drafts is
a generic IETF RFC problem.  It would be unfair to ask the authors of
this draft to change the TCP AO drafts, but someone should.

The document under discussion here should not support MD5, even at the
risk of failing to support legacy BGP.  That's a security opinion, not
a "we have to keep things running smoothly" opinion.

The document should also note that SHA-1 is not recommended.  The
provided example should use AES, not SHA-1.  Someone, someday, should
revise RFC5926 and get rid of SHA-1.

I do not know why there are no statistics about authentication
failures.  If a shared key falls out of synch or is subject to
injections attacks, the statistics might help detect that.

Hilarie