Re: [TLS] Ignoring unrecognized extensions

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> Matt McCutchen wrote:
> > 
> > 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?
> 
> 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++.

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.

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

   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