MIME-Version: 1.0
References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com>
 <CAPDSy+7Mqn3fnYhUwGzo5tBNMTiBQeoKMcABQ_pzK-y7AhmipA@mail.gmail.com>
In-Reply-To: <CAPDSy+7Mqn3fnYhUwGzo5tBNMTiBQeoKMcABQ_pzK-y7AhmipA@mail.gmail.com>
From: Nick Harper <nharper@google.com>
Date: Tue, 30 Jun 2020 16:45:11 -0700
Message-ID: <CACdeXiJk3DX=nAZEuBFj5Fd6NGACiPR5V6Cf-ycBWSWYDkH77A@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c46d5105a955c4a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iRLhv2X-Tm8DggecqHENAZ2dpd8>
Subject: Re: [TLS] Proposed change in TLS-Flags
Precedence: list

--000000000000c46d5105a955c4a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This was discussed in the WGLC thread (
https://mailarchive.ietf.org/arch/browse/tls/?gbt=3D1&index=3D973qdoi0PmJbJ=
zNU7Y-eC_a-WaI).
I haven't seen any proposals of when it would be useful for a server to
send a flag unsolicited.

On Tue, Jun 30, 2020 at 4:31 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Hi Yoav,
>
> Could you elaborate on the rationale for this change please?
> I was assuming that the ability for servers to send extensions not
> requested by clients was useful.
>
> Thanks,
> David
>
> On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>> Hi
>>
>> I=E2=80=99ve just submitted the following PR:
>>
>> https://github.com/tlswg/tls-flags/pull/4
>>
>> Three changes:
>>
>>    - It is no longer allowed to send an empty flags extension.  If you
>>    don=E2=80=99t support any flags, don=E2=80=99t send the extension.
>>    - The server is no longer allowed to respond with flag types that the
>>    client didn=E2=80=99t indicate support for first.
>>    - I=E2=80=99ve split the extension description section into a format =
section
>>    and a rules section
>>
>>
>> Please comment. Barring any objections, I=E2=80=99ll merge the PR just b=
efore the
>> submission deadline.
>>
>> Yoav
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--000000000000c46d5105a955c4a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This was discussed in the WGLC thread (<a href=3D"https://=
mailarchive.ietf.org/arch/browse/tls/?gbt=3D1&amp;index=3D973qdoi0PmJbJzNU7=
Y-eC_a-WaI">https://mailarchive.ietf.org/arch/browse/tls/?gbt=3D1&amp;index=
=3D973qdoi0PmJbJzNU7Y-eC_a-WaI</a>). I haven&#39;t seen any proposals of wh=
en it would be useful for a server to send a flag unsolicited.</div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 3=
0, 2020 at 4:31 PM David Schinazi &lt;<a href=3D"mailto:dschinazi.ietf@gmai=
l.com">dschinazi.ietf@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Yoav,<div><br></div><d=
iv>Could you elaborate on the rationale for this change please?</div><div>I=
 was assuming that the ability for servers to send extensions not requested=
 by clients was useful.</div><div><br></div><div>Thanks,</div><div>David</d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir &lt;<a href=3D"mailto:ynir.ietf=
@gmail.com" target=3D"_blank">ynir.ietf@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi<div><br></div><div=
>I=E2=80=99ve just submitted the following PR:</div><div><br></div><div><a =
href=3D"https://github.com/tlswg/tls-flags/pull/4" target=3D"_blank">https:=
//github.com/tlswg/tls-flags/pull/4</a></div><div><br></div><div>Three chan=
ges:</div><div><ul><li>It is no longer allowed to send an empty flags exten=
sion.=C2=A0 If you don=E2=80=99t support any flags, don=E2=80=99t send the =
extension.</li><li>The server is no longer allowed to respond with flag typ=
es that the client didn=E2=80=99t indicate support for first.</li><li>I=E2=
=80=99ve split the extension description section into a format section and =
a rules section</li></ul><div><br></div></div><div>Please comment. Barring =
any objections, I=E2=80=99ll merge the PR just before the submission deadli=
ne.</div><div><br></div><div>Yoav</div><div><br></div></div>_______________=
________________________________<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>
_______________________________________________<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>

--000000000000c46d5105a955c4a7--