Re: [TLS] certificate_request_context

Martin Thomson <martin.thomson@gmail.com> Fri, 07 October 2016 11:51 UTC

Return-Path: <martin.thomson@gmail.com>
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 9A50B12950A for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 04:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PB-1tZosZMcL for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 04:51:48 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5D5129481 for <tls@ietf.org>; Fri, 7 Oct 2016 04:51:48 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id z190so28121843qkc.2 for <tls@ietf.org>; Fri, 07 Oct 2016 04:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yYdKvY2Kqgl6t+CGo6aeoeqtGXZy7QP7oLDxWxwL3zI=; b=E2c0rmhvZj0YYCPpA4pTgM+QFeT7m9+e4C9PInV/M5M43TL7PgWp3X/6QcX8dcQQfy rZCGVjebvSisgHnjWdzLO4U0RSWZFZwXaoOaSbOckmII07VxMJVq5rwttVZ92XHv/MwO 28ctvBa8yCYTqjNgtT1PG5s6x8RRvfPwW/c76IZqBdlL7W2Te7tznBp1glv34tegwfGy 80gd9uZg30FW4vb6XPQbuMAmXjDuzh+rg/YM5S+d3l9kfRD08GLVsRN9rZyw09e8cRgc bppwT8sA4DARCkjEQAguXhoZ9KRWJKoZESyUJK58Af86VWaLI9Wr5eLFQ1UdNSY0s+QA lErw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yYdKvY2Kqgl6t+CGo6aeoeqtGXZy7QP7oLDxWxwL3zI=; b=kyN3isEZ33R6ait5S0+DJujMFmeeT9d8ksWbsogwHB41otQoS8pRo/Xj5A6tBMrdQf hDjmIuREahvsdXa/aXARbeOnyZkT0gPN6nnAsh0sQL/z91Fle1EA6mErr7znMX5Lf6EF C4oU07rY3KvQD0ppLfcft8AGPVRfGn2qxad4jif5u1XMlqjhKmLwyrUDFrlGLyQ0hpee 82zoEa/Pmo6yZD8GGWE/RZryp+S3nXrVLQZX69WzWVcpJ76gKysrellS2FpmN/Ld3gLu 8Fb7Xx2y/W5unPLVFC+u+EcW9WOhslVW5sEAzrY5GMqNbDbhegnrzMWyI19OD7+8fsQ7 Zbqw==
X-Gm-Message-State: AA6/9RmMkotOKwPEoej151hKTbXjXve5X2o5OmRDCxbJbgV41/6mFwakELtwLQOWmSncOIBjca2ycX1HWLDO/Q==
X-Received: by 10.55.71.3 with SMTP id u3mr14052063qka.144.1475841107223; Fri, 07 Oct 2016 04:51:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Fri, 7 Oct 2016 04:51:46 -0700 (PDT)
In-Reply-To: <68427910-70db-5545-5500-2d86517f667a@gmx.net>
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> <68427910-70db-5545-5500-2d86517f667a@gmx.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 07 Oct 2016 22:51:46 +1100
Message-ID: <CABkgnnV5dxVyoZqOyXcGjC6an5dDmwU+OXJyNevb7AP0QpfC2A@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sCYLnd5O_TK0skUHUTz5oCOpWqU>
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 11:51:49 -0000

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 <hannes.tschofenig@gmx.net> 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
> 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...?
>>
>