Subject: Re: [TLS] Integrity bounds in DTLS

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 May 2020 17:12:04 +1000

On Fri, May 1, 2020, at 14:51, Martin Thomson wrote:
> Thanks to some good work from Felix Günther, Marc Fischlin, Christian 
> Janson, and Kenny Paterson we now have a new result to share about the 
> integrity limits in QUIC.
> 
> There is a long write-up in 
> https://github.com/quicwg/base-drafts/issues/3619, the conclusion of 
> which is that endpoints need to count the number of failed decryptions 
> and stop using keys once a certain limit is reached.  Key updates can 
> be used to avoid this.
> 
> The same concern applies to DTLS.  I believe that the same solution - 
> or at least a similar solution - is therefore necessary for DTLS.
> 
> I know that we're past WGLC, but this is an important result regarding 
> a key distinction between TLS and DTLS.

News here is that we resolved some issues with AEAD_AES_128_CCM.

For TLS, we need to resolve what to do with AEAD_AES_128_CCM_8.  For those who don't want to read a long issue, the number of forgery attempts permitted has to be less than 2^6 to keep the same bounds as other ciphers.  That's not very useful.  TLS_AES_128_CCM_8_SHA256 is already a non-recommended cipher, so we're good there.  But it might still be good to have some parameters for it, even if it is guarded with some warning labels about differences in security margins.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 May 2020 10:51:06 +1000

Continuing the trend where I am the only one to post to this thread...

I just posted a proposal:

https://github.com/tlswg/dtls13-spec/pull/147

This is essentially a transcription of the work done for QUIC to DTLS.  There is one major change, in the addition of TLS_AES_128_CCM_8_SHA256.  QUIC prohibits the use of this cipher suite, so it doesn't have to worry about it.  The proposed text does not define limits for this cipher, essentially suggesting that it's not good for general use.

My personal conclusion is that this suite is fine for use in TLS, but unless we dramatically revise our expectations, it's no good for DTLS.  To that end, I'd be happier prohibiting the use of this cipher suite outright in DTLS.  I didn't put that in the proposal as I believe that would be counter to our established position, which is that this is not generally recommended, but it might have specialized uses in which it is OK.  The proposal therefore attempts to hedge by saying that you need special circumstances and further analysis before using it.

So I see two paths and one maybe option:

1. Prohibit use of TLS_AES_128_CCM_8_SHA256 in DTLS.
2. Allow TLS_AES_128_CCM_8_SHA256 in DTLS under special circumstances (the PR).
3. An unspecified proposal that allows TLS_AES_128_CCM_8_SHA256 more generally somehow.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 15 May 2020 10:29:00 +0000

> https://github.com/tlswg/dtls13-spec/pull/147

Looks good, thanks!

While the specific behaviours might more or less differ, the same
considerations apply to 1.2.  How do we make sure that the message
doesn't get ignored?  Would it be worth drafting this separately to
cover both versions (+ an explicit "Updates: 6347" label)?

> 3. An unspecified proposal that allows TLS_AES_128_CCM_8_SHA256 more

While I'd personally prefer path 1, I think we need to factor in
existing deployments somehow.

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: "Martin Thomson" <[email-masked]>
Date: Mon, 18 May 2020 10:46:51 +1000

> cover both versions (+ an explicit "Updates: 6347" label)?

We're already marking TLS 1.2 obsolete with this, so I don't think that labels are going to change.

The question is whether it is clear that these limits apply to the use of AEADs in TLS more generally.  I think that is clear enough, but I doubt that people will pay any mind unless they are implementing TLS 1.3.

The problem with TLS 1.2 is that there is no option for key updates, unless you count renegotiation, which is often disabled.  When I added limits to NSS, all I could reliably do was make the connection terminate if the limit was hit (which is why the limits used are larger than advised in the spec).

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 19 May 2020 10:50:41 +0000

On 18/05/2020, 01:47, "Martin Thomson" <[email-masked]> wrote:
> The question is whether it is clear that these limits apply to the use
> of AEADs in TLS more generally.  I think that is clear enough, but I
> doubt that people will pay any mind unless they are implementing TLS
> 1.3.

Yes, that's exactly my original point.  I'd like to maximise the chance
that the message doesn't get ignored: we have 1.2 deployments around
that are not likely to be forklifted to 1.3 soon and will have to
make them aware of the risk nonetheless.

> The problem with TLS 1.2 is that there is no option for key updates,
> unless you count renegotiation, which is often disabled.  When I added
> limits to NSS, all I could reliably do was make the connection
> terminate if the limit was hit (which is why the limits used are
> larger than advised in the spec).

Sure, protocol version as well as stack specific reactions will differ.

I guess my question is whether, to maximise coverage/visibility, it
makes sense to state the general problem together with version specific
behaviours in a separate doc?