Subject: [quicwg/base-drafts] Ben Kaduk's TLS Comment 24 (#4500)

From: Lucas Pardue <[email-masked]>
Date: Tue, 05 Jan 2021 19:00:43 -0800

@kaduk said:
> 
> Section 6.6
> 
>    The usage limits defined in TLS 1.3 exist for protection against
>    attacks on confidentiality and apply to successful applications of
>    AEAD protection.  The integrity protections in authenticated
>    encryption also depend on limiting the number of attempts to forge
>    packets.  TLS achieves this by closing connections after any record
>    fails an authentication check.  In comparison, QUIC ignores any
>    packet that cannot be authenticated, allowing multiple forgery
>    attempts.
> 
> QUIC seems very analogous to DTLS in this regard, and DTLS 1.3 also has
> similar text about AEAD limits for integrity.  Perhaps a brief mention
> that they are essentially the same is useful?
> 
>    For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
>    is 2^23 encrypted packets; see Appendix B.1.  For
>    AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
>    number of possible packets (2^62) and so can be disregarded.  For
>    AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
>    packets; see Appendix B.2.  Applying a limit reduces the probability
>    that an attacker can distinguish the AEAD in use from a random
>    permutation; see [AEBounds], [ROBUST], and [GCM-MU].
>    [...]
>    Note:  These limits were originally calculated using assumptions
>       about the limits on TLS record size.  The maximum size of a TLS
>       record is 2^14 bytes.  In comparison, QUIC packets can be up to
>       2^16 bytes.  However, it is expected that QUIC packets will
>       generally be smaller than TLS records.  Where packets might be
>       larger than 2^14 bytes in length, smaller limits might be needed.
> 
> (This seems to say that we're just reusing the TLS numbers even though
> in theory we do allow larger packets.  But if that's the case, why do
> the actual numbers we present differ from the ones given for DTLS 1.3?
> The actual text in Appendix B suggests that we are not actually reusing
> the TLS numbers (since we use different estimates for l, and
> furthermore, that [GCM-MU] allows larger limits than [AEBounds] as used
> by TLS 1.3).)
> 
>    Any TLS cipher suite that is specified for use with QUIC MUST define
>    limits on the use of the associated AEAD function that preserves
>    margins for confidentiality and integrity.  That is, limits MUST be
>    specified for the number of packets that can be authenticated and for
>    the number of packets that can fail authentication.  Providing a
>    reference to any analysis upon which values are based - and any
>    assumptions used in that analysis - allows limits to be adapted to
>    varying usage conditions.
> 
> DTLS 1.3 imposes essentially the same requirement.  IIUC it would be
> acceptable to use the same limit for DTLS 1.3 and for QUIC, and we
> should perhaps say that if a cipher is allowed for one it is allowed for
> the other (with the same limit), though on second though, we really do
> want the analysis to take into account the different assumptions about
> the number of blocks in a packet..
> 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4500

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Jan 2021 22:55:35 -0800

A few things here...

1. The text in DTLS is a copy of this text, so similarities are no accident.  However, the text has diverged, so drawing an analogy doesn't seem necessary (and I don't want a downref, even if it were informational).
2. The numbers we are using from TLS is the target advantage probability.  QUIC has a larger limit on packet size than TLS has on record size.  Larger sizes affects the limits, which is what you see there.
3. The note you quote is old and it should have been removed when we changed the numbers.
4. As noted the analysis for DTLS would be helpful, but not definitive.  As you say, the number of blocks in a packet can have an effect (though not for ChaCha20Poly1305 apparently).

So l've a PR for the note, but I don't see any other action here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4500#issuecomment-755121519

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Jan 2021 09:03:01 -0800

Closed #4500 via #4578.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4500#event-4180813782

---

From: kaduk <[email-masked]>
Date: Sat, 09 Jan 2021 19:56:50 -0800

> So l've a PR for the note, but I don't see any other action here.

I have an action item (to pester the DTLS 1.3 authors to reduce the divergence), but I agree there's no other action for this document.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4500#issuecomment-757410202