Re: [TLS] I-D Action: draft-rescorla-tls-ctls-04.txt

Richard Barnes <rlb@ipv.sx> Tue, 10 March 2020 16:42 UTC

Return-Path: <rlb@ipv.sx>
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 C1B1B3A0FDC for <tls@ietfa.amsl.com>; Tue, 10 Mar 2020 09:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 3ycFUe6qE4Ux for <tls@ietfa.amsl.com>; Tue, 10 Mar 2020 09:42:32 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 03D6F3A0CDC for <tls@ietf.org>; Tue, 10 Mar 2020 09:42:31 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id e11so13313079qkg.9 for <tls@ietf.org>; Tue, 10 Mar 2020 09:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ilNGAy7X1Aqd3ShUSp71NHNnWMomtovWn8//NIJY/gY=; b=umzKM3YotgRpvmvOamhdlsKyi31VgZCS993Q1FGKmueDN9W+zbEzDz0hRN/83OSnyK CNJT6F+j4DzPv2kpoFnrlE2wLWNU7cmRsXFMS1FsAQdO5KmzH3ZbvaOBUwvKptZjqUAD pNw2jSKj0FsjyXBAwUwWIqD6wIi8zuvqbMVk4zhEULw/sBN9nYNg1aOI0byPgcEX80ZA RhkuWp841dIPBoaFa4GWIQKGhDh2JX2l+PB7qrWJtfqBZNQoJ20jkRLddxzJbOjSslOv /74QcOn2lauSmqOT0b2Z9lUphAxSMop41ttxOg/F3/Tk+od+x4Pn6DqnpNxu7EMZ1jJN ezzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ilNGAy7X1Aqd3ShUSp71NHNnWMomtovWn8//NIJY/gY=; b=O5mRN5rfLXeaW5MeyuRz+J08BaQGpKUM1+gv9Pnjbf/ZtU2ZBYKTdccYc6nOeIreRn e20hHC2mjyRgG4PqlUgNBTRWvX9o4IU2loOFLCT7HP8wezBpvL1KG8I7EmGRZaiJZ0MQ vV9L2tqCcGKZfEuHsDyQED8JuB3ndMUrYowSvjUgqVAswNzGYiy/nzfcm6lXBnuZAwZs BL3GKNF1wwaaAlxvjODffmZ9HDkROoEH3VUXdYENci6M6j/LWQwtIu5SVaSwmFJxTeyv aKww2Uq6ZVsV1oF2W9WudCiOV1PuhnAUUFQ+H4UMOHCrLXY4bwfELg9O2J0NyfgxD9Hm +dCw==
X-Gm-Message-State: ANhLgQ2wZP1jDU/gL5ofSWuvIOSId+4Y74W5dHyvmHwa9WxyPXB0DKzQ xRApri8+7Y9H+BvAuZy8PbgHN8p9MAGosfOsN9WSkwbVpHo=
X-Google-Smtp-Source: ADFU+vvTfsKtras+SEK3KpZkjqo9JPrq6+lJ8NmcdfBHR2hBYWDy21h88+O+YQnp8GyM2JfY0wUJ8WV0zzgo8/FEtAY=
X-Received: by 2002:ae9:e203:: with SMTP id c3mr14046007qkc.132.1583858550681; Tue, 10 Mar 2020 09:42:30 -0700 (PDT)
MIME-Version: 1.0
References: <158378531549.5499.7962303709523423292@ietfa.amsl.com> <CACsn0ckBmDV45LJyigdU++D=xkj7hxhQ-mGmYRH451vASENdTQ@mail.gmail.com> <61637f36-3ecf-40a0-8c9e-c693486cc11f@www.fastmail.com>
In-Reply-To: <61637f36-3ecf-40a0-8c9e-c693486cc11f@www.fastmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 10 Mar 2020 12:42:13 -0400
Message-ID: <CAL02cgTR9NYNxAbBq_nw599o9zo2NLkzOYJj8eijGD5SCQktjw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049cb4905a082ce69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wGyKHKOZNGC9nLJfPjrdBOckttY>
Subject: Re: [TLS] I-D Action: draft-rescorla-tls-ctls-04.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 10 Mar 2020 16:42:34 -0000

So it seems like that would add a third class of extension:

1. Required extensions (type + value), not serialized
2. Required extensions (type only) [<--new], serialized as length+value
3. Optional extensions, serialized as type+length+value

There is some appeal to the logical completeness.  The main complication
would be serialization, just because you now have two serialized
representations of an extension, length+value and type+length+value.  You
would probably want to serialize in two vectors (one of each type), to
avoid switching within the Extension struct, which means that you'd always
have two vector lengths instead of one, thus at least one byte of wire
overhead for having the mechanism at all.

Net/net, I'm not sure the need justifies the complexity.

--Richard

On Tue, Mar 10, 2020 at 12:28 AM Martin Thomson <mt@lowentropy.net> wrote:

> On Tue, Mar 10, 2020, at 14:17, Watson Ladd wrote:
> > One thing I noticed from my reading is there is no gain from knowing
> > an extension will be present if one doesn't also know the value.
>
> That is only true if the extension has a value.  (See also flags)
>
> > I could imagine SNI being very useful to include, and knowing the order
> > of extension values permits their omission, keeping only the length.
>
> I believe that is the idea: put the extension at a fixed location so that
> you don't have to signal its type, just its value.
>
> > This does mean very little freedom to add new unknown extensions.
>
> I don't think that is necessarily true.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>