Re: [TLS] certificate_request_context

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 07 October 2016 10:30 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64F129480 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 03:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA581mGCEWQG for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 03:30:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E66D1294B1 for <tls@ietf.org>; Fri, 7 Oct 2016 03:30:40 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.121.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lg0sd-1b7Vxu0Qx9-00pb7P; Fri, 07 Oct 2016 12:30:37 +0200
To: Martin Thomson <martin.thomson@gmail.com>
References: <3a6ce7fb-143a-2d67-6682-f221048aed49@gmx.net> <20161007083415.GA8456@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnW3W6vk0AopaEMt=67nR49AHT2N4dgt_YxQkO4f8MUFSQ@mail.gmail.com> <ed519b04-1a6b-e299-596b-9d9f9d8eb419@gmx.net> <CABkgnnX=2g2Th-dR_1MtOvyEhVp9Nhijg2c5YOYfPGaH9EfwTg@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <68427910-70db-5545-5500-2d86517f667a@gmx.net>
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: <CABkgnnX=2g2Th-dR_1MtOvyEhVp9Nhijg2c5YOYfPGaH9EfwTg@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tls/HQ2I758AK_A-38xuBf80-UjM7YM>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] certificate_request_context
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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.

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.

On 10/07/2016 11:59 AM, Martin Thomson wrote:
> On 7 October 2016 at 20:45, Hannes Tschofenig <hannes.tschofenig@gmx.net>; 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...?
>