Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01

[Tony Cheneau <[e-mail]>]

Hello Roque,

The text you extracted corresponds to a part of the Supported Signature
Option. The only part that is interesting here is the Signature Type
Identifier that can be stored in the Reserved field of the PSO.  Maybe a
more relevant text would be:

  Signature Type Identifier is a 5-bit field.  It corresponds to the
  Signature Type Identifier subfield (bits 3 to 7 of the Signature
  Algorithm field) in the Supported Signature Algorithm option (defined in
  [draft-cheneau-csi-send-sig-agility-01]).  It indicates the type of
  signature contained in the Digital Signature field.

And this kind of PSO 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |      Reserved       |   STI   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                          Key Hash                             |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                       Digital Signature                       .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                           Padding                             .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



I think that the working group should discuss on what mechanism is to be
allowed for  Signature Agility in the newly defined * Signature Option
(PSO, here, but also Universal Signature Option). For example, we could
only require a 5 bit field as proposed here. This would allow us to
define new option and such, while waiting for a complete solution to be
approved by the working group.
What do you think ? Is that obvious or should we speak this any further
?

Regards,
 	Tony

On Thu, 10 Dec 2009, Roque Gagliano wrote:

> Julien,
>
> You can even include Tonys text about "Signature Algorithm":
> "
>   Signature Algorithm
>
>      A one-octet long field indicating a signature algorithm and the
>      corresponding hash algorithm that this node supports; this support
>      implies at least ability to verify signatures of this Signature
>      Algorithm algorithm.
>
>      If the first leftmost bit, bit 0, is set to 0, it indicates that
>      the emitter is able to perform signature checks only (i.e. no
>      signature generation with this type of signature algorithm).  If
>      this bit is set to 1, it indicates that the emitter has a public
>      key of this type and can generate signatures.  Bit 1 and 2 are
>      reserved.  Bit 3 to 7 are named Signature Type Identifier subfield
>      and encode an identifier for the signature algorithm and
>      corresponding hash algorithm.  Default values for the Signature
>      Type Identifier subfield defined in this document are taken in
>      part from the IANA-defined numbers for the IKEv2 protocol, i.e.
>      IANA registry named "IKEv2 Authentication Method":
>
>      *  Value 0 is RSA/SHA-1 (compatible with [RFC3971])
>
>      *  Value 1 is RSA/SHA-256
>
>      *  Section 5 of document [cheneau-csi-ecc-sig-agility] provides
>         values for ECDSA signature algorithm
> "
> Roque.
>
> On Dec 10, 2009, at 1:09 AM, Roque Gagliano wrote:
>
>> Hi Julian,
>>
>>>
>>> So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.
>>>
>>
>> The distinction is not so clear for me but I am fine with "no innovating".
>>
>>>> That is something I made clear in the CERT draft.
>>>
>>> But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved.
>>>
>>>>> The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility.
>>>>
>>>> So, we know there is a problem and probably know that SEC ADs are looking at these particular issues, however we would to advance this draft to the IESG hopping that it passes their LC with the promise to solve the issue later on? I only have been in CSI for a couple of months but does not sound proper IETF process to me.
>>>>
>>>> The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new SEND options have the possibility of identifying which algorithms each party are using, leaving the signaling part for later. This is similar to DNSSEC where in order to change from SHA-1 to SHA-256 probably all signatures will be for a while duplicated in the zone files.
>>>
>>> Would inclusion of an algorithm field in the PSO solve your concern?
>>
>> IMHO, it will help to move the document through the next step.
>>
>> Roque.
>>
>>> --julien
>>
>> -------------------------------------------------------------
>> Roque Gagliano
>> LACNIC
>> [e-mail]
>> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE
>>
>
> -------------------------------------------------------------
> Roque Gagliano
> LACNIC
> [e-mail]
> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE
>
>