On Tue, Jun 30, 2020 at 9:10 AM Daniel Migault
wrote:
> Hi Joe,
>
> Thanks for the feed back, please find my responses inline.
>
> Yours,
> Daniel
>
> --
> *From:* Joseph Salowey
> *Sent:* Monday, June 29, 2020 10:01 PM
> *To:* Daniel Migault
> *Cc:* Salz, Rich ; <
More to the point, this makes it more difficult to analyze relative to an empty
"flag" extension of the likes we currently use.
I haven't implemented this, but I imagine one strategy would be to rewrite
these flags and pretend that they were empty extensions. That would allow
implementations
Yeah, the thread that Nick mentioned.
Also, since there are no such extensions defined in the base TLS 1.3 spec, the
server can’t assume that the client knows what either the specific flag means,
or the entire flags extension means.
So suppose we invent some new client authentication scheme
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 wrote:
> Hi
>
> I’ve just submitted the following PR:
>
>
Hi Joe,
Thanks for the feed back, please find my responses inline.
Yours,
Daniel
From: Joseph Salowey
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault
Cc: Salz, Rich ;
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
HI Daniel
Some
Looks good to me.
On Thursday, June 25, 2020 15:32 +04, Kathleen Moriarty
wrote:
> Thank you, Joe.
>
> Sent from my mobile device
>
> > On Jun 25, 2020, at 1:10 AM, Joseph Salowey wrote:
> >
> >
> > Hi All,
> >
> > I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move
