On Tue, May 07, 2024 at 08:05:05AM -0700, David Benjamin wrote:
>
> draft-ietf-tls-wkech seems like a good model for this, but it is currently
> written specifically for ECH. What are your thoughts on generalizing that
> document to cover other cases as well?
> https://github.com/sftcd/wkesni/issu
Hiya,
On 21/05/2024 08:53, Ilari Liusvaara wrote:
Then there is possibility that IPv4 has gateway but IPv6 is direct-
routed. Then HTTPS entires need to be duplicated with potentially
different alpn values (filtered for IPv4, full for IPv6). HTTP/3
requires IPv6 in such setup (as opposed to not
On Tue, May 21, 2024 at 01:27:29AM +0100, Stephen Farrell wrote:
>
>
> What HTTPS RR parameters do we expect will see regular changes,
> and controlled by whom?
>
> It seems fairly clear that ECHConfig values will be changed
> often, e.g. hourly, which I think motivates the wkech thing,
> but I'm
Hiya,
On 09/05/2024 00:01, David Benjamin wrote:
Actually, I think one thing that could help is one of your drafts! One
barrier with trying to use HTTPS RR for TLS problems is keeping the DNS and
TLS sides in sync on the server deployment. Prior to ECH, this hasn't been
done before, so I would
On Wed, May 8, 2024 at 3:50 PM Watson Ladd wrote:
> On Tue, May 7, 2024 at 8:07 AM David Benjamin
> wrote:
> >
> > [changing the subject since I expect this to mostly be a tangential
> discussion]
> >
> > On Sat, May 4, 2024, 09:12 Stephen Farrell
> wrote:
> >>
> >> I hope, as the WG are proces
On Tue, May 7, 2024 at 8:07 AM David Benjamin wrote:
>
> [changing the subject since I expect this to mostly be a tangential
> discussion]
>
> On Sat, May 4, 2024, 09:12 Stephen Farrell wrote:
>>
>> I hope, as the WG are processing this
>> [draft-davidben-tls-key-share-prediction], we consider
