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

[Paul Lambert <[e-mail]>]

Combining the cryptographic parameters into a single suite identifier does not limit or hinder "future design/need".  It only clearly identifies the intended pairing/combinations of algorithms.

Allowing mix and match parameterization causes severe interoperability problems, testing complexity and potential security attacks (downgrade attacks).

A example of the mess that such a design can create is the mix-and-match parameterization used in the 802.11i security parameters.  Even though two devices may both support the same encryption algorithms, the parameterization can prevent interoperability.  The lare number of combinations due to the parameterization also prevents adequate testing.

Picking algorithms and allowing bad choices (like Md5) is poor design.  It's the result of not having clear product/system requirements.  Rather than perpetuating this indecision and the associated poor design practices, only one or two algorithm suites should be defined.  The RFC and number assignment process will allow extension of the defined suites when there are advocates for the new mechanisms.  

Including MD5 and 3DES in a new design is bad idea.  There is no existing implementation of the new protocol so there can be no legacy need for the depreciated algorithms.


Paul


 
Paul A. Lambert | Marvell Semiconductor | [phone]
 
> -----Original Message-----
> From: Bo Berry [mailto:[e-mail]]
> Sent: Tuesday, June 22, 2010 7:42 AM
> To: Paul Lambert
> Cc: [e-mail]
> Subject: Re: [manet] I-D Action:draft-ietf-manet-packetbb-sec-00.txt
> 
> Paul
> 
> Since RFC5444 and the draft is meant to be a generic packeting framework,
> having greater flexibility should be the goal so the framework does not
> hinder a future design/need.  Multiple combinations does not imply that a
> specific implementation would support all the combos.  It is reasonable
> that an implementation may choose to support a single feature and error on
> everything else.
> 
> As for MD5, I do not desire to use it but someone out there may have a
> real, acceptable need.
> 
> A different perspective.
> 
> -Bo
> 
> On Jun 21, 2010, at 7:25 PM, Paul Lambert wrote:
> 
> >
> >
> > 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 | [phone]
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >> Bo Berry
> >> Sent: Sunday, June 20, 2010 5:14 AM
> >> To: [e-mail]
> >> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/manet
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> manet mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/manet
> 
> ----
> [e-mail]
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. This email may contain information that is
> protected by NDA. Any unauthorized review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient
> (or authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> 
> 
> 
>