[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!



Yes, I am beginning to see this, though I still don't fully understand
it.

For example, in RFC 3971, section 5.2:

5.2.  RSA Signature Option

...

     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     |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Key Hash                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Digital Signature                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                           Padding                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

      This field starts after the Key Hash field.  The length of the
      Digital Signature field is determined by the length of the RSA
      Signature option minus the length of the other fields (including
      the variable length Pad field).

   Padding

      This variable-length field contains padding, as many bytes long as
      remain after the end of the signature. 

This seems like a catch-22. How can someone determine the length of the
Digital Signature field as there's no indication of how long the pad
field is.

Therefore, the Digital Signature field's length MUST be known based on
other information (key, etc).

So, sure, putting 0's in the 100s of bytes and, likely more
significantly, having to calculate the signature over those additional
bytes is a cost.

If we feel that is a burden, using multiple fragments is the way to go.
Based on the original write-up in the draft, this is required anyway so
there's really no savings.

       Signature       A variable-length field containing a digital 
                       signature. The signature value is computed with 
                       the hash algorithm and the signature algorithm, 
                       as described in HA-id and SA-id. The signature 
                       constructed by using the sender's private key 
                       over the following sequence of octets: 
                        
                       1. The 128-bit CGA Message Type tag value for 
                       Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090 
                       0665 d2e0 02c2. (The tag value has been 
                       generated randomly by the editor of this 
                       specification.)
                        
                       2. The 128-bit Source Address field from the IP 
                       header. 
                        
                       3. The 128-bit Destination Address field from 
                       the IP header. 
                        
                       4. The entire DHCPv6 message EXCEPT for the
                       option-code, option-len and Signature fields of
                       this option.

It does require one more fragment than the original specification (the
data beyond the end of the option). For the nodes that always add the
option as the last option (based on their choice to do so), they can
avoid this last fragment. But, of course they can't assume this when
receiving a message.

- Bernie
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg