Marco Schmidt - 2023-05-23 13:56:57
Hello, I'm Marco from the RIPE NCC. This chat panel is meant for discussion ONLY. If you have questions for the speaker and you want the session chair to read it out, please write it in the Q&A window also stating your affiliation. Otherwise, you can ask questions using the microphone icon.
Please note that all chat transcripts will be archived and made available to the public on https://ripe86.ripe.net/.
The RIPE Code of Conduct: https://www.ripe.net/publications/docs/ripe-766
Georg Kahest - 2023-05-23 14:22:02
nice finding @enumerated interfaces....
Iljitsch van Beijnum - 2023-05-23 14:41:10
Short TTLs are also problematic: when a DNS server is taken out by a DDoS (and DNS and DDoS meet often) then with a short TTL your service disappears much quicker.
Shane Kerr - 2023-05-23 14:41:42
Tell us the correct TTL, Iljitsch! ;-)
Iljitsch van Beijnum - 2023-05-23 14:42:44
5 minutes is definitely too small
Shane Kerr - 2023-05-23 14:43:20
Fair enough.
Éric Vyncke - 2023-05-23 14:43:25
What about 300 seconds ? (it seems larger :sweat_smile: )
Shane Kerr - 2023-05-23 14:43:53
So... TLS took ages before it got adoption? Does that mean TLS was not worth it, or had an improper threat model?
Iljitsch van Beijnum - 2023-05-23 14:44:12
BTW, there have been some crypto currency theft incidents with a trifecta of BGP hijack, DNS imposter and TLS bypass (carless user? not sure). With DNSSEC those people would still have their etherium. So perhaps they should sue the wallet people for not using DNSSEC.
Iljitsch van Beijnum - 2023-05-23 14:44:55
I believe SSL took off fairly quickly.
Shane Kerr - 2023-05-23 14:48:25
In my mind, TLS had a broken _business model_. Or rather, reliance on capitalism to solve all problems was a bad idea. The socialist approach - Let's Encrypt - has brought us more security, and basically a better world.
Iljitsch van Beijnum - 2023-05-23 14:49:59
I think Geoff is saying that because DNSSEC sucks we need to use another protocol which is actually built on top of DNSSEC...
Shane Kerr - 2023-05-23 14:50:30
About half the time he just ends with "and everything sucks, I'm glad it's not my job to fix it". :satisfied:
Martin Pels - 2023-05-23 14:51:10
@Shane. Google ranks TLS-enabled sites higher in search. that's a pretty capitalist incentive.
Iljitsch van Beijnum - 2023-05-23 14:51:36
The IETF (with Geoff in it) attempts quite a lot of fixing. Then people don't bother to apply the fixes. But don't stop complaining. I see no way to fix _that_.
Eva Lauren Kelly - 2023-05-23 14:52:16
does DNSSEC perform better on DNS over QUIC?
Shane Kerr - 2023-05-23 14:52:40
DNSSEC should have less problems with fragmentation (for example) with QUIC than raw UDP.
Eva Lauren Kelly - 2023-05-23 14:53:04
so I wonder whether that might be a way forwards
Shane Kerr - 2023-05-23 14:53:15
Also it shouldn't require retry over TCP for large messages.
Shane Kerr - 2023-05-23 14:53:44
And it should provide 0RTT, so have UDP-like packet counts.
Iljitsch van Beijnum - 2023-05-23 14:54:01
Now I hear echos of John Day (the application stuff)
Shane Kerr - 2023-05-23 14:54:04
So basically, on paper QIUC should solve a lot of problems with the current DNS. :smile:
Marco Schmidt - 2023-05-23 14:54:37
@eva If you would want to raise your question also to Geoff, please post it in the Q&A section
Shane Kerr - 2023-05-23 14:55:01
QUIC is orthogonal to DNSSEC though. QUIC secures the communication channel, DNSSEC signs the data.
Iljitsch van Beijnum - 2023-05-23 14:55:10
Is QUIC better than TCP when you only need one stream though?
Shane Kerr - 2023-05-23 14:55:38
QUIC should avoid head-of-line blocking, so yes even with one stream QIUC should be better than TCP. (Again, on paper at least...)
Eva Lauren Kelly - 2023-05-23 14:55:58
security properties of QUIC sound like a nice bonus i suppose
Iljitsch van Beijnum - 2023-05-23 14:56:34
But with DNSSEC you don't need that, as it already provides its own security.
Eva Lauren Kelly - 2023-05-23 14:57:33
aha, sounds like he is addressing QUIC here anyway
Brett Carr - 2023-05-23 15:00:25
DNSSEC is easy to operate if you know the stuff but for those who don't know it still has a high bar to entry
Carsten Schiefner - 2023-05-23 15:00:26
@Meeting Team: Could the echo be dampened somehow, please? If somehow possible? Thanks!
Marco Schmidt - 2023-05-23 15:02:05
@carsten: Thanks for the feedback - we are looking into that
Brett Carr - 2023-05-23 15:02:14
agree with @jim
Carsten Schiefner - 2023-05-23 15:02:25
@Marco: Lovely, thanks a lkot!
Geoff Huston - 2023-05-23 15:03:17
well said Randy!
Marco d'Itri - 2023-05-23 15:03:17
[applause]
Éric Vyncke - 2023-05-23 15:03:30
Same fonts ;-)
Brett Carr - 2023-05-23 15:04:09
Thanks @geoff lots to think about there, and I will be touting your presentation internally at $employer
Geoff Huston - 2023-05-23 15:07:36
@Brett: Server-side assembly of DNSSEC chained responses coupled with a QUIC transport using DOH sounds like a more promising way to navigate our way around a bunch of DNSSEC validation icebergs!
Marco d'Itri - 2023-05-23 15:18:11
As the maintainer of the RPKI software in Debian, some of which is driven by crontabs, I welcome establishing a consensus on how often validators should poll the repositories
Marco d'Itri - 2023-05-23 15:20:54
currently rpki-client is started every 15 minutes (with a +/- 10m randomization), so it looks like I should make it run more frequent by default
Geoff Huston - 2023-05-23 15:21:15
@marco thats a "how long is a piece of string" kind of question. We know that 1 second is kinda too little and 1 day is way too long.
Marco d'Itri - 2023-05-23 15:22:07
I think it's more a "how fast are the RIRs and other operators comfortable with" question, since they provide the repositories
Geoff Huston - 2023-05-23 15:22:32
(applause)
Geoff Huston - 2023-05-23 15:27:23
@marco - see https://www.potaroo.net/presentations/2020-07-23-iepg-rpki.pdf - slide 17 - 120 seconds is a popular choice, and 600 seconds is the next most popular. Is either of these a "good" choice? Unfortunately I don't have any helpful data (or intuition) to share on this.
Marco d'Itri - 2023-05-23 15:28:25
I will have a look. I just do not want the RIRs blaming me for releasing aggressive software, :-) so maybe I have been too much careful...
Geoff Huston - 2023-05-23 15:28:40
You could always use RRDP over QUIC to get over head of line blocking (and QUIC is SO fashionablethese days!)
Marco Schmidt - 2023-05-23 15:28:51
This session has now ended. The next plenary session will start at 16:00. More info on the RIPE 86 meeting plan: https://ripe86.ripe.net/programme/meeting-plan/
Marco d'Itri - 2023-05-23 15:29:27
Sure, I expect that the openssl people will release something QUIC-enabled any year now!
Randy Bush - 2023-05-23 15:53:24
@geoff do not solve app layer HOLB at transport. read man pages for fork() and exec().
