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 <m...@lowentropy.net> 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.)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
