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 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
I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
less sure about addressing the basic insecurity of the DNS channel with the
approach this draft takes. I don't have a complete thought here, but what
if we were to somehow fold the hint into the handshake transcript? I
suppose
Off the cuff, folding it into the transcript sounds tricky, since existing
TLS servers won't know to do it, and, as with any other DNS hints, we need
to accommodate the DNS being out of sync with the server. It'll also be
more difficult to deploy due to needing changes in the TLS stack and
generall
In my opinion, to prevent downgrade attack, server MUST or SHOULD using DNSSEC when announcing DNS record.21.05.2024, 21:48, "David Benjamin" :Off the cuff, folding it into the transcript sounds tricky, since existing TLS servers won't know to do it, and, as with any other DNS hints, we need to acc
Servers using DNSSEC won't help unless the client only honors the hint over
DNSSEC, and we do not live in a universe where DNSSEC succeeded to the
point that that's remotely viable.
I think that too can be discussed in detail post adoption, but I think such
a change would negate the value of this
Thank you for your comments.
Since I hadn't received any feedback, I shifted my focus to other issues and
needed some time to revisit this topic.
I've realized that CIDs in DTLS 1.3 are loosely defined, and the more I
investigate, the more I understand that this is actually very beneficial, muc
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
(replies inline)
On Sun, May 5, 2024 at 6:48 PM Dennis Jackson wrote:
> Hi David, Devon, Bob,
>
> I feel much of your response talks past the issue that was raised at IETF
> 118.
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root cert
Hi Richard. Thanks for the comments! Replies inline.
On Mon, May 6, 2024 at 10:23 AM Richard Barnes wrote:
> Hi all,
>
> Coming in late here. Appreciate the discussion so far. FWIW, here's how
> I'm thinking through this:
>
> I would frame the basic problem here as follows, since I think the u
On Mon, May 20, 2024 at 7:26 AM Dennis Jackson wrote:
> Compared to the alternatives, Trust Expressions seems to solve the
> problems less effectively and introduce much greater risks. If you really
> feel the opposite is true, I would strongly encourage you to:
> b) Make a good faith attempt to
These are all fair points, and it's possible we don't need to do anything
with the transcript.
I don't think we need to resolve this before adoption, I just wanted to
make sure that I said something now to make sure people weren't surprised
later.
-Ekr
On Tue, May 21, 2024 at 6:46 AM David Benj
Hiya,
A slightly meta comment:
On 21/05/2024 19:05, Nick Harper wrote:
From a process perspective, considering how a technology could be abused is
important and should be addressed to a reasonable level in the RFC. I don't
see a need for this to be fully fleshed out with every possible abus
Hi Nick,
On 21/05/2024 19:05, Nick Harper wrote:
[...]
Perhaps there are additional ways to use Trust Expressions to censor
the web that are more practical and more useful than the existing
techniques that I didn't consider. There are most certainly other
forms of domestic control of the Web
There is consensus to adopt this draft as a working group item. I'll work
with the authors to migrate to the official repository and submit an
updated draft.
On Tue, May 21, 2024 at 11:23 AM Eric Rescorla wrote:
> These are all fair points, and it's possible we don't need to do anything
> with
The TLS WG has placed draft-davidben-tls-trust-expr in state
Candidate for WG Adoption (entered by Joseph Salowey)
The document is available at
https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
___
TLS mailing list -- tls@ietf.org
To uns
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson wrote:
> This thread is now 40+ messages deep and I guess you might have not seen
> much of the previous discussion. I actually agree with much of your
> analysis, but it focused on the wrong question, as I wrote earlier in this
> thread:
>
> The que
17 matches
Mail list logo
