Re: [manet] WG adoption of NHDP-sec

Chris,

before I will reply to your comments, I have a general question: Do your comments apply to packetbb-sec or to NHDP-sec? It seems to me they apply to packetbb-sec, rather than NHDP-sec...

Ulrich

On Apr 21, 2011, at 17:17, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> 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.
> 
> The obvious response to that is to pick a new type extension
> for such. 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.
> 
> 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 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: +44 1245 242194  Fax: +44 1245 242124
> 
> 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] 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
> manet@ietf.org
> 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.
> ********************************************************************
> 