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

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 02 Feb 2014 14:33:04 -0500

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 11.3.1.7 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

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 2 Feb 2014 18:18:49 -0800 (PST)

> which features you need, not what is practical.

  They may be separable but you don't want to separate them. You
never want to do encryption without integrity protection. You can
do integrity protection without encryption though and there are
TLS ciphersuites to give you that-- TLS_RSA_WITH_NULL_SHA256--
but there are none that give you encryption without also giving you
integrity protection.

  You can address the comment by swapping terms, i.e. say "integrity
protection and/or encryption".

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 2 Feb 2014 19:08:51 -0800 (PST)

> were increasing the size of a namespace by eliminating possible names.

  Well that's a hair brained policy, but username selection is not a good
analogy. I was at a company that had no strict requirements on a username
so there should have been a near infinite size of the namespace. But we had
a collision when the company had less than 10 employees because there
was another "dan" at the company.

> possible tags, thereby increasing the chance of collision.

  That would be the case if all tags in the Sum(i=1..64) 0x5e^i tagspace
were equally probable of being chosen. Which implies implementations
choosing a random tag length for each tag generated in addition to a
random tag selection scheme for the randomly chosen length. I suspect,
though, that in practice the tag length will be fixed for a particular
implementation and the tag selection scheme will not necessarily be
random. So the herd mentality, plus the proliferation of one or two
companies' ALTO servers, will result in a severely reduced size of the
effective tagspace and the increased possibility of collisions.

  A tag generated as SHA256(NetworkMap) represented in 64 hex
characters would basically guarantee you'd never have a collision.
Saying, "it can be anything you want as long as it's less than 64
octets" would not.

  Dan.

---

From: Richard Alimi <[email-masked]>
Date: Sun, 9 Feb 2014 23:03:22 -0800

> Saying, "it can be anything you want as long as it's less than 64

Should I interpret your comment to say that we should to require particular
mechanisms for generating version tags, or be more explicit about
suggesting mechanisms that have a low collision probability?

To help steer readers towards better implementation practices, we'll change
the examples to use hashes in the version tags.

Thank you again for the review!

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 17 Feb 2014 06:38:34 -0800 (PST)

Hi RIchard,

> suggesting mechanisms that have a low collision probability?

  Yes, I think you should. Suggestions on how to ensure a low
probability of collision would be helpful.

> the examples to use hashes in the version tags.

  That's a great idea. So people who implement ALTO and check
the example will use hashes themselves and that will help ensure
a low probability of collision.

> Thank you again for the review!

  You're very welcome!

  regards,

  Dan.

---

From: Richard Alimi <[email-masked]>
Date: Mon, 17 Feb 2014 13:46:22 -0800

> probability of collision would be helpful.

We've added the following text to section 10.3:

It is RECOMMENDED that the tag have a low collision probability with other
tags. One suggested mechanism is to compute it using a hash of the data
content of the resource.

> a low probability of collision.

This change has been made to our copy in SVN.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Feb 2014 13:37:52 -0800 (PST)

Hi Richard,

On Mon, February 17, 2014 1:46 pm, Richard Alimi wrote:
>> >> so there should have been a near infinite size of the namespace. But
>> we
>> >> had
>> >> > 0x5e^64 possible tags.  But if it is required to be up to 64
>> octets,
>> >> you

  That sounds great!

> This change has been made to our copy in SVN.

  Fantastic. Thank you very much for your resolution to my comments.

  Dan.