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

[Ulrich Herberg <[e-mail]>]

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.
> ********************************************************************
>
>