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
Precedence: list

--00000000000049cb4905a082ce69
Content-Type: text/plain; charset="UTF-8"

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
>

--00000000000049cb4905a082ce69
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>So it seems like that would add a third class of exte=
nsion:</div><div><br></div><div>1. Required extensions (type=C2=A0+ value),=
 not serialized<br></div><div>2. Required extensions (type only) [&lt;--new=
], serialized as length+value<br></div><div>3. Optional extensions, seriali=
zed as type+length+value<br></div><div><br></div><div>There is some appeal =
to the logical completeness.=C2=A0 The main complication would be serializa=
tion, just because you now have two serialized representations of an extens=
ion, length+value and type+length+value.=C2=A0 You would probably want to s=
erialize in two vectors (one of each type), to avoid switching within the E=
xtension struct, which means that you&#39;d always have two vector lengths =
instead of one, thus at least one byte of wire overhead for having the mech=
anism at all.</div><div><br></div><div>Net/net, I&#39;m not sure the need j=
ustifies the complexity.<br></div><div><br></div><div>--Richard<br></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Tue, Mar 10, 2020 at 12:28 AM Martin Thomson &lt;<a href=3D"mailto:mt@lowe=
ntropy.net">mt@lowentropy.net</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Tue, Mar 10, 2020, at 14:17, Watson Ladd wr=
ote:<br>
&gt; One thing I noticed from my reading is there is no gain from knowing<b=
r>
&gt; an extension will be present if one doesn&#39;t also know the value.<b=
r>
<br>
That is only true if the extension has a value.=C2=A0 (See also flags)<br>
<br>
&gt; I could imagine SNI being very useful to include, and knowing the orde=
r<br>
&gt; of extension values permits their omission, keeping only the length.<b=
r>
<br>
I believe that is the idea: put the extension at a fixed location so that y=
ou don&#39;t have to signal its type, just its value.<br>
<br>
&gt; This does mean very little freedom to add new unknown extensions.<br>
<br>
I don&#39;t think that is necessarily true.<br>
<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div>

--00000000000049cb4905a082ce69--