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

[Jeffrey Hutzelman <[e-mail]>]

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