Cryptographically Generated Addresses (CGA)
draft-ietf-send-cga-06

[Ballot comment]
>    SubjectPublicKeyInfo data structure. Future versions of this
>    specification may add new fields to the end of the CGA Parameters and
>    the verifier SHOULD ignore any unrecognized data that follows the
>    encoded public key.

I don't understand what this is trying to say. This document defines
what gets compared, used, etc. No reading of this spec should be taken
to mean that "extra stuff after the end of the defined fields" should
somehow be used as part of the SEND computations. Thus, the above
would be a MUST (rather than a SHOULD), but I'd really like to
understand why this needs mentioning at all?

What problem/concern is the above trying to warn about?

[Ballot comment]
The following text is fundamentally good:

Finally, some cautionary notes should be made about using CGA-based
  authentication for other purposes than SEND. First, the other
  protocols should include type tags and the sender address in all
  signed messages in the same way as SEND does. Because of the
  possibility of related-protocol attacks, it is advisable to use the
  public key only for signing and not for encryption. Second, CGA-based
  authentication is particularly suitable for securing neighbor
  discovery [RFC2461] and duplicate address detection [RFC2462] because
  these are network-layer signaling protocols where IPv6 addresses are
  natural endpoint identifiers. In any protocol that aims to protect
  higher-layer data, CGA-based authentication alone is not sufficient
  and there must also be a secure mechanism for mapping higher-layer
  identifiers, such as DNS names, to IP addresses.


In that it discourages folks from using CGA-based authentication alone.  I'd
suggest strengthing it even further, though.  Would something like the
following text be acceptable?

CGA-based authentication should not be considered for purposes other
than SEND and closely related mechanisms.  CGA-based authentication
is particularly suitable for securing neighbor discovery [RFC2461] and
duplicate address detection [RFC2462] because these are network-layer
signaling protocols where IPv6 addresses are natural endpoint identifiers.
In any protocol that aims to protect higher-layer data, CGA-based authentication
alone is not sufficient as there must also be a secure mechanism for
mapping higher-layer identifiers, such as DNS names, to IP addresses.
Further, using CGA-based authentication for other purposes may
weaken the effectiveness of this mechanism for SEND, because of the
possibility of related-protocol attacks.  If another mechanism needs
to re-use CGA-based authentication, it must take care that it
include type tags and the sender address in all signed messages in the
same way as SEND does and  it must use the public key only for signing and
not for encryption.

[Ballot discuss]
The first paragraph of section 3 says:
  >
  >  ... For SEND, the public
  > key SHOULD be an RSA encryption key with the object identifier
  > rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public
  > key field SHOULD be formatted as an ASN.1 data structure of the type
  > RSAEncryptionKey defined in [PKCS.1.2002]. ...
  >
  PKCS #1 v2.1 (14 June 2002) does not specify a type of RSAEncryptionKey.
  I suspect that a type of RSAPublicKey is intended.  This type and
  the associated object identifier can be found in RFC 3279 (as well as
  in PKCS #1 v2.1).  The community will be able to easily locate RFC 3279.
  Please refer to section 2.3.1 of RFC 3279.

  Further, the use of SHOULD bothers me.  The use of RSA can be SHOULD, but
  the format of fields when RSA is selected ought to be a MUST.  I suggest:
 
    SEND SHOULD use an RSA public/private key pair.  When RSA
    is used, the algorithm identifier must be rsaEncryption, which
    is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted
    using RSAPublicKey type as specified in section 2.3.1 of RFC 3279.

  In the 1st full paragraph on page 9, Section 4 says:
  >
  > ... The quality of the random number generator does not affect the
  > strength of the binding between the address and the public key. ...
  >
  This kind of statement will encourage implementors to use a constant,
  which is a problem.  A SHA-1 hash of the time of day would be okay.

  Section 7.3 ought to reference RFC 1750.

  The security considerations ought to say something about the lifetime
  of the public/private key pair.  The one brief statement in section 7.3
  is not sufficient for an implementor to know how often the key pair
  needs to be changed.

[Ballot discuss]
The first paragraph of section 3 says:
  >
  >  ... For SEND, the public
  > key SHOULD be an RSA encryption key with the object identifier
  > rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public
  > key field SHOULD be formatted as an ASN.1 data structure of the type
  > RSAEncryptionKey defined in [PKCS.1.2002]. ...
  >
  PKCS #1 v2.1 (14 June 2002) does not specify a type of RSAEncryptionKey.
  I suspect that a type of RSAPublicKey is intended.  This type and
  the associated object identifier can be found in RFC 3279 (as well as
  in PKCS #1 v2.1.  The community will be able to locate RFC 3279 much
  more easily.  Please refer to section 2.3.1 of RFC 3279.

  Further, the use of SHOULD bothers me.  The use of RSA can be SHOULD, but
  the format of fields when RSA is selected ought to be a MUST.  I suggest:
 
    SEND SHOULD use an RSA public/private key pair.  When RSA
    is used, the algorithm identifier must be rsaEncryption, which
    is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted
    using RSAPublicKey type as specified in section 2.3.1 of RFC 3279.

  In the 1st full paragraph on page 9, Section 4 says:
  >
  > ... The quality of the random number generator does not affect the
  > strength of the binding between the address and the public key. ...
  >
  This kind of statement will encourage implementors to use a constant,
  which is a problem.  A SHA-1 hash of the time of day would be okay.

  Section 7.3 ought to reference RFC 1750.

  The security considerations ought to say something about the lifetime
  of the public/private key pair.  The one brief statement in section 7.3
  is not sufficient for an implementor to know how often the key pair
  needs to be changed.