Re: [manet] Fwd: New Version Notification fordraft-ietf-manet-packetbb-sec-00

["Dearlove, Christopher (UK)" <[e-mail]>]

I'm in favour of a signature TLV, for the usual reasons of
not all reinventing similar wheels. However for an instance
of use I may have, this proposal wouldn't work as is.
Expecting not to be unique, here are some comments.

The first issue is that not all signatures are simply an
encryption of a hash. I have a concrete example in mind,
but rather than disclose that example, I'll refer to the
Schnorr signature (there's a Wikipedia page that's good
enough to show this). This would make this constained
specification not work. Note that even a minimal expansion
to include Schnorr wouldn't be sufficient. Note that I'm
not suggesting using Schnorr, it's just a convenient public
example of the point.

The next point pulls in two directions. First some cryptographic
algorithms need parameters, so to specify such an algorithm needs
more than just an algorithm code. But then a given deployment
might, for various reasons, require all nodes to be using the same
set of parameters, at which point space considerations (if nothing
else) dictate that sending those parameters in every packet/message
is pointless. But now why send the octet (or anything else) indicating
the encryption algorithm? It doesn't fully specify the method, and if
the parameters are agreed, so by implication is the encryption
algorithm. The only value of the indication of the method is if we
support more than one method, to distinguish between them. But that
may be to distinguish between, for example, different parameterisations
of the same method.

Putting those together, the only thing I could use from this
specification for the approach I'm interested in (or at least one
of them) is to use the given TLV value and then pick a private type
extension and do my own thing in that space. If that didn't involve
passing any method information, but was just implicitly assuming
that the algorithm (and parameters) was agreed, then the TLV value
would simply be the signature. This could then be a defined type
extension rather than having to use a private one. Arguably that
should be type extension zero, with type extension 1 being the
special case of signature=encrypt(hash(data)).

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
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 Ulrich Herberg
Sent: 20 June 2010 09:42
To: [e-mail]
Cc: Thomas Clausen
Subject: [manet] Fwd: New Version Notification fordraft-ietf-manet-packetbb-sec-00


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

I have submitted the packetbb-sec draft as WG draft. The draft does
not contain any changes since the last individual draft
(draft-herberg-manet-packetbb-sec-03). We will work on a new revision
until the IETF meeting in Maastricht.

Best regards
Ulrich

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[e-mail]>
Date: Sun, Jun 20, 2010 at 4:13 AM
Subject: New Version Notification for draft-ietf-manet-packetbb-sec-00
To: [e-mail]
Cc: [e-mail]



A new version of I-D, draft-ietf-manet-packetbb-sec-00.txt has been
successfully submitted by Ulrich Herberg and posted to the IETF
repository.

Filename:        draft-ietf-manet-packetbb-sec
Revision:        00
Title:           MANET Cryptographical Signature TLV Definition
Creation_date:   2010-06-20
WG ID:           manet
Number_of_pages: 17

Abstract:
This document describes a general and flexible TLV (type-length-value
structure) for representing cryptographic signatures as well as
timestamps, using the generalized MANET packet/message format
[RFC5444].  It defines two Packet TLVs, two Message TLVs, and two
Address Block TLVs, for affixing cryptographic signatures and
timestamps to a packet, message and address, respectively.



The IETF Secretariat.
_______________________________________________
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.
********************************************************************