On Thu, Apr 22, 2021, at 02:31, Michael Thomas wrote:
On 4/20/21 7:46 PM, Bron Gondwana wrote:there's a whole fallacy somewhere which I've had to address a few times already in my own working groups, but which I still commonly see, along the lines of "big companies have masses of resources and hence can easily run experiments or implement arbitrary ideas - and have an obligation to do so when requested/demanded". They don't, you have to persuade them just as much as anyone else, plus they're slower to move and harder to persuade.I wasn't making any such assumption, just pointing out that it was well within the capability of a Google-like company to run an experiment.
Potato, potato. You're assuming they have the capability based on their size, not on knowledge of how the teams are structured or what their incentives are, which is my point - why would they want to do this for you? Why are you entitled to their time and their effort to run the experiment for you?
- Because Google is big?
- Because your technical argument is compelling?
- Some other reason that I missed?
Instead I got told that signing their zone is apparently "boiling the ocean" which to me is astonishing. If you take that at face value, that is a stunning indictment of DNSSec.
It sounds like a conversation that's worth having with those who have tried DNSSec and given up, or decided not to try to use it. The fact that you're astonished by their response is a good clue that maybe there's something interesting here.
Personally, I'm right in there with indictments on DNSSec in general. I didn't write this, but I stand by it:
Rob wrote "DNSSEC is fragile and easy to get wrong in subtle ways." I say that DNSSEC is operational poison - it's hard to get right, easy to get wrong, and most importantly hard to debug failures when it happens - your users aren't going to be able to report the cause. It's theoretically good tech, but it clearly isn't getting traction and berating those who choose not to use it doesn't help.
Chrome already did the DANE work once upon a time so DNSSec is the only missing piece. But the very thought that the number of packets exchanged in a transport protocol's setup is *off topic* within 24 hours and a few messages back and forth speaks miles about how broken many working groups are and why nobody wants to participate.
You seem very focused on this "number of packets" idea. Lower number of packets is nice, but only if the tradeoffs are worth it. Discarding all the existing progress to restart from scratch with a new design is a pretty high cost and clearly those working on QUIC aren't that keen. I didn't see anybody jump in that thread and say "hey, I'd also like to discuss this".
And if it makes everything more fragile, that's a downside too. DNSSEC makes things fragile based on the number of big name sites that screw it up every year. It also makes it much more expensive - DNSSEC is hard to get right and hard to keep right.
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
