Re: [secdir] secdir review of draft-ietf-alto-protocol

Jeffrey Hutzelman <> Sun, 02 February 2014 19:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C37FA1A0101; Sun, 2 Feb 2014 11:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a8DNgaTtOro4; Sun, 2 Feb 2014 11:33:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8C4A31A0100; Sun, 2 Feb 2014 11:33:17 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id s12JX4Vo020510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Feb 2014 14:33:10 -0500 (EST)
Message-ID: <>
From: Jeffrey Hutzelman <>
To: Dan Harkins <>
Date: Sun, 02 Feb 2014 14:33:04 -0500
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Feb 2014 19:33:20 -0000

On Sat, 2014-02-01 at 10:54 -0800, Dan Harkins wrote:

>   - 6.3, since the tag must not contain ASCII characters below
>      0x21 or above 0x7e you can't really construct one from the
>      hash of the contents of a Network Map.

Uh, sure you can.  Figure out some scheme for serializing the contents.
Compute a hash.  Encode in base64.  Or hex.

>  Also, given those
>      restrictions and the fact that a tag just has to be less than
>      or equal to 64 octets, the probability of identical tags being
>      used is not zero. I think the probability of the tag from
>      example is 0.5 to collide with one of just 460
>      other Network Maps.
>      I suggest requiring a tag to be 64 octets. That will make
>      even money probability of collision among nearly 3000
>      other Network Maps, which is safer.

OK, maybe I'm confused and reading out of context here.  But I once had
someone tell me I needed to change my 5-character username because they
were requiring all usernames to be at least 6 characters, _in order to
increase the number of possible usernames_.  That is, they claimed they
were increasing the size of a namespace by eliminating possible names.

The point is, if a tag is required to be exactly 64 octets, you get
0x5e^64 possible tags.  But if it is required to be up to 64 octets, you
get Sum(i=0..64) 0x5e^i possible tags, which is strictly greater than
0x5e^64.  So, requiring a tag to be 64 octets _reduces_ the number of
possible tags, thereby increasing the chance of collision.

>   - 8.3.5, encryption and integrity protection go hand-in-hand,
>      they cannot be "and/or".

Huh?  That's not true.  Confidentiality and integrity are separable, and
it is common to want one without the other.  As it turns out, neither
TLS nor SSH generally gives you that option, but the and/or is about
which features you need, not what is practical.

I do agree that it's clearer to use the word "confidentiality" rather
than "encryption".

-- Jeff