TLS initial salt is arbitrary

[thysce]

Reading through section 5.2 of QUIC TLS I wondered why the salt is chosen to be that very value of 0xafbfec289993d24c9e9786f19c6111e04390a899? From a security standpoint, putting random numbers in a document without specifying why they have that value seams a bit concerning to me.

Also I couldn't find an explanations for changing that number in previous draft versions. It would be helpful to put a reason for the choice of the salt in the section and/or describe the process of choosing as an appendix for instance.

Maybe it's just me not finding the explanation so please point me to it in that case.

[marten-seemann]

Can you elaborate your security concerns?
This value is not expected to provide any end-to-end security properties to the protocol, it is only used to:

1. provide an easy way to detect packet corruption (as it feeds into an AEAD)
2. prevent version-unaware middleboxes from parsing a packet

[thysce]

I do not have any real concerns, but am am no security expert too. I just stumbled across that number and wondered why it was that oddly specific. Maybe something like 0x314159... (First digits of pi) or 0xf0e1d2c3b4... (asc./desc. Digits) would have made it more clear that there is no meaning to that number at all.
On reading a number that is that arbitrary, I would have expected it to carry some meaning. To clarify this, it might be a good idea to explicitly state that this number was chosen at random.

[MikeBishop]

The intent is obfuscation against middleboxes which don't support the current version of QUIC. Perhaps the clearest way to communicate that intent is to state that future versions of QUIC SHOULD select a different random salt?

[martinthomson]

@MikeBishop we already say that.

The provenance of the value is not security-relevant. It could be an all zero value and essentially be as good. Note that the same applies to the keys used to authenticate Retry packets.

I don't plan to do anything in response to this issue.