Subject: Re: [TLS] Choice of Additional Data Computation

From: Hanno Becker <[email-masked]>
Date: Fri, 1 May 2020 09:41:13 +0000

> > (*): Even if we optimize the CID away with cTLS the question about the
> > security implications will surface again.

> I think that cTLS is the answer to the size issue.  But there, the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack, so we > might be able to send without a CID, but re-insert the value before processing.  As the canonical form, DTLS always including the value seems fine to me.

On: "the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack"

I fully agree, and whether true or not, that's the reason why so far I thought that an AEAD that's agnostic of compression techniques
and operates as-if there's always a full header on the wire, is more robust than what we have at the moment.

Regarding re-introducing the explicit CID in DTLS 1.3: My impression so far was that DTLS 1.3 attempts to already
incorporate some record compression ideas through the flexible header format, and I'd find it cleaner to either explore
and use those ideas fully (including implicit CIDs, for example), or leave them for c[D]TLS entirely and stick to a single
header format for DTLS 1.3. But that's subjective.

Apart from that, thanks Martin for sharing the paper https://felixguenther.info/Q20_RC.pdf in the other thread,
I think it might be useful for this thread, too.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Felix Günther <[email-masked]>
Date: Tue, 5 May 2020 19:44:53 +0200

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 <[email-masked]> 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.)

---

From: Hanno Becker <[email-masked]>
Date: Wed, 6 May 2020 06:00:30 +0000

Hi Felix,

Thanks for chiming in!

> sequence number, length, connection ID, ... -- what else?

Perhaps version and content type, though at least the latter is fixed.

> on-the-wire header (as the latter may be compressed in different ways).

Yes.

> the on-the-wire header, which I don't expect is intended.

Can we go a bit into this? As mentioned in the original thread
https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
there are some (arguable) considerations of why it has practical benefits
to not cryptographically bind the header _format_ to the record.

Those considerations, however, are secondary to security considerations,
so they didn't surface here so far.

Could we therefore clarify:

Are there any _security_ concerns arising from the modifiability of the
header format assuming the underlying pseudo-header is bound via AEAD?

I don't see one so far, but might miss something. In my head, once the logical
data is authenticated, the entire on-the-wire header merely degrades to a 'hint'
to the receiver as to what the logical header data is, the precise form of which
is entirely irrelevant.

_If_ there are no security concerns (and only then), I'd like to bring up those secondary
considerations from https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
regarding modularity, efficiency and flexibility again, arguing in favor of purely logical AEAD
omitting the wire-format.

> yield a different nonce, leading AEAD decryption to fail.

Would you expect a change in proof complexity when switching
to explicit length and sequence number authentication in the AEAD?

> authenticated as part of the AAD.

Yes, that matches my thinking above - it's probably practically fine, but
a formal argument gets more complex without explicit epoch authentication
because it involves the mapping { epoch id } -> { keys }.

Regards,
Hanno

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 May 2020 13:04:37 -0700

> authenticated as part of the AAD.

Actually, the full epoch is included in the overall sequence number and
hence used to generate the nonce.

https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4

Does that help?

-Ekr

---

From: Felix Günther <[email-masked]>
Date: Sat, 16 May 2020 11:53:35 +0200

Hi,

> https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4

Sorry, I forgot about reading this difference in how the record sequence
number is constructed in DTLS (vs. TLS, and also QUIC). Yes, this should
effectively separate the nonce spaces between the different epochs /
epoch keys, and implicitly authenticate the epoch through the nonce.

Cheers,
Felix

---

From: Hanno Becker <[email-masked]>
Date: Sun, 17 May 2020 05:35:28 +0000

> Actually, the full epoch is included in the overall sequence number and hence used to generate the nonce.

Good point Ekr, I missed that.

So, we're here at the moment:
(1) Only the CID issue really _needs_ fixing somehow.
(2) Other header fields are currently authenticated through a mixture of AAD, nonce, and implicit properties of the AEAD,
and proof complexity doesn't seem to grow significantly because of that non-uniformity (the latter was slightly in doubt
so far for epoch authentication, but Ekr's remark clarifies that it isn't actually the case).
(3) No security issues with the proposed alternative -- uniformly pseudo-header based AAD -- have been raised yet.
(4) Non-security arguments for a pseudo-header AAD have been proposed, e.g. network bandwidth reduction.
Those aren't discussed until the question of security reaches some clarity.

Felix, could you give some input on (3) as detailed in my last post?

We still need to change _something_ to address (1), the pseudo-header approach does so while bringing other
advantages, and no concrete security have been pointed out so far. So, once again:

Are there objections in terms of security towards the (purely) pseudo-header AAD?

Cheers,
Hanno

________________________________
From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Friday, May 15, 2020 9:04 PM
To: Felix Günther <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Choice of Additional Data Computation

On Tue, May 5, 2020 at 10:55 AM Felix Günther <[email-masked]<mailto:[email-masked]>> wrote:

Does that help?

-Ekr

---

From: Felix Günther <[email-masked]>
Date: Mon, 18 May 2020 08:37:01 +0200

Hi,

> header format assuming the underlying pseudo-header is bound via AEAD?

This will depend on what security you want to aim at. Clearly, if
non-malleability of headers is a goal, then yes.

More generally, cryptographic models of secure communication channels
would carve out "a ciphertext" (in quotes, as its not only the AEAD
ciphertext) from the spec. Now, it's always a modeling choice what this
ciphertext should include. A reasonable and natural choice for DTLS
would be to include the full on-the-wire header. Integrity would then
require that any modification of that header leads to the ciphertext
being rejected.
At the minimum, one would need to include all cryptographically relevant
information (esp. epoch, sequence number) enabling decryption, but then
singling those out from the wire format feels a little odd.

Hence, I would say that a natural cryptographic security notion most
likely suggests full on-the-wire header authentication. But again, it
all comes down to what's the goal.

> to the receiver as to what the logical header data is, the precise form

This depends on the perspective. For analyzing channel security, it is
often conceptually easier to follow a modular approach that combines
confidentiality under passive attacks (usually straightforward) and
integrity of ciphertexts under active attacks. The latter means: no
modification of the ciphertext on the wire is permitted (in contrast to
plaintext integrity, demanding only that no modifications to the payload
can be made). This argument hence indeed relies on headers not being
malleable.

Our security analysis [1] for example models that the decision logic of
whether receiver should be accepting a certain next packet must be
decidable from the transcript of sent and received packets so far
(publicly, without internal keys or state).
Whether this would still work with a malleable 'hint' to the logical
header I don't know. Not saying this can't work, but our analysis
doesn't speak to that.

> to explicit length and sequence number authentication in the AEAD?

Length: no.
Sequence number (and epoch): only minor, as it merely obviates one level
of indirection (authentication via the nonce input).

Cheers,
Felix

---

From: Felix Günther <[email-masked]>
Date: Mon, 18 May 2020 08:37:36 +0200

Hi,

On 2020-05-17 07:35 +0200, Hanno Becker <[email-masked]> wrote:
> (2) Other header fields are currently authenticated through a mixture of
> AAD, nonce, and implicit properties of the AEAD,
> and proof complexity doesn't seem to grow significantly because of that
> non-uniformity (the latter was slightly in doubt
> (3) No security issues with the proposed alternative -- uniformly
> pseudo-header based AAD -- have been raised yet.

Our security analysis doesn't speak to (3) --- I added some more
detailed remarks in reply to your last post. Cearly, you wouldn't
achieve the same security definition (as headers are intentionally
malleable). Whether that's a problem or not depends on the goal, and if
you can indeed prove the corresponding, to-be-formalized security
statements.

Cheers,
Felix