Figure out which transcript is authenticated #57
Comments
|
"compact binary encoding" brings to mind CBOR. I think having a canonical/compat JSON format is beyond the scope of this doc. |
|
CBOR is a possibility, but defining a compact, canonical CBOR representation might also be nontrivial. Personally, I would reuse the TLS extensions field format, with numeric key IDs and binary formats defined for each cTLS template element. |
|
Perhaps reading RFC 8949 will change your mind.
|
|
My main concern about a generic JSON->CBOR conversion is that it is still an inefficient encoding, and I would like to be able to distribute cTLS profiles efficiently. A generic CBOR encoding would still have keys represented as strings, binary values represented in hexadecimal, etc. Even apart from efficiency, I still have concerns regarding canonicalization. For example, some JSON-handling intermediaries are likely to alter the order of keys in maps, convert integer-valued floats to integers, etc. |
|
I was suggesting cbor as the inter-machine transport. As for keys-as-string, well, you are using json and therefore don't have alternatives. Maybe use the TLS presentation language. It's already part of TLS stacks, is pretty compact, and canonical. |
This is a radical change that attempts to implement the (possible) consensus to move from a "reconstruction-based" transcript to a "non-reconstruction" transcript. Verifying the transcript without reconstruction requires the transcript to include the template, which requires a byte-identical representation of the template. This change makes this possible by introducing a stable binary representation of the template, with JSON as a human-readable alternative. This change also attempts to: * Clarify the use of cTLS in datagram contexts - Including how retransmission works without sequence numbers * Formalize the notion of when vector lengths can be omitted * Rearrange the extension templating in a more convenient fashion Fixes #57
There was some discussion in the TLS session at IETF 113 about whether the Finished message should authenticate the reconstructed TLS transcript (as currently) or the cTLS transcript. We should try to reach a conclusion about this.
Note that, if it is allowed to receive compression templates over an untrusted channel (#56), authenticating the cTLS transcript would presumably require including the compression template in the transcript, to avoid cross-template attacks (e.g. injecting the attacker's
key_sharewithout altering the transcript). To avoid hashing JSON (which might be reformatted by intermediary systems), this would probably require defining a compact binary encoding of the JSON template (which I would like to have!).The text was updated successfully, but these errors were encountered: