[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Re: STUN/ICE: Username length inconstency
On Tuesday 21 August 2007 01:16:39 ext Jonathan Rosenberg wrote:
> This is a good catch. I recently introduced the limit in STUN based on
> last call comments, forgetting that we had ICE use cases that could
> result in values longer than 127. I had picked 127 thinking about human
> readable usernames. My bad. I think the limit in STUN should be
> increased to match ICE, not the other way around.
Hmm, I am not sure 1023 character long username are that great really. For a
start, after concatenation (2047 characters), you'll get connectivity checks
that exceed the typical Internet MTU. That brings either problem:
- NATs will not handle fragmented packets, or
- ICE implementation will refuse to send at all (packet too big).
Second, I wonder if if makes sense to have a higher entropy for the username
(12,000 bits here!) than we have for the message integrity (160 bits
currently) or the shared secret password. But that's something for security
gurus to judge. Even if we switched to SHA512, we'd still have more than
enough username entropy with just 63 characters from each sides (756 bits).
Third, we do not want to drain the entropy pool of ICE-capable device too
badly. There are better stuff to dedicate entropy to that ICE connectivity
checks, such as generating TLS parameters.
--
Rémi Denis-Courmont
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic