Re: [Hipsec] Host ID Parameter in RFC5201-bis

[Tobias Heer <[e-mail]>]

Hello Henrik, 

thanks for the input. Short version: I think you comments are good and the HI parameter should be self-contained. I agree with removing the DNSKEY format.

More comments in line.

Am 30.11.2010 um 19:01 schrieb Henrik Ziegeldorf:

> Hi,
> 
> I'm currently implementing basic elliptic curve cryptography for HIP according to RFC5201-bis,
> and have some suggestions concerning the Host ID parameter (Sect. 5.2.8).
> 
> I'd like to discuss the following points:
> 
> 1) Self-containment of the host_id parameter: For RSA/DSA identities an algorithm field is specified, for ECDSA identities there is none.
> 
> For RSA and DSA the format of the host identity field is defined as the DNSKEY format.
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             flags             |    protocol   |   algorithm   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               /
>    /                          public key                           /
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
> 
> For ECC, the host identity field format is defined as follows:
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          ECC Curve            |                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Public Key                            /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Note, that the format for ECDSA identities has no algorithm field, which would allow to identify the use of ECDSA algorithm.
> This isn't really serious, since we can determine from HIT_SUITE_LIST parameter which algorithms we use.
> However, this leads to the parameter not being self-contained anymore,
> since from the host_id parameter alone we cannot distinguish the algorithms in use, i.e. RSA, DSA or ECDSA.
>   
> I see two alternatives to provide for self-containment (and make it easier to implement):
> 
> 
> a) Adapt the format of the ECC HI field to the format for RSA and DSA identities.
>    I guess this would make sense, if their is some future usecase in HIP for the flags and protocol fields.
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             flags             |    protocol   |   algorithm   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          ECC Curve            |          Public Key           /               
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
>    /                                                               /
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
After some thinking, I would not favor this alternative although there are efforts to define DNSKEY for ECC. First, I don't know if it is a good plan to attach to these ongoing efforts because they have different goals than HIP (e.g., http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04 only defines p-256 and p-384, no lower - we would not have a curve for low-power devices). We could try to ask for lower curves but I think it is not likely to have DNSKEY documents for all curves (e.g., binary curves, etc.) that might be needed for different HIP use cases.

If we wouldn't attach to these efforts and define our own curves but reuse the DNSKEY format and description we would need our own algorithm numbers assigned to be compatible with DNSKEY. I don't think this is useful in terms of standardization of DNSKEY. Hence, I would prefer the alternative mentioned below and define DNSKEY mappings for HIs instead. That way, one could still pull the keys from DNS and apply minor conversions to generate a HI from it.

> 
> b) Dump the flags and protocol fields (and loose compatibility to DNSKEY Format as defined in RFC2535 3.1)
>    and include algorithm as a fixed field in the host_id parameter, f.e.
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |             Type              |             Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |          HI Length            |DI-type|      DI Length        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Algorithm   |            Host Identity                      /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      /                               |         Domain Identifier     /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      /                                               |    Padding    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> To me, this makes more sense, since values for the algorithms are already defined in Sect. 5.2.8
> (but might only be used with the RSA, DSA formats).
> 
>         Algorithms       Values
> 
>         RESERVED         0
>         DSA              3 [RFC2536] (RECOMMENDED)
>         RSA              5 [RFC3110] (REQUIRED)
>         ECDSA            7 [fundamental-ecc] (RECOMMENDED)
> 
> Without an explicit algorithm field, it is unclear where to use the ECDSA value.

To me it makes sense. Anyone on the list with good reasons not to do this?

> 
> 2) If the host_id parameter format was not changed, the following happens:
> 
>   - First, we would need HIP_SUITE_LIST to distinguish RSA/DSA and ECDSA.
>   - Then, in the RSA/DSA case we would need to peek into the host identity's algorithm field to distinguish RSA and DSA,
>     since HIT_SUITE_LIST does not distinguish between RSA and DSA.
> 
>   I think it is nicer and cleaner to have one single field to distinguish between the RSA, DSA and ECDSA (and other future algorithms),
>   instead of having this two-step process to distinguishing algorithms. (And also, this supports my point above.)

Yes, self-containment is essential - also for storing and passing on the HIs.
> 
> 
> 2) Minor editorial change:
>    In RFC5201-bis the definition of the ECC host identity gives the impression,
>    that there seem are 2 undefined bytes directly after ECC Curve field.
>    Shouldn't the format for ECC HI's be written like this instead:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |          ECC Curve            |      Public Key               /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
>      /                                                               /
>      /                                                               /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
ACK.

Tobias
-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi