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

From: "Black, David" <[email-masked]>
Date: Wed, 21 Aug 2013 16:16:39 -0400

Tom,

Thank you for this review.

I would prefer not to repeat general advice applicable to all uses of
IPsec in this draft.  That applies to the exposure of AES GCM to nonce reuse
and means of preventing that reuse (e.g., use of IKE) which are covered in the
Security Considerations section of RFC 4106; if that advice is inadequate,
I'd suggest a revision of RFC 4106 rather than adding advice to this draft.

* OTOH, it would make sense to add a sentence to point out that all of the
referenced security RFCs and the security considerations in all of the
other referenced RFCs are applicable if that seems useful.

As explained in Section 2.2, the hardware implementation considerations
originally used to select AES-CTR as a "SHOULD implement" transform now
favor AES-GCM.  Based on those considerations, AES-GCM is a significantly
better choice due to its hardware-friendly hash, so retaining the "SHOULD"
for AES-CTR doesn't make sense.

The comments on 3DES seems off the mark to me.  The IETF approach to
security, as I've understood it, is to require implementation of
sufficient security mechanisms so that they will be available if needed.  
Since the protocols to which this draft's requirements apply will operate
at high data rates in some environments (e.g., see discussion in Section 2.2),
3DES is no longer appropriate as the single "MUST implement" confidentiality
transform.  Further, the comparison to AES-GCM seems misplaced, as AES-CBC
is the new "MUST implement" transform, not AES-GCM.

* I'll add some advice about matching strengths of symmetric and asymmetric
keys with a pointer to NIST SP 800-57, as there are key length requirements
in this draft.

* ESP sequence number cycling is prohibited (MUST rekey before that happens)
by RFC 2404 and RFC 4303, so I don't see any point in discussing its 
consequences.  OTOH, I think it would be good to call attention to this
requirement to rekey before the ESP sequence number rolls over and point out
that extended sequence numbers greatly reduce the frequency at which that may
be necessary (probably in Section 2 of this draft).

The three paragraphs noted by '*' above indicate the three changes that I'd
propose to make in response to this review - is that reasonable?

With this draft in IESG Evaluation for next week's telechat (August 29),
I would plan to defer these changes until after the telechat.

Thanks,
--David

> -----Original Message-----
> From: Tom Yu [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2013 2:57 PM
> To: [email-masked]; [email-masked]; draft-ietf-storm-ipsec-ips-
> [email-masked]
> Subject: secdir review of draft-ietf-storm-ipsec-ips-update-03
> 
> 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?

---

From: Tom Yu <[email-masked]>
Date: Thu, 22 Aug 2013 19:45:22 -0400

> I'd suggest a revision of RFC 4106 rather than adding advice to this draft.

I would tend to agree about not repeating general advice applicable to
all uses of IPsec.  This document does replace AES-CTR with AES-GCM,
and the consequences of nonce reuse with these modes are qualitatively
different and possibly bear mentioning.

I think the text in RFC 4106 about the risks of nonce reuse should be
more specific about the consequences.  (RFC 4106 says "destroys the
security guarantees of AES-GCM mode" instead of "reveals the
authentication subkey".)  Compared to most other cipher modes, nonce
reuse in GCM has surprisingly catastrophic consequences.  Perhaps RFC
4106 could use revision, but that would not benefit readers of this
document until that revision was published.

> other referenced RFCs are applicable if that seems useful.

That would be useful, as would additional text calling out the
security considerations sections for RFCs related to algorithms whose
requirement levels this document changes, e.g., AES-CTR (RFC 3686),
AES-GCM (RFC 4106), and AES-GMAC (RFC 4543).

Because this document replaces one "SHOULD" requirement level AES
counter mode with another, I think it would also be useful to contrast
the considerably different consequences of nonce reuse in AES-CTR
(confidentiality loss limited to the blocks with colliding counter
values) compared to AES-GCM (additionally reveals the authentication
subkey).

The relative severity of these vulnerabilities might be debatable in
the context of a block storage protocol.  If you believe the security
impacts to block storage protocols caused by these nonce reuse issues
are negligibly different, the document might not need to make that
comparison.  (Although I would be interested in hearing the reasoning
behind such a belief.)

> for AES-CTR doesn't make sense.

Am I correct in concluding from the above that there were no security
issues leading to the changes of requirement levels for AES-CTR
("SHOULD" to "MAY"), and that you base the advice on hardware
implementation considerations?  If so, this text in Section 2.2 seems
potentially misleading:

   "This document changes both [3DES-CBC and AES-CTR] of these
   requirements based on cryptographic developments since the
   publication of RFC 3723."

unless "cryptographic developments" refers to both the block size
vulnerability of 3DES and the standardization of AES-GCM.  In that
case, I would suggest adding text to the "AES Counter mode" paragraph
of Section 2.2 indicating that the new preference of AES-GCM above
AES-CTR is because of hardware implementation considerations and not
cryptographic weakness.

> is the new "MUST implement" transform, not AES-GCM.

I agree that 3DES is no longer appropriate as the "MUST implement"
confidentiality transform.  I think that because 3DES remains
available as an optional algorithm, it could be valuable to provide
advice about when its use might be an acceptable risk (low data rate
sessions?).

> I would plan to defer these changes until after the telechat.

Your proposed changes seem reasonable.

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 Aug 2013 20:46:07 -0400

Tom,

I think we should agree to disagree on one point, and I'm prepared to make
text changes to address the others (in particular, you are clearly right
that the hardware implementation rationale for AES GCM instead of AES CTR
should be made clearer).  As previously noted, I plan to hold off on
submitting a revised draft until after the IESG telechat on August 29.

Again, thank you for the review and your comments.

-- Point of disagreement

I firmly believe that filing technical errata against RFC 4106 (AES GCM)
is the appropriate vehicle for the concerns about AES GCM nonce reuse,
including the comparison of security properties to AES CTR.  Such errata will
get the requisite level of review from security experts and cryptographers
who may not look at this draft, and will result in them being seen by
anyone who implements GCM, in contrast to this draft which may not even
be consulted by all IPsec implementers.

I propose leaving this to the Security ADs to determine at this juncture, as
I believe I understand your security concerns, (with which I do not disagree).

Rather, I am asserting that this draft is the wrong vehicle for them, because
(IMHO) they should be directly associated with the AES GCM RFC, and filing
technical errata against that RFC is the appropriate means to accomplish that.

-- Points of agreement

(1) Applicability of security considerations text in other RFCs

> AES-GCM (RFC 4106), and AES-GMAC (RFC 4543).

Ok, I can do that.

(2) Rationale for replacement of AES CTR with AES GCM

> vulnerability of 3DES and the standardization of AES-GCM.

That is the situation.

> In that

Good suggestion - I'll plan on doing that.

(3) Use of 3DES

> advice about when its use might be an acceptable risk (low data rate

Ok, I can write a sentence to the effect that when the data rate is low
enough that 3DES's rekeying frequency is not a concern, 3DES is a
reasonable algorithm to use.

(4) Key strength matching

> > keys with a pointer to NIST SP 800-57, as there are key length requirements

(5) ESP sequence numbers and rekeying

As previously noted, I'll do the following:

> > that extended sequence numbers greatly reduce the frequency at which that
> > may be necessary (probably in Section 2 of this draft).

Thanks,
--David

> Sent: Thursday, August 22, 2013 7:45 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; draft-ietf-storm-ipsec-ips-
> Subject: Re: secdir review of draft-ietf-storm-ipsec-ips-update-03
>

---

From: Tom Yu <[email-masked]>
Date: Thu, 22 Aug 2013 23:39:13 -0400

> technical errata against that RFC is the appropriate means to accomplish that.

Hi David,

I think that is a reasonable approach (although I do have some slight
disagreement with it), and I'm willing to defer to the Security ADs
about which approach is the most appropriate in this situation.

>> > may be necessary (probably in Section 2 of this draft).

Yes, I believe we are in agreement on the other points you describe
above.  Thank you for your prompt and thoughtful reply.