On Tue, 16 Mar 2021, 20:03 Jeremy Harris, wrote:
> On 16/03/2021 07:53, Ben Smyth wrote:
> > Further, is it reasonable for the above first end to
> >> expect the above second end to continue processing and
> >> sending data that would have been sent in the absence of
> >> such a first Close Alert
Oh, that is a good observation.
If the client has the same ServerHello-sensitive preferences (version, key
share, supported groups, cipher suites, PSKs) between inner and outer
ClientHello, it doesn't need to reprocess. But if it has different
preferences, it needs to resolve this circular depende
On Wed, Mar 17, 2021 at 08:15:53AM +0100, Ben Smyth wrote:
> > Do I understand that right? And if so, what is the point of the
> > language in the RFC that appears to permit a half-close?
>
> Specifications don't define systems, they guide design. The specification
> does not "requir[e] an end t
On 17/03/2021 07:15, Ben Smyth wrote:
Perhaps one scenario where that
behaviour is useful: An endpoint is about to be comprimised and raises an
alert to avoid secrets being leaked.
I'd have tout that a section 6.2 Error Alert would be more
appropriate in such a situation, than the (implicitly
n
On Wed, 17 Mar 2021, 15:31 Jeremy Harris, wrote:
> On 17/03/2021 07:15, Ben Smyth wrote:
> > Perhaps one scenario where that
> > behaviour is useful: An endpoint is about to be comprimised and raises an
> > alert to avoid secrets being leaked.
>
> I'd have tout that a section 6.2 Error Alert woul
On 17/03/2021 14:45, Ben Smyth wrote:
Do you at least agree that Google is in violation of the 6.1
wording requiring that it sends a Close Alert before sending
a TCP FIN?
Which aspect of Section 6.1 do you think Google doesn't comply with?
"Each party MUST send a "close_notify" alert before
We've closed out most of the open issues on draft-ietf-dnsop-svcb-https
and it will be going to WGLC shortly.
Current version at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-04.txt
Hopefully we're done, but you can open issues against:
https://github.com/MikeBishop/dns
