Re: [TLS] certificate_request_context

Hannes Tschofenig <> Fri, 07 October 2016 10:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F64F129480 for <>; Fri, 7 Oct 2016 03:30:43 -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 UA581mGCEWQG for <>; Fri, 7 Oct 2016 03:30:41 -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 1E66D1294B1 for <>; Fri, 7 Oct 2016 03:30:40 -0700 (PDT)
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0Lg0sd-1b7Vxu0Qx9-00pb7P; Fri, 07 Oct 2016 12:30:37 +0200
To: Martin Thomson <>
References: <> <> <> <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <>
Date: Fri, 7 Oct 2016 12:30:34 +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="jBNIOSdi1NVVHVjBlifnq9WiwAorDR7JR"
X-Provags-ID: V03:K0:4B0f6f74MWunhZOazFV53bhgIAeGAn6/eZAUCUmBXo/peTXMfPI 8iDGopMTJc8xWW03UyoJtCgDEFkMwuGl3C8+MX76J2vUqmO4CJG14Bl+Arg0yImgmkMQCwy kPPkeTp+NfavJcyY5MyIj2uxZ7whfvOniFke6PCNkQ0PIcAa9Wz/afj5+wKT73/lnvFCY+X KyJezzWYxS9eW4asjwM5Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:QNhfLNO6Yms=:B6KKzzNOK77C/+htvnID2e T3Xq9WJEDwgwbjtzs+b4S7ctOpVIBy+HxU/WwBLtyHYgttYT625Uw3r1FoLMl2rLAHSmK/92e zTBziyJA4+JKgPQ+OZR/ISnt1C4+4hVGSuylioD2JLluWxgyQ1MDYyLs70lKjtbfUknx2uJqd dl+DGX10dAnH7CxfYxE5n0MzwdvCnbkunXH2jYkyr5St30325e3cGxSCkM6cJbzTO4YOwh9x8 +xQHuW4yOFLWI04zWiVMKaJD1LkValDGIHoPGFbb7cvdCzsi7h6d4OVgij9P1qBWd3s2e8gQb LdpJXGnlqDUj6fwAFkXZMOnw5+HE7QMf9q8yHei1xjtI/UwWa0M/ZJvTKjlwv0OKiDs4fut1x EBYWz19kCqJFSDS7Xv9d0R1ycjUpIKe05funvCo5AF+Amd9q0dF+iwlxWbByF3TcTT1J4a0BY BS07QrypZh1oRvuDBpizbYnKE/75EXAPLl1gmlo7dg0Xz9ISruXziGAoUWdpvJrCfRYJ8znBD OjUk3WlicYrOUnNu38QNguZxVfkfLg9vpxQS+s335QFTg2U/szRXWl0EKiowTpyCSTEAaNOjz QqZOhT/4NnHa9035RxSO7hZbGFGA4H3ilBwxINbV8R0/DF8s6y0X8Vz1eUDQdznti/m/DoZoZ yHE7yjpp779usnC9a6DieQdbRY2ZH8h57kw/xm92ruwaPYqlD7Z19lf5HaYyN56L/Fvabl5EP 3EbduBqK00e5kegq4eqZhijcgsaMmcNUliRKZUwWRT1tjl+3H4qMI8rKLao=
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 10:30:43 -0000

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.


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

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...?