Re: [manet] packetbb-sec WGLC comments (was: Re: WG adoption of NHDP-sec)

[Ulrich Herberg <[e-mail]>]

Chris,

after some more discussions between the authors of packetbb-sec, we can
agree with your point of view. We will work on a new revision, which we will
submit soon.

Regards
Ulrich

On Tue, May 24, 2011 at 5:34 PM, Ulrich Herberg <[e-mail]> wrote:

> Chris,
>
> sorry for the late reply, I was very busy these last weeks ;-)
>
> On Thu, Apr 21, 2011 at 5:17 PM, Dearlove, Christopher (UK) <
> [e-mail]> wrote:
>
>> Brief version: I think there's a two part change that should
>> be included before finishing WGLC.
>>
>> My apologies in advance in that should this spark a discussion,
>> I'll be out of the loop for a week and a half and no able to
>> contribute. (The UK is largely shutting down, we have for a
>> combination of rare reasons, two four day weekends, with a
>> three day gap. Many of us are taking those three days off too.)
>>
>> My main concern over this document is that it specifies a
>> signature as the composition of a hash function and a
>> cryptographic function, in that order. There are other ways
>> of constructing signatures that do not correspond to such
>> a decomposition.
>>
>
> I agree that there other ways of constructing signatures. In your case,
> couldn't you just select the identity function as hash function and then
> only use the cryptographic function for creating the signature (i.e.
> chris_special_signature_function(id(message)) )?
>
> If that is not suitable, of course, a new type extension could be used:
>
>
>>
>> The obvious response to that is to pick a new type extension
>> for such.
>
>
> yes
>
>
>> This can't be normative text in this document, but
>> I think it should be described in the applicability statement,
>> which should say that this specification describes a general
>> approach to signatures (much of the document, such as how to
>> traety hop counts/limits is not specific to this decomposition)
>> and then a specific approach to signatures, and should provide
>> the comment that other mathematical forms of signature are
>> possible, and should be handled by use of alternative type
>> extensions. In the main body of the specification, a bit more
>> clarity on what is form-specific and what is not would then
>> help.
>>
>
> Yes, I agree to that and will update the text accordingly.
>
>
>>
>> This then leads to the question a to whether the form described
>> should be the privileged type extension = 0 case. Actually I
>> would suggest it should be type extension = 1, with 0 reserved
>> for "I'm not providing any information on algorithms, this is
>> defined out of band, not in each packet. The reason I suggest
>> that as type 0 (and including it in this document) is that it
>> puts the two lowest-overhead options together (type extension 0,
>> which can be omitted, and no algorithm information).
>>
>> Note that for timestamp, what other type extensions may be is
>> alraedy covered, but not so for signatures, and timestamp uses
>> the type extension 0 for the analogous case I suggest for type
>> extension 0 for signature, i.e. detertmined otherwise (should
>> the phrase "administrative action" be used in both cases?)
>>
>
> I see your point. However, I am not convinced that the additional overhead
> of setting the type extension for the proposed decomposition into
> hash+crypto is desirable. Most signatures mechanisms that I am aware of use
> this decomposition. There are certainly other ways of calculating a
> signature, but sending an additional octet in every message for these -- at
> least currently -- rare cases needs to be justified. As for timestamps, I
> don't see one single prevalent way of representing a timestamp, which is why
> we use the type extension 0 for a general case.
>
> Ulrich
>
>
>>
>> I think there should be another iteration before going to
>> SECDIR and IESG, as I think it will avoid work further down the
>> line, as well as being a better specification this way.
>>
>> --
>> Christopher Dearlove
>> Technology Leader, Communications Group
>> Communications and Networks Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: [phone]  Fax: [phone]
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87,
>> Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Joe Macker
>> Sent: 07 April 2011 17:17
>> To: MANET IETF
>> Subject: [manet] WG adoption of NHDP-sec
>>
>>
>>                    *** WARNING ***
>>
>>  This message has originated outside your organisation,
>>  either from an external partner or the Global Internet.
>>      Keep this in mind if you answer this message.
>>
>>
>> As discussed in Prague we are presently considering adoption of NHDP
>> security related document as a WG document.
>>
>> reference is draft-herberg-manet-nhdp-sec-01
>>
>> Please comment if you have an opinion.
>>
>> -Joe
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended
>> recipient please delete it from your system and notify the sender.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>>
>>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>