Subject: [TLS] certificate_request_context

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 7 Oct 2016 09:48:32 +0200

Hi all,

I am wondering why the certificate_request_context field found in the
CertificateRequest and in the Certificate message is so long. It is
supposed to be used to match a certificate request against incoming
certificate.

Does the field really need to be up to 256 bytes long? I think 8 bytes
should be more than enough.

I would also like to suggest to change the definition of
certificate_request_context:

Here is the current text since the last sentence feels misleading:

"
certificate_request_context

An opaque string which identifies the certificate request and which will
be echoed in the client’s Certificate message. The
certificate_request_context MUST be unique within the scope of this
connection (thus preventing replay of client CertificateVerify
messages). Within the handshake, this field MUST be empty.
"

"
certificate_request_context

An opaque string which identifies the certificate request and which will
be echoed in the client’s Certificate message. The
certificate_request_context MUST be unique within the scope of this
connection (thus preventing replay of client CertificateVerify
messages). This field SHALL be zero length unless used for
post-handshake authentication described in Section 4.5.2.
"

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Oct 2016 11:34:16 +0300

> should be more than enough.

I presume 255, but whatever...

If application supports any sort of multiplexing (e.g. HTTP/2), one
presumably wants the context to be non-opaque and identify the stream
that caused the request + some parameters about the request (to avoid
duplicating those in application layer).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Oct 2016 19:59:43 +1100

> duplicating those in application layer).

It's opaque to TLS.  And 255 simply establishes the number of octets
in the length (1), if you don't need that much context (few will even
if they implement this), don't use the extra space.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 7 Oct 2016 11:45:07 +0200

Hi Martin,

the problem is that with embedded implementations you need to be
prepared to receive this amount of data when the specification says so.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Oct 2016 20:59:34 +1100

> prepared to receive this amount of data when the specification says so.

How are you managing 65k session tickets, extensions, cipher suite
lists, supported group lists, etc...?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 7 Oct 2016 12:30:34 +0200

Hi Martin,

this may be an implementation specific issue but some of the parameters
I have to keep in memory while others I "only" have to parse. In some
cases the embedded implementation also has control over the number of
parameters being included in a message (which is useful for bandwidth
reasons as well).

Ideally, I would prefer to have the length of a field somehow relate to
the content.

Going through all the parameters and re-evaluating whether the size is
indeed appropriate might be a good idea.

Ciao
Hannes

PS: For the reason that embedded devices don't have an endless amount of
RAM the max_fragment_length extension was introduced and in
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00
we suggest to also apply this concepts to lightweight TLS server
implementations.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Oct 2016 22:51:46 +1100

I don't think it would be sensible to set an upper limit in this case
(those lead to regrets in my experience), however, recommending that
the value be kept as small as possible seems OK.  It's probably
redundant advice though.

Since this is extremely transitory state, I sort-of assumed that it
would be OK. And it's zero-length during the handshake.  Were you
planning on having super-constrained devices with post-handshake auth
support?

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 7 Oct 2016 14:26:05 +0200

Hi Martin,

post-handshake authentication is indeed probably something that is less
likely to happen in the embedded environment and I will check whether
there are some use cases that require it.

If it isn't required then the best possible alternative at the moment is
for an embedded client implementation to immediately return a
Certificate message containing no certificates followed by Finished.

Thanks for your thoughts on this topic!

Ciao
Hannes