Subject: [TLS] Version in record MAC

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Oct 2015 09:28:08 -0700

Folks,

https://github.com/tlswg/tls13-spec/issues/278

The additional data field presently includes the version:

      additional_data = seq_num + TLSPlaintext.record_version

However, TLSPlaintext.record_version is now always {3, 1}, so
this is redundant. There seem to be two primary options here:

     1. Don't MAC the version at all.
     2. MAC the negotiated version (which should be clear at
        this point).

I could go either way on this (slightly leaning towards #2) but
the current thing seems silly.

-Ekr

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 19 Oct 2015 09:39:55 -0700

If (2.) is used, would it be nice to make it  negotiated_version + seq_num?
I think for some algorithms, the MAC can be partially pre-computed if
things are in that order.

On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

-- 
Colm

---

From: David Benjamin <[email-masked]>
Date: Mon, 19 Oct 2015 16:49:01 +0000

What purpose does putting the version in the AD serve? It's not harmful,
sure, but just using the sequence number is simplest. It seems the only
reason we'd consider putting it into the AD is because historically the
record version was in there as part of the record header. In a vacuum, I'm
having a hard time imagining why one would want negotiated_version in there
that wouldn't also apply to putting the whole handshake hash in there. Am I
missing something?

David

On Mon, Oct 19, 2015 at 12:40 PM Colm MacCárthaigh <[email-masked]>
wrote:

>
> If (2.) is used, would it be nice to make it  negotiated_version
> + seq_num? I think for some algorithms, the MAC can be partially
> pre-computed if things are in that order.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Oct 2015 11:06:34 -0700

>      2. MAC the negotiated version (which should be clear at

3. Nothing

The version is implicit in the key derivation (yeah, there are lots of
rounds of HMAC between, but it's there.

The sequence number is fed into the nonce.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Oct 2015 11:12:12 -0700

> The sequence number is fed into the nonce.

How is this different from #1?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Oct 2015 11:13:58 -0700

> How is this different from #1?

#1 implies the sequence number is covered by the MAC.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Oct 2015 11:17:40 -0700

> #1 implies the sequence number is covered by the MAC.

Yeah, I think that's riding the nonce far too hard.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Oct 2015 11:21:33 -0700

> Yeah, I think that's riding the nonce far too hard.

On what basis?  Any change in the nonce will cause the record
decryption to fail.  That's the property we're looking for here, isn't
it?

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Oct 2015 18:24:30 -0400

Option #2 seems fine to me.

Russ

---

From: Adam Langley <[email-masked]>
Date: Mon, 19 Oct 2015 17:46:16 -0700

On Monday, October 19, 2015, Martin Thomson <[email-masked]>
wrote:

> On 19 October 2015 at 11:17, Eric Rescorla <[email-masked] <javascript:;>>
> wrote:

I don't believe that there's any reason to include the sequence number in
the AD input of an AEAD. I think that an empty AD for TLS would be fine now
that the content type is encrypted. (Not that I deeply care either way.)

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 06:32:45 -0700

I'm mostly convinced by this text in RFC 5116:
http://tools.ietf.org/html/rfc5116#section-2.1

   Because the authenticated decryption process
   detects incorrect nonce values, no security failure will result if a
   nonce is incorrectly reconstructed and fed into an authenticated
   decryption operation.  Any nonce reconstruction method will need to
   take into account the possibility of loss or reorder of ciphertexts
  between the encryption and decryption processes.

It would probably be worth checking with the cryptographers in the room.

CCing Hugo and McGrew.

-Ekr

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Thu, 22 Oct 2015 13:59:42 +0000

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 9:33 AM
To: Adam Langley
Cc: Martin Thomson; [email-masked]; Hugo Krawczyk; David McGrew (mcgrew)
Subject: Re: [TLS] Version in record MAC

CCing Hugo and McGrew.

-Ekr

On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley <[email-masked]<mailto:[email-masked]>> wrote:
On Monday, October 19, 2015, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

I don't believe that there's any reason to include the sequence number in the AD input of an AEAD. I think that an empty AD for TLS would be fine now that the content type is encrypted. (Not that I deeply care either way.)

Agreed.  Any value that always goes into the nonce doesn’t need to go into the AD.

David

Cheers

AGL

--
Adam Langley [email-masked]<mailto:[email-masked]> https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 07:07:04 -0700

Thanks for the quick response, David. I now agree with Martin and
Adam that we should remove this.

Chairs, I haven't seen any objections any reason I shouldn't make this
change?

-Ekr

On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) <[email-masked]>
wrote:

>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Thursday, October 22, 2015 9:33 AM
> *To:* Adam Langley
> *Cc:* Martin Thomson; [email-masked]; Hugo Krawczyk; David McGrew (mcgrew)
> *Subject:* Re: [TLS] Version in record MAC
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Oct 2015 08:49:35 -0400

Thinking about this a little more:

If we ever change the nonce construction to have an explicit nonce or
otherwise
not depend on the RSN (e.g., something like SIV) we're going to be sad if
we don't have the RSN in the AD. Obviously, we'd also need to change the
text about the nonce construction, so it's not like you could drop in a
construction
like this, but it would be slightly easier to do if we already MACed the
RSN.

I'm not sure which side of the fence I'm on here. What do others think?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 27 Oct 2015 17:09:15 +0200

> I'm not sure which side of the fence I'm on here. What do others think?

AFAIK, the only case where this would be useful with RFC5116-compliant
ciphers are the ciphers with N_MAX=0, i.e. no nonce. And such ciphers
can't currently be used.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Oct 2015 11:56:48 -0400

> ciphers are the ciphers with N_MAX=0, i.e. no nonce. And such ciphers

Yes, that's correct. But we could relax that restriction and make those work
if we wanted...

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Tue, 27 Oct 2015 11:49:15 -0700

> Yes, that's correct. But we could relax that restriction and make those work

Explicit nonces should not be used in TLS. I'm happy to be building
things without them in mind.

SIV modes, if turned into AEADs, would have to authenticate their
nonces internally. RFC 5297 basically says that already
(https://tools.ietf.org/html/rfc5297#section-3). That might mean that
the nonce is prepended to the AD inside the AEAD abstraction, but that
wouldn't be TLS's concern.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Oct 2015 14:53:56 -0400

Sure. Like I said, I don't feel strongly about this, I just wanted to take
people's
temperature. I'm find with removing the seq from the AD.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Oct 2015 17:33:10 +0900

Per discussion with Sean, I've merged this at:
https://github.com/tlswg/tls13-spec/commit/5f30bca74fdf8ded2bf50b112487ca780faa52ef