The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-msec-ipsec-signatures-06

[Ballot discuss]
I'd like to formally request a response to last call comments from Ian
Jackson received by the IESG.  In particular, these comments
questioned whether the draft  was  using reasonable cryptographic
practice by using OAEP/PKCS1 1.5 for RSA signatures in a new protocol.
While I'd like a response to all Ian's comments  it is this concern
that motivates my request.

The following comments are based on my reading and on a review
provided by Stephen Kent.

Section 2 : The draft proposes signing the message with
RSAES-PKCS1-v1_5.  That's a encryption scheme, not a signature scheme.
There is a corresponding signature scheme, but it is not clear why
that scheme would be used in new protocols.  Section 2 seems generally
confused about the difference between encryption and signatures.

Section 2 does not appear to specify the algorithm used in sufficient
detail for implementation.  It does not specify what hashes are
required to be implemented or how the receiver finds out what hash is
used.  It seems to imply that the PKCS1 1.5 indication of hash is not
to be used because the hash will be known at the IPsec layer.  However
this mechanism will be the integrity algorithm used; isn't that
normally where the choice of hash would be communicated at the IPsec
layer?  I'm uncomfortable that the specific text to be signed is not
called out; I realize that this is implied by the ESP and AH
specifications but I would prefer for a specific reference.

Section 2 does not specify the value of the ICV in sufficient detail
to meet requirements of the ESP v3 specification.  See 2.8 in the ESP
v3 specification; comparison rules, length and processing steps need
to be specified by the integrity algorithm.

Section 2 also provides insufficient detail for the ICV to comply with
draft-ietf-ipsec-rfc2402bis.

Section 2 claims that distribution of the key and selection of key
lifetime is a local policy matter.  Seems more like a group policy to
me.


Section 3: Section 3 mixes a discussion of bandwith required and a
discussion of processing required.  The processing requirements should
be the primary focus and the discussion of bandwith should be
separated.
The following bullet in section 3 is confusing:
      o The sender has a substantial amount of processing power, whereas
        receivers are not guaranteed to have substantial processing
        power, and

The text says this algorithm is inappropriate when receivers have
similar processing power to senders.  That's not what is intended.

  The size of the RSA modulus can affect the processing required to
s/can affect/affects/
Section 4:
The spec should call out the fact that this does not work with
combined-mode ESP ciphers like aes-gcm.

Section 5:
Indicate that the private key MUST NOT be sent as part of group
download policy.


Missing: The specification should describe what key sizes are required
to implement.

[Ballot comment]
Minor nits:

The title of this draft is: "The Use of RSA Signatures within ESP and AH"

Understanding that this algorithm *may* be used for unicast, it seems that the major motivation of this draft is for use in multicast environments. Should this be better reflected in the title?

Also, first letter capitalization for words in the title does not seem to be consistent.

[Ballot comment]
DISCUSS only until shepherd acknowledges these nits.
(Personally, I think the RECOMMENDED that Lucy queries is OK)

Document: draft-ietf-msec-ipsec-signatures-04.txt
Review: Lucy E. Lynch
Date: 2 mars 2005

The Use of RSA Signatures within ESP and AH
draft-ietf-msec-ipsec-signatures-04.txt

"This draft is basically ready for publication, but has nits that should
be fixed before publication."

Very readable document, with a clear statement of need:

  "Some group applications require true data origin authentication,
  where one group member cannot successfully impersonate another group
  member. The use of asymmetric digital signature algorithms, such as
  RSA, can provide true data origin authentication."

The document has some formating nits (see below)

NOTES:

one question - why is this a recommendation and not a requirement?

2.0
  "The use of an ephemeral key pair  with a lifetime of the ESP or AH SA is
  RECOMMENDED. This recommended  policy reduces the exposure of the RSA
  private key to the lifetime of the data being signed by the private key.
  Also, this obviates the need to revoke or transmit the validity period of
  the key pair."

NITS: idnits 1.60

tmp/draft-ietf-msec-ipsec-signatures-04.txt:

tmp/draft-ietf-msec-ipsec-signatures-04.txt(3): Line is too long: the
offending characters are 'an Weis'
tmp/draft-ietf-msec-ipsec-signatures-04.txt(4): Line is too long: the
offending characters are 'Systems'
tmp/draft-ietf-msec-ipsec-signatures-04.txt(5): Line is too long: the
offending characters are 'y, 2004'

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...
  * The document seems to lack an RFC 3668 Section 5, para 1 IPR
    Disclosure

  Acknowledgement.

  (Expected a match on the following text:
    "The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.")

  * The document seems to lack an RFC 3668 Section 5, para 2 IPR
Disclosure
    Acknowledgement.

  (Expected a match on the following text:
    "Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.")

  * The document seems to lack an RFC 3668 Section 5, para 3 IPR
Disclosure
    Invitation.

  (Expected a match on the following text:
    "The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.")


  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about
    Internet-Drafts being working documents -- however, there's a
paragraph with
    a matching beginning. Boilerplate error?

  (Expected a match on the following text:
    "Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
Internet-Drafts."

  ... but found this:
    "Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups. Note that other
    groups may also distribute working documents as Internet Drafts.")


  - The page length should not exceed 58 lines per page, but there was 1
    longer page, the longest (page 1) being 525 lines

  Miscellaneous warnings:

  - The "Author's Address" (or "Authors' Addresses") section title is
    misspelled.

IANA Comments:
Upon approval of this document the IANA will register the following:
An IPSec Authentication Algorithm "SIG-RSA"
An IPSEC AH Transform Identifiers "AH-RSA"
An IPSEC Security Association Attribute "Authentication Key Length" (Variable type)
These registrations will be put in the appropriate registries found at the following:

Last Call comments to be addressed by the authors:

Section 2.1.

This section, while useful, feels inane. It begins by demonstrating that the factor time does not scale predictably (factoring a 512 bit modulus consumed 8000 MYs, while factoring a 528 bit modulus took 3000 MYs). It then assumes that a conservative assumption is that it does scale. The example undercuts the advice presented later, and makes me suspicious of the advice.

There is no effort to tie the advice with the improvements garnered from Moore's law, algorithmic advance, or economic development.  A 1024-bit key may be fine to use for an entire year now, but it won't be acceptable in a few years.

Section 2.2.

It is equally important to use this scheme only when all of the potential receivers are known to have sufficient processing power to verify the signature. It is also important to use this scheme judiciously when any receiver may be battery powered. Not every device can afford to do an RSA verify even once a day.

Many comments were sent to the author and the WG Chairs.  A revised draft is needed to address the comments.  I have also asked RSA Labs to confirm that the key size recommendations are reasonable.