Re: [TLS] certificate_request_context

Hannes Tschofenig <> Fri, 07 October 2016 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7746F129581 for <>; Fri, 7 Oct 2016 05:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 77RBt7mw-qH6 for <>; Fri, 7 Oct 2016 05:26:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A60CC129579 for <>; Fri, 7 Oct 2016 05:26:11 -0700 (PDT)
Received: from [] ([]) by (mrgmx001) with ESMTPSA (Nemesis) id 0MOf5S-1bmPxO0h1i-0069mR; Fri, 07 Oct 2016 14:26:08 +0200
To: Martin Thomson <>
References: <> <> <> <> <> <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <>
Date: Fri, 07 Oct 2016 14:26:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="tCkUEoUEngbTdsVrrvPJWdA7QbMTQTSc6"
X-Provags-ID: V03:K0:uyGYQsRtH/40Tn2wrDsMvGMiAR7/yuoh+yjzilGJ+eGs8rSxz7S lVrIdE/a4nc9kdqeNZikClyT5ssf4c1VYB4DejhA0pxRfG4XvnD25dXhkNNpKXHg4b1U3rR 2LPsQIb9ZglBvwYbtCC9yeGWG/S0oLT0J6iJY55KCa3ymMnINLqDClh0stUeQw+2IZC1Dkg ioYb8dcozyF8TDhqZ3a0g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dv4FVbLEMwc=:LMs8TEksbxxEaQVUO9j0/i yzkXwZd7SYtB5yKNmmMFl9QQySrHKTTCK2JMxh5gBs6pOqy+vYfOFK1QLNUj70jc4angiVHQy EQdJDQepniaMCKdJ4LdRqwyr/ZHsKYY5UqEwb3QULvLfqP+kcW9jDjyOpnYcj7Vfzq03H65wF CPsK20p2f3YsFVDP10VeIHqDXD90kB3CygHN5KkZe/4Uj+rcs2B+ib857CKKtyF5mLyqpJsPe 6GBbd9ZFIzXwtCdSzPZi7mXMaMlgKHo/QavqLajszBE6Q73PMFCfs0tv08cwTOp4ml4AZb2Pf 4w/g7u4u+Aauig9oJbuPknhmO5IDd+F60dbD5kg0s73u2F7P1l+TD9Mo8/SJzEeC4y9pOUHh1 QkZp0EQrY5lCVufTFalui+WOdeBEU7elfvMVKRtNc2WmuYu8elSVn9KWQK1u599wy4tEjeqjL ERzh+3SSe6zi9tfCHnmt8SqV+kzJ7zTmdxFaO9TfjUwHN12hOmcwtcLHWfTC3pZGcRtcCYB67 GWk2UQ1F6DiwEfLC31eU71xX8WGR/ABzG/vklkmw40IpS0dQDn+ceuMeHBb0tZw5ilGL0/jOy L2EFc5Nc//9/wZ4aht/tfsroTqiQ3ixqp0ipRgsaaB1Iolo58IZvpuC3otgVgbZ0h95VsuIOy wdsCxlGts940y086CfTJsAaxkdiBxDh8pja7AtOtzzdbhMbCVjsh8TAsa0mhQpCgpV6cTaF0E 5cqpDMgY792sY55FKCKQ04eOp04aTcFnxLFFxpmQgtSEZHqpUm8VntfeM7o=
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] certificate_request_context
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Oct 2016 12:26:14 -0000

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!


On 10/07/2016 01:51 PM, Martin Thomson wrote:
> 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?
> On 7 October 2016 at 21:30, Hannes Tschofenig <> wrote:
>> 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
>> we suggest to also apply this concepts to lightweight TLS server
>> implementations.
>> On 10/07/2016 11:59 AM, Martin Thomson wrote:
>>> On 7 October 2016 at 20:45, Hannes Tschofenig <> wrote:
>>>> the problem is that with embedded implementations you need to be
>>>> 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...?