Subject: [secdir] Secdir review of draft-jivsov-openpgp-ecc-12

From: Brian Weis <[email-masked]>
Date: Tue, 10 Apr 2012 20:11:49 -0700

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.

This document adds support for the use of ECC as an authentication method to OpenPGP. Two public key algorithms are supported: ECDSA and ECDH. The document describes the supported ECC curves, how the public key is represented in OpenPGP, and encodings for public and private keys. For ECDH, it also specifies the KDF for creating a KEK from from ECDH shared secret and the method for key wrapping a session key that is used to protect data traffic. This seems to be standard OpenPGP practice for DH public key algorithms. A stated goal is to conform to Suite B; as far as I can tell this is achieved.

I have the following comments/questions.

Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is preferable to reference just the RFC. I suggest removing "and in [SEC1]".

Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity ("point O"), which would be better to use. This seems to be the only term in this section specific to [SEC1], so making this change should enable you to change your reference to RFC 6090 here too.

Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done?

Section 7: The use of "P" for parameters is confusing, since P was just used in Section 6 to mean "Point". It would be helpful if it were "Params" or something other name.

Section 7: It would be helpful to the reader to explain that setting ZB to "x" is using the "compact output" of the shared secret (see RFC 6090 Section 4.2).

Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader.

Section 8: This says "The key wrapping method is based on [RFC3394]". I hope is it actually "conforming to [RFC3394]", which would be a clearer statement. Is that so? If not, why?

Section 8: This section gives an example of encoding a 32-octet ASE-256 session key into 40 octets, which seems to be the input to the key wrap. My understanding of the AES key wrap defined in RFC 3394 is that the key input should be just 32 octets, where it is prepended with an 8 octet IV. This doesn't match your example though. Can this be made to match the inputs in the RFC? For example, see the example in Section 4.6 of RFC 3394. (This would also remove the need for padding an AES-256 key, and reduce the padding for the two smaller sizes.)

Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section 9?

Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information.

Thanks,
Brian

---

From: Brian Weis <[email-masked]>
Date: Wed, 11 Apr 2012 14:04:55 -0700

Hi Andrey,

On Apr 11, 2012, at 12:26 PM, Andrey Jivsov wrote:

> Thank you for your comments, Brian. I integrated some of them into -13, posted http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/
> 
> On 04/10/2012 08:11 PM, Brian Weis wrote:
>> 
> It seems to me that SEC1 provides the most succinct description of the algorithm among all the publicly available sources. RFC 6090 refers to another external document, which is written in a form of a survey of crypto methods, which the reader will need to process to get the relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the ECDSA exactly.
> 
>> 
> The main reason for SEC1 reference is to define the format 04 || x || y. RFC 6090 is missing any method to serialize an ECC point (no on-the-wire format).  
> 
>> 
> Right beneath of the table there was a sentence that addresses this in -12, which I modified to read:
> 
> "Note that the point O shall not appear in a public keys, including ephemeral public keys used with ECDH, defined in section 8."
> 

I believe this sentence is saying that it will never be included in a protocol payload, which makes sense to me. So I'm wondering if there is actually any value for mentioning the value/description of point O it in your I-D? It's a bit confusing to include it if it isn't actually used.

> Done. P-->Params
> Done. Added the reference at the bottom.
> 
>> 
> This is exactly what the qualifiers intended for, but they are only needed for persons validating this draft to be compatible with SP800-56A. I wonder if the reference here adds any value for the rest of readers?

Since your stated goal is to meet Suite B requirements, and complying with SP800-56A is part of those requirements, I imagine there will be people wanting to validate this after it becomes an RFC. It would seem to be in your best interest to make it clear to them. :-) People who don't care about the reference will just ignore it.
 
> Done. It is precisely "conforming"
> 
>> 
> There are two reasons for the current method:
> 
> * In OpenPGP the message encryption algorithm (symmetric algorithm of a session key) is encrypted to a public key of a recipient. In RFC 4880 it's done so that the session key is 1_byte_symm_alg || key || checksum. One can argue on the benefit of a checksum, but the ID bumps the payload size to the next 8 bytes, which gives space to accomodate the checksum and PKCS#5 padding markers for free

Ok, so what you're saying is that you really need the 40 bytes as input to the key wrap function. You should have some text clarifying exactly how you're using the AES Key wrap though. For example: "The inputs to the AES Key wrap are as follows: The Plaintext is taken as the 40 bytes described above, the KEK is the value derived from the KDF, and the Default Initial Value is used."

> * One cannot we cannot say which key size was used to encrypt the message by looking at RSA or ElGamal encrypted session key. AESWRAP leaks this information when it is tightly encapsulated the session key (this may leak how sensitive a protected document is). There is a description in the same section 8 on how to avoid this leak by padding the payload of AESWRAP to make it always look like an AES-256 session key.

> I intended to say that the format of the (EC)DSA signed message is defined in the RFC4880. It's a pair of r,s integers in both cases. Changes to public keys are needed for both ECDSA and ECDH, defined in section 9.

For internal consistency it might be good to point to section 9.

> I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes and assuming that 521 ~ 512). As with some of the above issues, is it the right thing to do to add a reference if it can be avoided, given that a presence of a reference suggests that the reader must then study it in order to understand a corresponding statements. Isn't the issue of relative strength well-understood, so that readers that use the current table can look it up?

In my experience, the issue of relative strength has NOT been well-understood over the years, and I believe the NIST document is the first to actually pull it all together.

Thanks,
Brian

> Thank you.

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 11 Apr 2012 12:26:46 -0700

Thank you for your comments, Brian. I integrated some of them into -13, 
posted http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/

> Section 5: A reference to ECDSA is given for both RFC 6090 and [SEC1]. The definition in RFC 6090 supersedes [SEC1], and it is preferable to reference just the RFC. I suggest removing "and in [SEC1…

It seems to me that SEC1 provides the most succinct description of the 
algorithm among all the publicly available sources. RFC 6090 refers to 
another external document, which is written in a form of a survey of 
crypto methods, which the reader will need to process to get the 
relevant portion. It's unfortunate that FIPS 186-3 doesn't spell out the 
ECDSA exactly.

> Section 6: RFC 6090 uses the notation "(@,@)" for the point at infinity ("point O"), which would be better to use. This seems to be the only term in this section specific to [SEC1], so making this…

The main reason for SEC1 reference is to define the format 04 || x || y. 
RFC 6090 is missing any method to serialize an ECC point (no on-the-wire 
format).

> Section 6: The reasoning for passing the point at infinity isn't clearly defined. Can you explain when this would be done?

Right beneath of the table there was a sentence that addresses this in 
-12, which I modified to read:

"Note that the point O shall not appear in a public keys, including 
ephemeral public keys used with ECDH, defined in section 8."

Done. P-->Params

> Section 8: Are the "5 variable-length and fixed-length fields" meant to be OtherInfo as defined in SP800-56A? If so, mentioning this would make it easier on the reader.
This is exactly what the qualifiers intended for, but they are only 
needed for persons validating this draft to be compatible with 
SP800-56A. I wonder if the reference here adds any value for the rest of 
readers?

* In OpenPGP the message encryption algorithm (symmetric algorithm of a 
session key) is encrypted to a public key of a recipient. In RFC 4880 
it's done so that the session key is 1_byte_symm_alg || key || checksum. 
One can argue on the benefit of a checksum, but the ID bumps the payload 
size to the next 8 bytes, which gives space to accomodate the checksum 
and PKCS#5 padding markers for free
* One cannot we cannot say which key size was used to encrypt the 
message by looking at RSA or ElGamal encrypted session key. AESWRAP 
leaks this information when it is tightly encapsulated the session key 
(this may leak how sensitive a protected document is). There is a 
description in the same section 8 on how to avoid this leak by padding 
the payload of AESWRAP to make it always look like an AES-256 session key.

> Section 10: The statement "No changes in the format are needed for ECDSA" seems true, but isn't it necessary to describe the Algorithm Specific Fields for ECDSA? Is this actually defined in Section…

I intended to say that the format of the (EC)DSA signed message is 
defined in the RFC4880. It's a pair of r,s integers in both cases. 
Changes to public keys are needed for both ECDSA and ECDH, defined in 
section 9.

> Section 13: The table of equivalent algorithm strengths seems to match claims in SP800-57-Part1-Rev3-May2011. It would be helpful to reference this document here as a source for the information.

I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes and 
assuming that 521 ~ 512). As with some of the above issues, is it the 
right thing to do to add a reference if it can be avoided, given that a 
presence of a reference suggests that the reader must then study it in 
order to understand a corresponding statements. Isn't the issue of 
relative strength well-understood, so that readers that use the current 
table can look it up?

Thank you.

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 11 Apr 2012 17:17:41 -0700

Hello again Brian. Thank you for your comments. I integrated them into 
-14 revision.

On 04/11/2012 02:04 PM, Brian Weis wrote:
> ...
> I believe this sentence is saying that it will never be included in a 
> protocol payload, which makes sense to me. So I'm wondering if there 
> is actually any value for mentioning the value/description of point O 
> it in your I-D? It's a bit confusing to include it if it isn't 
> actually used.
>
>

I eliminated the B0=0.

>> ...
>> SP800-56A. I wonder if the reference here adds any value for the rest 
>> of readers?
>
> Since your stated goal is to meet Suite B requirements, and complying 
> with SP800-56A is part of those requirements, I imagine there will be 
> people wanting to validate this after it becomes an RFC. It would seem 
> to be in your best interest to make it clear to them. :-) People who 
> don't care about the reference will just ignore it.

I added this reference to (already referenced) SP800-56A.

> ...
>> * In OpenPGP the message encryption algorithm (symmetric algorithm of 
>> a session key) is encrypted to a public key of a recipient. In RFC 
>> 4880 it's done so that the session key is 1_byte_symm_alg || key || 
>> checksum. One can argue on the benefit of a checksum, but the ID 
>> bumps the payload size to the next 8 bytes, which gives space to 
>> accomodate the checksum and PKCS#5 padding markers for free
>
>
> Ok, so what you're saying is that you really need the 40 bytes as 
> input to the key wrap function. You should have some text clarifying 
> exactly how you're using the AES Key wrap though. For example: "The 
> inputs to the AES Key wrap are as follows: The Plaintext is taken as 
> the 40 bytes described above, the KEK is the value derived from the 
> KDF, and the Default Initial Value is used."

I added a sentence on Default Initial Value.

Here is what the current document says in section 8.
>
> The input to the key wrapping method is the value "m" derived from the 
> session key, as described in section 5.1. Public-Key Encrypted Session 
> Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 padding step is 
> omitted.~~The result is padded using the method described in [PKCS5] 
> to the 8-byte granularity.~~For example, a following AES-256 session 
> key, which 32 octets are denoted from k0 to k31, is composed to form 
> the following 40 octet sequence:
>
> 09 k0 k1 ... k31 c0 c1 05 05 05 05 05
>
> The octets c0 and c1 above denote the checksum.~~This encoding allows 
> the sender to obfuscate the size of the symmetric encryption key used 
> to encrypt the data.~~For example, assuming that an AES algorithm is 
> used for the session key, the sender MAY use 21, 13, and 5 bytes of 
> padding for AES-128, AES-192, and AES-256, respectively, to provide 
> the same number of octets, 40 total, as an input to the key wrapping 
> method.
>

By the way, I should have mentioned that the search with Google for 
"AESWRAP" will bring up the following page with code to implement the 
key wrapping for this draft:
    http://code.google.com/p/gnupg-ecc/wiki/AESWrap

The following page provides test keys and other practical information to 
implementers:
    http://sites.google.com/site/brainhub/pgpecckeys

>> leaks this information when it is tightly encapsulated the session 
>> key (this may leak how sensitive a protected document is). There is a 
>> description in the same section 8 on how to avoid this leak by 
>> padding the payload of AESWRAP to make it always look like an AES-256 
>> session key.
>>

The design criteria was to keep the message-specific fields as small as 
possible. This is achieved by placing everything possible into the key 
structure. Consider that the KDF parameters field (that affects the 
ECDH) is fixed at key generation.

ECDSA stays the same as DSA, while ECDH needs one additional field with 
AESWrapped key.

This said, I cannot find of a good way to say "compare this [section 10] 
to section 9, just above" ( these comments are a design insight, not a 
spec ).

>> I wanted to convey a statement that ECC==Hash==2*AES (meaning sizes 
>> and assuming that 521 ~ 512). As with some of the above issues, is it 
>> the right thing to do to add a reference if it can be avoided, given 
>> that a presence of a reference suggests that the reader must then 
>> study it in order to understand a corresponding statements. Isn't the 
>> issue of relative strength well-understood, so that readers that use 
>> the current table can look it up?
>
> In my experience, the issue of relative strength has NOT been 
> well-understood over the years, and I believe the NIST document is the 
> first to actually pull it all together.

What stopped me is that this reference points to a draft.

> Brian
...