On Thu 2021-12-16 10:37:53 -0800, Ben Schwartz wrote:
> In my view, a correct implementation here would simply provide the TLS
> stack with an IP address and no validation identity, so there is no
> way for the TLS stack to retrieve an ECHConfig.
That would be a reasonable implementation, for
Hi Ben--
On Mon 2021-12-13 08:34:22 -0800, Ben Schwartz wrote:
> The terminology section says
>
>* "unilateral" means capable of opportunistic probing deployment
> without external coordination with any of the other parties
>
> To my eye, that excludes any way of delivering ECHConfigs,
On Fri, Dec 10, 2021 at 5:03 PM Daniel Kahn Gillmor
wrote:
> Hi Ben--
>
> Thanks for the prompt review and feedback!
>
> On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote:
> > The SNI guidance looks good to me.
> >
> > I find it confusing to mention ECH in this draft. ECH can never be used
>
Hi Ben--
Thanks for the prompt review and feedback!
On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote:
> The SNI guidance looks good to me.
>
> I find it confusing to mention ECH in this draft. ECH can never be used
> with this specification, because there is (by definition) no SVCB record
The SNI guidance looks good to me.
I find it confusing to mention ECH in this draft. ECH can never be used
with this specification, because there is (by definition) no SVCB record to
provide the ECH keys. (If there is a SVCB record in play, then we are no
longer in "unilateral probing".)
I did
Hi dprive,
Here's a list of changes introduced in version -01 regarding the use of SNI:
- SNI guidance for authoritative servers on two scenarios;
- using SNI for alternate server credentials
- serving different records based on SNI
- SNI guidance for recursive resolvers
