#ietf125 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #ietf125, aggregated by home.social.
-
After testing chinese payment apps at #IETF125, I discover in Arora's talk at #UndoneCS that there is an indian payment app, Aadhaar Pay https://play.google.com/store/apps/details?id=com.tcs.merchant.cags.boi&hl=ln
-
After testing chinese payment apps at #IETF125, I discover in Arora's talk at #UndoneCS that there is an indian payment app, Aadhaar Pay https://play.google.com/store/apps/details?id=com.tcs.merchant.cags.boi&hl=ln
-
The Internet Last Week
* IETF 125
https://www.ietf.org/meeting/125/
* Cuba power outage effects
https://noc.social/@cloudflareradar/116240190351546459
https://mastodon.social/@IODA/116246041272623316
https://infosec.exchange/@dougmadory/116240466331483809
https://mastodon.social/@netblocks/116240861464667713
* IoT DDoS botnets disrupted
https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks
* Unallocated IP4 /13 announced
https://infosec.exchange/@spamhaus/116250561577999852
https://bgp.he.net/net/102.224.0.0/13
https://stat.ripe.net/widget/routing-history#resource=102.224.0.0/13&starttime=2026-03-15
* CAs must perform DNSSEC validation
https://cabforum.org/2025/06/18/ballot-sc-085v2-require-validation-of-dnssec-when-present-for-caa-and-dcv-lookups/
https://infosec.exchange/@mnordhoff/116240122433847371 -
The Internet Last Week
* IETF 125
https://www.ietf.org/meeting/125/
* Cuba power outage effects
https://noc.social/@cloudflareradar/116240190351546459
https://mastodon.social/@IODA/116246041272623316
https://infosec.exchange/@dougmadory/116240466331483809
https://mastodon.social/@netblocks/116240861464667713
* IoT DDoS botnets disrupted
https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks
* Unallocated IP4 /13 announced
https://infosec.exchange/@spamhaus/116250561577999852
https://bgp.he.net/net/102.224.0.0/13
https://stat.ripe.net/widget/routing-history#resource=102.224.0.0/13&starttime=2026-03-15
* CAs must perform DNSSEC validation
https://cabforum.org/2025/06/18/ballot-sc-085v2-require-validation-of-dnssec-when-present-for-caa-and-dcv-lookups/
https://infosec.exchange/@mnordhoff/116240122433847371 -
#IETF125
For once, there was no cats on the slides: -
#IETF125
For once, there was no cats on the slides: -
Now, a bit of SciFi: securing communications in space (related to working groups like tiptop or dtn).
Prevent the aliens from modifying packets?
Not obvious to do with asynchronous communications (common in space).
-
Now, a bit of SciFi: securing communications in space (related to working groups like tiptop or dtn).
Prevent the aliens from modifying packets?
Not obvious to do with asynchronous communications (common in space).
-
An interesting point is that the chinese challenge is open internationaly. Foreigners are encouraged to apply. (Unlike what Russia did for GOST.)
Apparently (but the speaker refused to answer) the proposal has to be new. Do not submit ML-KEM.
-
An interesting point is that the chinese challenge is open internationaly. Foreigners are encouraged to apply. (Unlike what Russia did for GOST.)
Apparently (but the speaker refused to answer) the proposal has to be new. Do not submit ML-KEM.
-
A talk about the new chinese commercial cryptographic algorithms program at #IETF125 (ping @shaft)
"commercial" as in "no State secrets"Current algorithms are ZUC, SM2, SM3, SM4, SM9... (All of them ISO standards.) https://en.wikipedia.org/wiki/ZUC_stream_cipher https://en.wikipedia.org/wiki/SM9_(cryptography_standard)
Some are in IANA registries (for instance for TLS) See RFC 8998
Now asking for post-quantum alternatives. (Formal announcement one year ago.) https://niccs.org.cn/niccs/index.html You can still submit a poposal!
-
A talk about the new chinese commercial cryptographic algorithms program at #IETF125 (ping @shaft)
"commercial" as in "no State secrets"Current algorithms are ZUC, SM2, SM3, SM4, SM9... (All of them ISO standards.) https://en.wikipedia.org/wiki/ZUC_stream_cipher https://en.wikipedia.org/wiki/SM9_(cryptography_standard)
Some are in IANA registries (for instance for TLS) See RFC 8998
Now asking for post-quantum alternatives. (Formal announcement one year ago.) https://niccs.org.cn/niccs/index.html You can still submit a poposal!
-
Among the funny questions: at what point will ML-DSA and ML-KEM no longer regarded "Post-Quantum Cryptography" but just plain "Cryptography"? Before or after IPv6 world domination?
-
Among the funny questions: at what point will ML-DSA and ML-KEM no longer regarded "Post-Quantum Cryptography" but just plain "Cryptography"? Before or after IPv6 world domination?
-
Now, SAAG meeting (Security Area Open Meeting, basically examining possible future security work).
There are many IETF working groups in the Security Area...
-
Now, SAAG meeting (Security Area Open Meeting, basically examining possible future security work).
There are many IETF working groups in the Security Area...
-
So, when an old resolver (not knowing DELEG) queries a new server for a domain which has only DELEG (and no NS records), what the answer should be? NXDOMAIN? SERVFAIL? Synthesis of some NS?
-
So, when an old resolver (not knowing DELEG) queries a new server for a domain which has only DELEG (and no NS records), what the answer should be? NXDOMAIN? SERVFAIL? Synthesis of some NS?
-
-
-
DELEG working group (changing completely the #DNS delegation). Last big issue: how should a new server reply to an old client, when the server has only DELEG records and no NS records?
-
DELEG working group (changing completely the #DNS delegation). Last big issue: how should a new server reply to an old client, when the server has only DELEG records and no NS records?
-
Good morning, Shenzhen:! Seventh and last day of #IETF125 https://www.ietf.org/meeting/125/
Today, we are going to break/save/restore the #DNS with the new delegation system, DELEG. Also, security area general meeting.
-
Good morning, Shenzhen:! Seventh and last day of #IETF125 https://www.ietf.org/meeting/125/
Today, we are going to break/save/restore the #DNS with the new delegation system, DELEG. Also, security area general meeting.
-
And so the fun begins… Air Canada delays my return flight home today from #IETF125 in Tokyo by an hour…
——
Your flight AC4 to Vancouver is delayed because a mechanical issue on an earlier flight caused the scheduled aircraft to arrive late. It will now depart at 18:35. We apologize and are working to get you on your way.
-
And so the fun begins… Air Canada delays my return flight home today from #IETF125 in Tokyo by an hour…
——
Your flight AC4 to Vancouver is delayed because a mechanical issue on an earlier flight caused the scheduled aircraft to arrive late. It will now depart at 18:35. We apologize and are working to get you on your way.
-
And now, at last, AI in the dnsop working group. "DNS for AI Discovery"
https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/ (5 or 6 very similar drafts, often from China)
_agents.ietf.org soon! More seriously, this is a limited (and rightly so) proposal to use DNS just for naming AI agents.
-
And now, at last, AI in the dnsop working group. "DNS for AI Discovery"
https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/ (5 or 6 very similar drafts, often from China)
_agents.ietf.org soon! More seriously, this is a limited (and rightly so) proposal to use DNS just for naming AI agents.
-
-
-
Another funny question. After Cisco broke because Cloudflare changed the order of DNS records in the answer (which is perfectly legitimate), should we mandate a specific order in #DNS?
-
Another funny question. After Cisco broke because Cloudflare changed the order of DNS records in the answer (which is perfectly legitimate), should we mandate a specific order in #DNS?
-
After a lively discussion on solutions to depend less on the #DNS root (obviously no consensus, despite a tendency to deny there is a problem to solve), another hot question: DNS #censorship and the need to be transparent about it. https://datatracker.ietf.org/doc/draft-nottingham-dnsop-censorship-transparency/
What to display to the end user? (Not anything got from the resolver: security issues.) Lumen Database entry?
-
After a lively discussion on solutions to depend less on the #DNS root (obviously no consensus, despite a tendency to deny there is a problem to solve), another hot question: DNS #censorship and the need to be transparent about it. https://datatracker.ietf.org/doc/draft-nottingham-dnsop-censorship-transparency/
What to display to the end user? (Not anything got from the resolver: security issues.) Lumen Database entry?
-
It seems we have now the mandatory very-long-thread-with-a-lot-of-rant on the #IETF125 mailing list about https://datatracker.ietf.org/doc/draft-rescorla-anonymous-network/ and the possibility that it prevents us going to China (and may be other countries).
-
It seems we have now the mandatory very-long-thread-with-a-lot-of-rant on the #IETF125 mailing list about https://datatracker.ietf.org/doc/draft-rescorla-anonymous-network/ and the possibility that it prevents us going to China (and may be other countries).
-
Now, dnsop working group (real-time transcript said "Dina Zop") because the #DNS loves you and we love it, too.
First, a lot of stuff about various ways to be less technically dependent on the root (local caching, local root as in RFC 8806, etc).
RFC 8806, the resolver behaves as if it were authoritative for the root. RootCache is more resolver-traditional.
-
Now, dnsop working group (real-time transcript said "Dina Zop") because the #DNS loves you and we love it, too.
First, a lot of stuff about various ways to be less technically dependent on the root (local caching, local root as in RFC 8806, etc).
RFC 8806, the resolver behaves as if it were authoritative for the root. RootCache is more resolver-traditional.
-
Among the questions: will the LLMs be required to log in Meetecho? Will they have to pay a fee for attending? Are they eligible for NomCom?
-
Among the questions: will the LLMs be required to log in Meetecho? Will they have to pay a fee for attending? Are they eligible for NomCom?
-
Thinking about writing an April Fools RFC about the future "AI-only IETF", where everything, writing drafts, implementing them at the hackathon, reviewing them and trolling on the mailing lists about cookies will be done by LLMs.
-
Thinking about writing an April Fools RFC about the future "AI-only IETF", where everything, writing drafts, implementing them at the hackathon, reviewing them and trolling on the mailing lists about cookies will be done by LLMs.
-
-
-
Interesting questions about student participation in the IETF. The delays are not the same (a RFC can easily take longer than a master thesis).
-
Interesting questions about student participation in the IETF. The delays are not the same (a RFC can easily take longer than a master thesis).
-
Testimony from Tsinghua university at IETF. Worked on 4over6 (softwires, BEHAVE working group), SAVI (source IP address validation, currently the SAVNET working group, with extensions to routing protocols), and now AI (LLM agents running wild on the network)
Mentioned in 22 RFCs (not many universities have this score)
"IETF: the heaven for contribution to the Internet"
-
Testimony from Tsinghua university at IETF. Worked on 4over6 (softwires, BEHAVE working group), SAVI (source IP address validation, currently the SAVNET working group, with extensions to routing protocols), and now AI (LLM agents running wild on the network)
Mentioned in 22 RFCs (not many universities have this score)
"IETF: the heaven for contribution to the Internet"
-
-
-
The research arm of CNNIC is the National Engineering Laboratory. Working on many things, including of course a lot of AI (and drone identification.
-
The research arm of CNNIC is the National Engineering Laboratory. Working on many things, including of course a lot of AI (and drone identification.
-
CNNIC https://cnnic.cn/ is both the registry of ;cn (and other Chinese TLD, for instance in Unicode), the registry of some ICANN TLDs and the NIR (National Internet registry, for IP addresses).
-
CNNIC https://cnnic.cn/ is both the registry of ;cn (and other Chinese TLD, for instance in Unicode), the registry of some ICANN TLDs and the NIR (National Internet registry, for IP addresses).
-
Now, "host speaker", CNNIC (.cn registry) will talk about "Innovation and development of Internet infrastructure resources technology".
And there is a nice lunch box.