Re: [TLS] Choice of Additional Data Computation

[Felix Günther <[e-mail]>]

Hi,

Sorry for chiming in with delay (thanks @Chris for pinging me); I'm not
following the list very closely, feel free to additionally CC me in case.


First of all, let me make sure I correctly understand that
 * "on-the-wire header" is what's exemplified in Fig. 4 of the draft
 * "pseudo-header" would be a superset, esp. including full epoch, full
sequence number, length, connection ID, ... -- what else?

Further, I understand there is _no_ unique mapping from pseudo-header to
on-the-wire header (as the latter may be compressed in different ways).

The latter, to me, suggests that authenticating the pseudo-header alone
may not be sufficient. It would at least allow on-path modifications to
the on-the-wire header, which I don't expect is intended.


As for the current authentication of the on-the-wire header: We [1] did
an analysis of the record layer of DTLS 1.3 (and QUIC) in which
 + we establish confidentiality, integrity and robustness ("correct
operation under adversarial manipulation")
 + of the record layer deprotecting packets with encoded/abbreviated
sequence numbers to payload fragments
 + under an adversary that can arbitrarily tamper with the packets (in
particular truncate ciphertext, i.e., modify lengths)
 + based on standard AEAD security.

However, our work did not consider
 - epochs or key updates (analysis under one key only)
 - the full header (only model encoded sequence number entering the AAD)
[- processing of payload fragments into the actual multiplexed data
streams (as in the TLS-related models Chris mentioned [2,3]; this only
applies to QUIC's application interface, and arguably is beyond the
cryptographic operations).]


Our analysis supports the arguments that:

 1) The length is implicitly authenticated through the ciphertext itself
-- tampering with the ciphertext, in particular its length, will make
AEAD decryption fail.

 2) The full sequence number is implicitly authenticated through the
nonce -- decoding the wrong sequence number will (offset by the IV)
yield a different nonce, leading AEAD decryption to fail.


As said, we didn't consider connection IDs or epochs, but for both I'm wary:

 3) Implicit connection IDs clearly aren't authenticated. I'm not sure I
fully understood the concept, but this sounds like a bad idea.

 4) I slightly disagree with "epochs determine the key" (true) as, what
I understand is, an argument that "the full epoch is implicitly
authenticated by using the right key", at least in its absoluteness. My
*guess* would be that, due to the key schedule, this argument comes down
to the probability of keys colliding (which is anyway to be avoided, so
probably fine). Still, from a security analysis point of view, showing
security with key updates might be easier if the (full) epoch was
authenticated as part of the AAD.


So, overall I guess my tendency would be to authenticate both what's on
the wire and the reconstructed context. At least from a crypto
perspective, this would be the safest bet. But again, this is
extrapolating beyond what our analyses cover, hence just my two cents.

Best,
Felix


[1] Marc Fischlin, Felix Günther, Christian Janson. Robust Channels:
Handling Unreliable Networks in the Record Layers of QUIC and DTLS.
Preprint for QUIPS 2020 Workshop at https://felixguenther.info/Q20_RC.pdf

[2] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
Paterson. Data Is a Stream: Security of Stream-Based Channels.
https://eprint.iacr.org/2017/1191

[3] Christopher Patton, Thomas Shrimpton. Partially Specified Channels:
The TLS 1.3 Record Layer without Elision. https://eprint.iacr.org/2018/634


On 2020-04-27 02:13 +0200, Martin Thomson <[e-mail]> wrote:
> A few of the submissions to QUIPS addressed this question for QUIC (which has a similar construction to DTLS) and concluded that this was broadly OK.  What changes is the degree to which we rely on the strength of the AEAD for prevention of spoofing.
> 
> (I'm sorry, but I can't find the paper that was most directly applicable, perhaps Felix can help out.  https://eprint.iacr.org/2020/114.pdf does a pretty good job, though it is a broader treatment.)