Re: [dnsext] draft-hoffman-dnssec-ecdsa-01

[Robert Moskowitz <[e-mail]>]

On 01/27/2010 11:23 AM, Paul Hoffman wrote:
> At 1:30 PM +0100 1/27/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>    
>> I have a few technical points to be discussed for the DNSSEC
>> EDCDA draft, draft-hoffman-dnssec-ecdsa-01.
>>
>>
>> (1)  bit string vs. octet strings
>>
>> Cryptographers are used to think in bit strings of arbitrary
>> bit size.  DNS folks usually deal with octet strings.
>>
>> Since the introduction of bit strings does not incur any visible
>> benefit here, I suggest to avoid the notion of bit strings entirely
>> throughout the draft and use octet string oriented language and
>> octet string sizes for field descriptions.
>>      
> I figured that keeping the cryptographers happy while not hurting the DNS folks was a good idea. I'm happy to change, however.
>    

Paul, is there some reason you did not include P-521?  I might think it 
should be here for completeness.  It is in RFCs like 4753.

>    
>> (2)  representation of EC keys
>>
>> Section 3 of the draft says (in its first paragraph):
>>
>> |  ECDSA public keys consist of a single value, called "Q" in FIPS
>> |  186-3.  In DNSSEC keys, Q is a simple bit string that represents
>> |  the uncompressed form of a curve point.
>>
>> This is by far underspecified for the intended audience of this memo.
>>
>> Section 2.3.3 of the SEC-1 Standard specifies the precise algorithm
>> to convert an EC point to a 'normalized' octet string.
>> This algorithm is widely adopted (IEEE, ANSI, NIST, IETF PKIX, etc.).
>> Making explicit reference to the resulting data format should
>> provide benefits for re-using existing crypto-APIs as well.
>>
>> I recommend to normatively quote this specification in a similar
>> way as it is done in various new RFCs, including this week's
>> RFC 575? series.
>>      
> That sounds good.
>
>    
>> Further, the restriction to uncompressed form seems unnecessary,
>> or even detrimental to the intended benefit of savings in DNS
>> response packet size as well as consumed bandwidth and delay.
>> The use of the compressed form essentially would cut down the
>> EC key size to half the size of the uncompressed form.
>>      
> Some IPR claims have been made on the compressed form, and none on the uncompressed form. I chose to avoid that problem.
>
>    
>> The draft text also is silent about the 'quality' requirements.
>> SEC-1 and various NIST publications contain verification procedures
>> and requirements for key generators, signers, and verifiers.
>> Such requirements are already imported in recent IETF documents,
>> cf. the abovementioned RFC 575? series.
>> I suggest that the draft be amended by related normative text,
>> after discussion of the assurance level the WG deems needed for
>> this application of ECC.
>>      
> The current DNSSEC documents do not reference the NIST material on provable and probable primes in the discussion of RSA. The material you suggest is parallel. I'm happy to add it, but it will likely cause people to think that ECC is harder than RSA.
>
>    
>> (3)  Precision if data element/field specification
>>
>> Given the intended audience of the draft, the size of the data
>> elements used in the specification should be made explicit.
>>
>> I suggest to introduce a parameter 'm' (this is 'mlen' in SEC-1)
>> into the table in Section 3 and make systematical use of it in
>> Section 4.
>>      
> Given how few people understand NIST's m values, I think this will lead to more confusion for no benefit.
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>
>