ekr____

8 ms·

61.
by ekr____ 7mo ago
> > The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetui
62.
by ekr____ 7mo ago
This seems like a good place to uplevel. I actually agree with you that in an abstract architectural sense a DNSSEC-style solution for authenticating they keys for endpoints is better. The problem from my perspective is that for a number of
63.
by ekr____ 7mo ago
Ah, I see what you're asking. You're not going to find this answer satisfying, I suspect, but there are two main reasons browsers and big sites (that's what we're talking about) didn't bother to try to make DNSSEC f
64.
by ekr____ 7mo ago
> DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that. 100%. The reasons why are explained in some detail here: https://educatedguesswork.org/
65.
by ekr____ 7mo ago
> > LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/ > > I mean, Mozilla got the ball rolling Among others: Let’s Encrypt was created
66.
by ekr____ 7mo ago
> But if it's worth doing for HTTP, why not for DNS? I'm sorry I don't understand your question.
67.
by ekr____ 7mo ago
Thanks for the explanation. It seems like there are two cases here: 1. Things that use TLS and hence the WebPKI 2. Other things. None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you
68.
by ekr____ 7mo ago
> As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as
69.
by ekr____ 7mo ago
> I'd argue that the only difference is that browser vendors care about protecting against MITM on the client side. They're fine with MITM on the server side or with (potentially state-sponsored) BGP prefix hijacks. And I'
70.
by ekr____ 7mo ago
Can you expand on this a bit, under the assumption that the traffic is using some form of transport security (e.g., TLS, SSH, etc.)?
71.
by ekr____ 7mo ago
I'm not trying to just nitpick you here, but, the message I was responding to said "People stopped caring about ulta-low latency first connect times back in the 90s.". It seems to me that you're saying here that (1) the
72.
by ekr____ 7mo ago
Oh, I was basically agreeing with you. To really nerd out about it, it seems to me there are two metrics. 1. How much it failed (i.e., how low adoption was). 2. How much effort the IETF and others put into selling it. From that perspective,
73.
by ekr____ 7mo ago
> But at least it doesn't have to be a charitable activity covered by non-profits. LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/ Anyway, I
74.
by ekr____ 7mo ago
Fair enough on Multicast and HIP. I'm less sure about the case for PEM. S-HTTP was a bigger failure in absolute terms (I should know!) but it was eventually published as Experimental and the IETF never really pushed it, so I don't
75.
by ekr____ 7mo ago
> In fact, it's failed more comprehensively than any IETF technology ever attempted Now here is where I disagree. Just off the top of my head, how about HIP, IP multicast and PEM?
76.
by ekr____ 7mo ago
It's actually not safe for clients to perform local validation because a quite significant fraction of middleboxes and the like strip out RRSIG and the like or otherwise tamper with the records in such a way that the signatures don&#x2
77.
by ekr____ 7mo ago
> People stopped caring about ulta-low latency first connect times back in the 90s. They did? That's certainly going to be news to the people at Google, Mozilla, Cloudflare, etc. who put enormous amounts of effort into building 0-R
78.
by ekr____ 7mo ago
Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.
79.
by ekr____ 7mo ago
It's not really free, though. Rather, the costs are distributed rather than centralized, but running DNSSEC and keeping it working incurs new operational costs for the domain holders, who need to manage keys and DNSSEC signing, etc. An
80.
by ekr____ 7mo ago
You'll have to judge for yourself whether this demonstrates deep understanding of both arguments, but I did try to be evenhanded in these posts: https://educatedguesswork.org/posts/dns-security-dnssec/ https
81.
Let's build a tool-using agent(educatedguesswork.org)
1 points by ekr____ 7mo ago|0 comments
82.
by ekr____ 7mo ago
Can you elaborate a bit more about what you think the unnecessary complexity here? A basic source of concern here is whether it's safe for the server to use an initial congestion window large enough to handle the entire PQ certificate
83.
by ekr____ 7mo ago
A few points of technical clarification might help here. 1. The reason for a relatively small initial congestion window (cwnd) is to avoid situations where a lot of connections start up and collectively exceed the capacity of the network, c
84.
by ekr____ 8mo ago
Perhaps the same underlying cause, but there's no reason why Google's public CA being temporarily down would bring YouTube down.
85.
by ekr____ 9mo ago
You're arguing with something I'm not saying. I didn't handwave anything away or say it wasn't worth discussing. I simply described how the system was designed.
86.
by ekr____ 9mo ago
The problem with this specific design is that it reveals your identity to the site, which is obviously undesirable from a privacy perspective. For those who are interested one of my recent newsletter posts goes into a fair amount of detail
87.
by ekr____ 9mo ago
I'm not quite sure what you're getting at here. The Google system is tied to a mobile driver's license, and there is an identity check at enrollment that is intended to tie the credential to the device. It's true that if
88.
by ekr____ 9mo ago
In this case the ZKPs are tied to a private key stored in a secure element in the phone, so effectively they are tied to control of the device where the original credential was enrolled.
89.
by ekr____ 9mo ago
See also: https://en.wikipedia.org/wiki/Domesticated_silver_fox
90.
I automatically generated minutes for five years of IETF meetings(educatedguesswork.org)
4 points by ekr____ 9mo ago|0 comments

More ›