Subject: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 30 Jan 2017 21:41:11 +0000

My question: in TLS 1.3, if the client inserts an extension of a type that the server does not recognize, how must the server behave?  Is it required that the server just ignore the extension, or can it take some other action (e.g. ignore the client hello)?

Background (why I'm asking): one of the things we've been doing is seeing how we might retrofit postquantum security into TLS 1.3; I know that the WG does not want to address this now, however I believe it will eventually; ideally, we could later create an RFC on how to do this within TLS 1.3 ( without having to come up with TLS 1.4).

The specific subtask we're looking at is how a postquantum key exchange (and a nonpostquantum one) can be used to generate keys.  Yes, I know that's been proposed before; I just want to make sure that it's actually kosher by the rules of TLS 1.3.  One goal that we have is to be able to have backwards compatibility with TLS 1.3 implementations that don't know about these post-quantum extensions.  One of the things we're looking at is having the client include an extension that would have some of the data; we would set things up so that if the server ignores the extension, the protocol acts "correctly" (that is, if the client and the server are both willing to use the same group, they'll interoperate, if not, then the connection will fail because both sides don't share a group in common).

So, a key requirement of this specific type extension is that the server ignores an extension it doesn't recognize.  We could do it without adding an extension; however that gets rather uglier.

I've been going through the TLS 1.3 draft (draft-ietf-tls-tls13-18), and there doesn't appear to be any MUST statements that says that the server ignores extensions it doesn't recognize.  There's a statement that a client MUST abort if it gets an extension it doesn't expect, but there's no similar language for the server.  Presumably, the server is supposed to be silent about zero length extensions from the client (as the draft states that the client sends a zero length extension for any type that it doesn't need to send, but is willing to receive in reply), however the extensions I'm asking about will not have zero length.

Is it the intension of the WG that the client is able to insert extensions into the client hello that the server might not expect?  If it is, could the next version of the draft insert a MUST statement to that effect?

Thank you.

---

From: Adam Langley <[email-masked]>
Date: Mon, 30 Jan 2017 13:45:26 -0800

On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
<[email-masked]> wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave?  Is it required
> that the server just ignore the extension, or can it take some other action
> (e.g. ignore the client hello)?

The server must ignore unknown extensions.

Cheers

AGL

---

From: David Benjamin <[email-masked]>
Date: Mon, 30 Jan 2017 21:55:51 +0000

On Mon, Jan 30, 2017 at 4:45 PM Adam Langley <[email-masked]> wrote:

Here's a PR to spell this out more explicitly in the text:
https://github.com/tlswg/tls13-spec/pull/868

I could have sworn this was in there already, but apparently not? That or I
can't read.

David