On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett <davemgarr...@gmail.com>
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recognize sentinel values from all future versions,
> not just this one. Thus, for future proofing, (just) using the version
> number isn't a great idea. It's probably safest to just pick one static
> value and be done with it forever.
>
That may be true, but then this value is as good as any other.
An alternative would be to burn N-8 bits on a sentinel and then
8 bits on the version number. E.g.,
01 02 03 04 05 34 [0]
BTW, I'm basically indifferent between 48 and 64 bits.
-Ekr
[0] I didn't use 00 00 00 00 00 as the sentinel because I have some vague
memory
that there are implementations which use 0s in the timestamp.
And now, for my proposed bikeshed color:
>
> 0x0b501e7e5e1ec7ed
> ("obsoleteselected"; 64-bit value)
>
> I'd like to say I was clever enough to come up with neat hex words, but I
> Googled for a list and found 2 to put together. ;)
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
