[secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03

[Tom Yu <[e-mail]>]

I have reviewed 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 primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I believe this document is ready with minor issues.

The Security Considerations section in its entirety is

    "This entire document is about security."

Although the above statement is true, I think it would also be
beneficial to provide additional information in the Security
Considerations to help implementers and administrators make informed
risk assessments.  This could include describing the consequences of
failing to adopt the recommendations of this document.  I have
outlined below some possible risk tradeoffs to consider describing in
the document.

AES in GCM mode is vulnerable to catastrophic forgery attacks if a
nonce is ever repeated with a given key.  Hopefully this won't be a
practical issue, but implementation bugs involving random number
generators are not uncommon.  Forgery in a content protection context
is probably also less of a concern than forgery in an authentication
context.

What concerns with AES-CTR motivate its demotion?  I do seem to recall
that (contrary to best practice) confidentiality can be done
separately from integrity in IPsec.  Is this composition done in a way
that has vulnerabilities?  I'm not very familiar with IPsec and am not
remembering the details at the moment.

If there is sufficiently low traffic, is it likely that a site
constrained by legacy or resource issues could use 3DES (with its
64-bit block size) at an acceptable risk level?  (possibly with
frequent rekeying)  Ciphertext collision isn't as catastrophic with
CBC mode ciphers as nonce collision is for AES-GCM.  McGrew's paper
about collision attacks includes equations that estimate data leakage.

It could be useful to include advice about matching symmetric key
lengths with public key strengths.  See NIST SP 800-57 Part 1.

What are the consequences of sequence number cycling in ESP?