Subject: [TLS] Ignoring unrecognized extensions

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Jun 2010 13:27:39 -0400

Dear TLS group,

I think it is the intent of RFC 5246 that a TLS server, in addition to
tolerating an "extensions" field in the ClientHello that is nonempty as
a whole, MUST ignore individual extensions that it does not recognize.
However, I cannot find this stated anywhere in RFC 5246.  Am I missing
something?  Would this be worthy of an erratum?

-- 
Thanks,
Matt

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 22 Jun 2010 11:23:52 -0700

> something?  Would this be worthy of an erratum?

That is indeed how extensions are supposed to work.  If a server does
not recognize a particular extension it ignores it.  The server hello
will not contain a response, so the client then has the option to abort
or to continue the handshake without the use of the behavior defined by
that extension.

I don't know if there's still time to sneak this into RFC 4366++.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Jun 2010 21:09:24 +0200 (MEST)

> something?  Would this be worthy of an erratum?

My copy of rfc-5746, section 3.6 says this in the second last paragraph:

http://tools.ietf.org/html/rfc5746#section-3.6

   TLS servers implementing this specification MUST ignore any unknown
   extensions offered by the client and they MUST accept version numbers
   higher than their highest version number and negotiate the highest
   common version.  These two requirements reiterate preexisting
   requirements in RFC 5246 and are merely stated here in the interest
   of forward compatibility.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Jun 2010 15:12:52 -0400

>    of forward compatibility.

I saw that.  My point is that I can't find the preexisting requirements
in RFC 5246 that are being reiterated.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Jun 2010 21:25:52 +0200 (MEST)

> in RFC 5246 that are being reiterated.

It contains a similar hint, but in a non-obvious location:

http://tools.ietf.org/html/rfc-5246#page-47

   Note: this extension is not meaningful for TLS versions prior to 1.2.
   Clients MUST NOT offer it if they are offering prior versions.
!  However, even if clients do offer it, the rules specified in [TLSEXT]
!  require servers to ignore extensions they do not understand.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Jun 2010 22:01:59 +0200 (MEST)

> I don't know if there's still time to sneak this into RFC 4366++.

You mean

 https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4366-bis/

The existing text that I read to imply this is in Section-1.1 on page 5:

   TLS clients and servers may use the extensions described in this
   document. The extensions are designed to be backwards compatible,
   meaning that TLS clients that support the extensions can talk to TLS
   servers that do not support the extensions, and vice versa.

The wording in rfc-5246, section 7.4.1.4.1 and similarly
rfc-5746, section 3.6 might be clearer.

 http://tools.ietf.org/html/rfc5246#page-47

   The rules specified in [TLSEXT] require servers to ignore extensions
   they do not understand.

   TLS servers MUST ignore any unknown extensions offered by the client.

Curiously rfc-5246 uses a dangling [TLSEXT] reference; maybe it should
have refered to RFC4366 instead -- is the updated TLSEXT draft already
2 years behind schedule?

>From the URL above, the I-D appears to be still with the IESG.
Such a wording clarification, when considered adequate, could
be applied during AUTH48, I suppose.

-Martin