Re: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt

Seems like a bad idea to have separate hash and signature values:

> The rationale for separating the hash function and the cryptographic
   algorithm into two octets instead of having all combinations in a
   single octet - possibly as TLV type extension - is twofold: First, if
   further hash functions or cryptographic algorithms are added in the
   future, the number space might not remain continuous.  More
   importantly, the number space of 256 possible combinations would be
   rapidly exhausted: 16 different hash functions and 16 different
   cryptographic algorithms would lead to exhaustion.

Having multiple combinations is a bad idea.  It greatly complicates testing of devices since it leaves available many combinations.

The notion that 16 hash and 16 signature values would fill the number space is incorrect.  There is no reason to allow all of the combinations - only a few really make sense.

Similar comments for the parameters.  The overall security context needs to have a definition, but allowing parameterization complicates testing and leaves open room for downgrade attacks.

MD5 should NOT be included in the requested list of hash algorithms.

The cryptographic algorithm registry is poorly constructed and does not accommodate modes of operation (modes should not be a parameter)

This whole encapsulation seems generic and not specific to MANET.  Aren't there existing encapsulations that could be used?

Paul

Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Bo Berry
> Sent: Sunday, June 20, 2010 5:14 AM
> To: manet@ietf.org
> Subject: Re: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt
> 
> Ulrich, Thomas:
> 
> Below are a few points for consideration and discussion.
> 
> Regards
> -Bo Berry
> 
> 
> In section 10.2.2.  Hash Function suggest adding  SHA-128, SHA-256,
> SHA-386, SHA-512 under SHA-2.
> 
> And in section 10.2.3.  Cryptographic Algorithm, suggest adding ECC.
> 
> As noted in section 5, "Before being able to validate a cryptographic
> signature, routers have to exchange keys (e.g. public keys)."  Each
> router (node) may have several keys (key ring). In this case, it would
> be useful to define a key index TLVs.  The Key Index TLV would be
> needed when multiple keys are used.
> 
> Also suggest breaking the <signature> TLV into separate TLVs to
> increase flexibility and to align with the separate <timestamp> TLV.
> Nodes may wish/need to configure the hash and crypto functions when
> keys are configured and would not need to carry this info in the
> signature TLV.
> 
> So we could define the following TLVs:
> 
>       <key-index TLV> := <key index value>
>       <hash-function TLV> := <hash function identifier>
>       <cryptographic-algorithm TLV> := <crypto-algor identifier>
>       <signature-value TLV> := <signature value>
> 
> 
> 
> 
> On Jun 20, 2010, at 4:41 AM, Ulrich Herberg wrote:
> 
> > 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
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Mobile Ad-hoc Networks Working Group of
> the IETF.
> >
> >
> > 	Title           : MANET Cryptographical Signature TLV Definition
> > 	Author(s)       : U. Herberg, T. Clausen
> > 	Filename        : draft-ietf-manet-packetbb-sec-00.txt
> > 	Pages           : 17
> > 	Date            : 2010-06-19
> >
> > 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.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-sec-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > <Mail Attachment>_______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
> 
> 
> 
> 
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet