SlideShare ist ein Scribd-Unternehmen logo
1 von 23
Downloaden Sie, um offline zu lesen
Measurement of DNSSEC
Validation with RSA-4096
Geoff Huston, Joao Damas
APNIC Labs
November 2021
RSA is not a “dense” algorithm
Security “level” (bits) * RSA Key Length (bits)
80 1,024
112 2,048
128 3,072
140 4,096
192 7,680
* An n-bit security level implies that an attacker would need to perform 2n operations to “solve” it.
And quantum computing
is an “issue”
(using a mere 20 million qubit quantum computer!)
What if…
You’re concerned by this because:
• You want to protect the data for longer than 8 hours
• You believe that quantum computers will develop quickly
• You believe that ECDSA represents a lower level of resistance to quantum
computing techniques
• So you might want to keep using RSA, but extend its key length to
defend against this risk
• To 4,096 bit keys perhaps?
Will RSA-4096 work for DNSSEC?
The major concern is the size of the data to be carried in DNS payloads
Algorithm Private Key (bytes) Public Key (bytes) Signature (bytes) Security Level
RSA-1024 1,102 438 259 80
RSA-2048 1,776 620 403 112
RSA-4096 3,312 967 744 140
ECDSA P-256 187 353 146 128
Ed25519 179 300 146 128
These sizes impact DNS payload sizes
RSA-4096 Performance
Signing Time is the elapsed time to size a zone with 0.5M entries
Validation Time is the elapsed time to validate 50K responses
Algorithm Signing Time (secs) Validation Time (secs)
None 905
RSA-1024 52 1,168
RSA-2048 126 1,173
RSA-4096 830 1,176
ECDSA P-256 159 1,036
Ed25519 205 1,008
RSA-4096 signed DNS Response sizes by
Query Type
RR Type RSA-4096 (bytes) ECDSA P-256 (bytes)
A 747 273
DS 721 245
DNSKEY 1,245 347
DNS Flag Day 2020 proposed a maximum DNS payload of
1,232 bytes when using UDP transport
Will it fit?
If we are looking at the point of UDP truncation then we need to look
at the distribution of EDNS(0) UDP Buffer size settings on these DNSSEC
validation queries
17% of users query via
recursive resolvers that use a
UDP buffer size of less than
1,245 bytes
Test Rig
• Configure an Ad campaign to ask for 2 URLs:
• One has a domain name that is signed using an RSA-4096 key
• One uses an invalidly signed domain name, again using a RSA-4096 key
• The Domain names are dynamically generated with unique sub-labels
• We perform a DNS packet capture at the authoritative server
• We are looking for experiments that use resolvers that ask for DS and
DNSKEY records
https://0ds-udeb9087f-c13-a1283-s1632968189-i00000000.ape.dotnxdomain.net/1x1.png
https://0di-udeb9087f-c13-a1283-s1632968189-i00000000.ape.dotnxdomain.net/1x1.png
Experiment result classes
1. “Validating”
The A / AAAA queries have the DO bit set
DS / DNSKEY queries are made
The user fetches the validly signed web object, but not the invalidly signed
object
2. “Mixed Validating”
The A / AAAA queries have the DO bit set
DS / DNSKEY queries are made, but not necessarily by every resolver
The user fetches both the validly-signed and invalidly signed web objects
Single RSA-4096 Key
• The zone uses a single yet as both the KSK and the ZSK
• The DNSKEY records contains a single key
• Test of 84M samples over 7 day period in September 2021
Algorithm Validating (% of tests) Mixed (% of tests)
RSA-1024 29.7% 9.0%
RSA-4096 29.4% 9.1%
We use a RSA-1024 signed zone as a control,
where the DNSKEY response is 491 octets
RSA-4096 DNSKEY response processing
• 74% of experiments received the DNSKEY response of 1,245 bytes
over UDP
• 26% of experiments had a smaller UDP buffer size and were sent a
truncated UDP response
• 23.5% of experiments followed up using TCP
• And 2.5% did not!
• 2% then re-queried with a different resolver that used a larger UDP buffer size
• 0.5% failed DNS resolution
But maybe this is not a “real” test
• Perhaps a more realistic scenario for a DNSSEC-signed zone is to use a
ZSK and a separate KSK, which means we should look at the DNSKEY
record with 2 x RSA-4096 keys
• And we should also consider a key roll scenario, which means we
should also look at the DNSKEY record with 3 x RSA-4096 keys
• So let’s go there!
Multiple RSA-4096 Keys
Key Count DNSKEY Response Size (bytes)
1 x RSA-4096 1,245
2 x RSA-4096 1,755
3 x RSA-4096 2,237
Validation Outcomes with larger DNSKEY records
Algorithm / Key Count Validating Mixed
RSA-1024 29.7% 9.0%
RSA-4096 x 1 29.4% 9.1%
RSA-4096 x 2 27.9% 9.1%
RSA-4096 x 3 24.0% 7.8%
The comparison between the 2-key and 3-key cases shows that there are more issues than
just UDP fragmentation and/or TCP re-query when the DNS response grows from 1,755 to
2,237 bytes
Are we touching upon internal implementation issues? Or perhaps selective network
responses to pre-empt potential DNS amplification attacks? Perhaps other causes are at
work here to create this difference between the outcomes of these two cases.
What’s going on?
• Maybe the resolver’s UDP Buffer size in queries is being too optimistic
and doesn’t reflect the resolver’s ability and the local network’s ability
to admit fragmented UDP responses and reassemble the responses
• Path MTU mismatch, security policies, receiver buffer limits?
Or
• The resolver is unable to perform a TCP fetch after receiving a
truncated UDP response
• Over-enthusiastic local security rules, or borked DNS implementations,
misbehaving middleware, or load-distribution front end size filters?
Failure to complete a TCP re-query rises with
a larger DNS PAYLOAD
Key Count TCP Failure Rate
RSA-4096 x 1 (1,245 bytes) 0.1%
RSA-4096 x 2 (1,755 bytes) 2.5%
RSA-4096 x 3 (2,237 bytes) 7.2%
Here we are looking for a query sequence where we respond to the original query with a
truncated UDP DNS response, but there is no subsequent TCP completed re-query
Where is this a problem?
RSA-1024 RSA-4096x2 Difference
Portugal 68% 40% -28%
Morocco 59% 31% -27%
Iceland 95% 72% -23%
Guyana 41% 28% -13%
USA 60% 48% -12%
Ireland 27% 18% -9%
Switzerland 81% 73% -9%
Brunei 31% 23% -8%
Singapore 71% 64% -8%
Sweden 91% 84% -7%
These are all % of users who complete DNSSEC Validation
Which ISPs?
RSA-1024 RSA-4096 x 2 Difference AS Name
AS39603 93% 47% -45% P4 UMTS, Poland
AS5466 94% 51% -44% Eircom, Ireland
AS23688 93% 54% -39% Link3, Bangladesh
AS45543 73% 34% -39% SCTV, Vietnam
AS36903 77% 41% -36% MT-MPLS, Morocco
AS34779 91% 56% -35% T-2, Slovenia
AS35819 93% 65% -28% Etihad Etisalat, Saudi Arabia
AS28573 63% 37% -26% Claro, Brazil
AS3243 92% 67% -25% Meo Residencial, Portugal
AS4818 91% 69% -22% Digi Telecom, Malaysia
Does RSA-4096 have a future in DNSSEC?
• It’s not looking good!
• But does it matter?
• Should we be turning to using 140-bit security level in DNSSEC in
2021 in any case?
(i.e. is RSA-4096 over-achieving for DNSSEC?)
It’s DNSSEC!
• What is the “secure lifetime” of a signed item of DNS data?
• It’s not hiding a “secret”!
• It‘s protecting the integrity of the DNS data
• And the integrity of the digital signature depends on the key lifetime
• So the anticipated secure lifetime of a DNSSEC key needs to be greater than the key
lifetime, but not that much longer!
• So the longer the lifetime of a DNSSEC key, then the greater your
requirement for a longer secure lifetime, which implies the greater your
need a higher security level of your algorithm and key
• For example, if your roll keys every 6 months then your secure lifetime requirement
is less than 1 year
• While RSA-1024 is probably incapable of providing a 10 year secure lifetime
for encrypted messages, it is likely to still be useful in DNSSEC as long as
you roll your keys more frequently than every decade!
It’s Quantum Computing!
• In our current understanding of the quantum computing environment
the concept of “security level” does not transcribe from conventional
to quantum computing cleanly
• While some algorithms and key profiles have the same “security
level” they have different levels of quantum resilience
• For example, RSA with longer keys lengths is thought to be more
quantum resilient than an equivalent security level elliptical curve
profile
Questions?

Weitere ähnliche Inhalte

Was ist angesagt?

ICANN DNS Symposium 2021: Measuring Recursive Resolver Centrality
ICANN DNS Symposium 2021: Measuring Recursive Resolver CentralityICANN DNS Symposium 2021: Measuring Recursive Resolver Centrality
ICANN DNS Symposium 2021: Measuring Recursive Resolver CentralityAPNIC
 
NANOG 82: DNS Evolution
NANOG 82: DNS EvolutionNANOG 82: DNS Evolution
NANOG 82: DNS EvolutionAPNIC
 
IETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSIETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSAPNIC
 
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache Servers
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache ServersNANOG32 - DNS Anomalies and Their Impacts on DNS Cache Servers
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache ServersChika Yoshimura
 
RIPE 82: An Update on Fragmentation Loss Rates in IPv6
RIPE 82: An Update on Fragmentation Loss Rates in IPv6RIPE 82: An Update on Fragmentation Loss Rates in IPv6
RIPE 82: An Update on Fragmentation Loss Rates in IPv6APNIC
 
Testing Rolling Roots
Testing Rolling RootsTesting Rolling Roots
Testing Rolling RootsAPNIC
 
DNS & DNSSEC
DNS & DNSSECDNS & DNSSEC
DNS & DNSSECAPNIC
 
Pseudo Random DNS Query Attacks and Resolver Mitigation Approaches
Pseudo Random DNS Query Attacks and Resolver Mitigation ApproachesPseudo Random DNS Query Attacks and Resolver Mitigation Approaches
Pseudo Random DNS Query Attacks and Resolver Mitigation ApproachesAPNIC
 
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018Internet Week 2018: APNIC Reverse DNS service outage report: May 2018
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018APNIC
 
Rolling the Root Zone DNSSEC Key Signing Key
Rolling the Root Zone DNSSEC Key Signing KeyRolling the Root Zone DNSSEC Key Signing Key
Rolling the Root Zone DNSSEC Key Signing KeyAPNIC
 
Drilling Down Into DNS DDoS
Drilling Down Into DNS DDoSDrilling Down Into DNS DDoS
Drilling Down Into DNS DDoSAPNIC
 
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenchesInternet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenchesAPNIC
 
BSides: BGP Hijacking and Secure Internet Routing
BSides: BGP Hijacking and Secure Internet RoutingBSides: BGP Hijacking and Secure Internet Routing
BSides: BGP Hijacking and Secure Internet RoutingAPNIC
 
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI MattersAPNIC
 
Introduction DNSSec
Introduction DNSSecIntroduction DNSSec
Introduction DNSSecAFRINIC
 
The Anatomy of DDoS Attacks
The Anatomy of DDoS AttacksThe Anatomy of DDoS Attacks
The Anatomy of DDoS AttacksAcquia
 
Experience Using RIR Whois
Experience Using RIR WhoisExperience Using RIR Whois
Experience Using RIR WhoisAPNIC
 
AstriCon 2017 - Docker Swarm & Asterisk
AstriCon 2017  - Docker Swarm & AsteriskAstriCon 2017  - Docker Swarm & Asterisk
AstriCon 2017 - Docker Swarm & AsteriskEvan McGee
 
Are we really ready to turn off IPv4?
Are we really ready to turn off IPv4?Are we really ready to turn off IPv4?
Are we really ready to turn off IPv4?APNIC
 

Was ist angesagt? (20)

ICANN DNS Symposium 2021: Measuring Recursive Resolver Centrality
ICANN DNS Symposium 2021: Measuring Recursive Resolver CentralityICANN DNS Symposium 2021: Measuring Recursive Resolver Centrality
ICANN DNS Symposium 2021: Measuring Recursive Resolver Centrality
 
NANOG 82: DNS Evolution
NANOG 82: DNS EvolutionNANOG 82: DNS Evolution
NANOG 82: DNS Evolution
 
IETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNSIETF 100: A signalling mechanism for trusted keys in the DNS
IETF 100: A signalling mechanism for trusted keys in the DNS
 
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache Servers
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache ServersNANOG32 - DNS Anomalies and Their Impacts on DNS Cache Servers
NANOG32 - DNS Anomalies and Their Impacts on DNS Cache Servers
 
RIPE 82: An Update on Fragmentation Loss Rates in IPv6
RIPE 82: An Update on Fragmentation Loss Rates in IPv6RIPE 82: An Update on Fragmentation Loss Rates in IPv6
RIPE 82: An Update on Fragmentation Loss Rates in IPv6
 
Testing Rolling Roots
Testing Rolling RootsTesting Rolling Roots
Testing Rolling Roots
 
DNS & DNSSEC
DNS & DNSSECDNS & DNSSEC
DNS & DNSSEC
 
Pseudo Random DNS Query Attacks and Resolver Mitigation Approaches
Pseudo Random DNS Query Attacks and Resolver Mitigation ApproachesPseudo Random DNS Query Attacks and Resolver Mitigation Approaches
Pseudo Random DNS Query Attacks and Resolver Mitigation Approaches
 
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018Internet Week 2018: APNIC Reverse DNS service outage report: May 2018
Internet Week 2018: APNIC Reverse DNS service outage report: May 2018
 
Rolling the Root Zone DNSSEC Key Signing Key
Rolling the Root Zone DNSSEC Key Signing KeyRolling the Root Zone DNSSEC Key Signing Key
Rolling the Root Zone DNSSEC Key Signing Key
 
Drilling Down Into DNS DDoS
Drilling Down Into DNS DDoSDrilling Down Into DNS DDoS
Drilling Down Into DNS DDoS
 
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenchesInternet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
Internet Week 2018: 1.1.1.0/24 A report from the (anycast) trenches
 
BSides: BGP Hijacking and Secure Internet Routing
BSides: BGP Hijacking and Secure Internet RoutingBSides: BGP Hijacking and Secure Internet Routing
BSides: BGP Hijacking and Secure Internet Routing
 
Network Security Best Practice (BCP38 & 140)
Network Security Best Practice (BCP38 & 140) Network Security Best Practice (BCP38 & 140)
Network Security Best Practice (BCP38 & 140)
 
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters
2nd ICANN APAC-TWNIC Engagement Forum: Why RPKI Matters
 
Introduction DNSSec
Introduction DNSSecIntroduction DNSSec
Introduction DNSSec
 
The Anatomy of DDoS Attacks
The Anatomy of DDoS AttacksThe Anatomy of DDoS Attacks
The Anatomy of DDoS Attacks
 
Experience Using RIR Whois
Experience Using RIR WhoisExperience Using RIR Whois
Experience Using RIR Whois
 
AstriCon 2017 - Docker Swarm & Asterisk
AstriCon 2017  - Docker Swarm & AsteriskAstriCon 2017  - Docker Swarm & Asterisk
AstriCon 2017 - Docker Swarm & Asterisk
 
Are we really ready to turn off IPv4?
Are we really ready to turn off IPv4?Are we really ready to turn off IPv4?
Are we really ready to turn off IPv4?
 

Ähnlich wie DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096

Signing DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutionsSigning DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutionsAPNIC
 
RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?APNIC
 
Hardening the Core of the Internet
Hardening the Core of the InternetHardening the Core of the Internet
Hardening the Core of the InternetRIPE NCC
 
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonDNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonAPNIC
 
NANOG 74: That KSK Roll
NANOG 74: That KSK RollNANOG 74: That KSK Roll
NANOG 74: That KSK RollAPNIC
 
NZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECNZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECAPNIC
 
Rolling the Root KSK
Rolling the Root KSKRolling the Root KSK
Rolling the Root KSKAPNIC
 
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]APNIC
 
getdns PyCon presentation
getdns PyCon presentationgetdns PyCon presentation
getdns PyCon presentationMelinda Shore
 
DNSSEC signing Tutorial
DNSSEC signing Tutorial DNSSEC signing Tutorial
DNSSEC signing Tutorial Men and Mice
 
OpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform TechnologyOpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform TechnologyCourtland Smith
 
IGF 2023: DNS Privacy
IGF 2023: DNS PrivacyIGF 2023: DNS Privacy
IGF 2023: DNS PrivacyAPNIC
 

Ähnlich wie DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096 (20)

Signing DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutionsSigning DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutions
 
RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?RIPE 86: DNSSEC — Yes or No?
RIPE 86: DNSSEC — Yes or No?
 
8 technical-dns-workshop-day4
8 technical-dns-workshop-day48 technical-dns-workshop-day4
8 technical-dns-workshop-day4
 
Hardening the Core of the Internet
Hardening the Core of the InternetHardening the Core of the Internet
Hardening the Core of the Internet
 
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonDNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
 
NANOG 74: That KSK Roll
NANOG 74: That KSK RollNANOG 74: That KSK Roll
NANOG 74: That KSK Roll
 
NZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSECNZNOG 2013 - Experiments in DNSSEC
NZNOG 2013 - Experiments in DNSSEC
 
ION Bangladesh - DANE, DNSSEC, and TLS Testing in the Go6lab
ION Bangladesh - DANE, DNSSEC, and TLS Testing in the Go6labION Bangladesh - DANE, DNSSEC, and TLS Testing in the Go6lab
ION Bangladesh - DANE, DNSSEC, and TLS Testing in the Go6lab
 
Rolling the Root KSK
Rolling the Root KSKRolling the Root KSK
Rolling the Root KSK
 
DNS - MCSE 2019
DNS - MCSE 2019DNS - MCSE 2019
DNS - MCSE 2019
 
RP11_XaviertTorrentGorjon
RP11_XaviertTorrentGorjonRP11_XaviertTorrentGorjon
RP11_XaviertTorrentGorjon
 
ION Hangzhou - Why Deploy DNSSEC?
ION Hangzhou - Why Deploy DNSSEC?ION Hangzhou - Why Deploy DNSSEC?
ION Hangzhou - Why Deploy DNSSEC?
 
IoT Secure Bootsrapping : ideas
IoT Secure Bootsrapping : ideasIoT Secure Bootsrapping : ideas
IoT Secure Bootsrapping : ideas
 
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
What if everyone did it?, by Geoff Huston [APNIC 38 / APOPS 1]
 
getdns PyCon presentation
getdns PyCon presentationgetdns PyCon presentation
getdns PyCon presentation
 
DNSSEC signing Tutorial
DNSSEC signing Tutorial DNSSEC signing Tutorial
DNSSEC signing Tutorial
 
ION Islamabad - Deploying DNSSEC
ION Islamabad - Deploying DNSSECION Islamabad - Deploying DNSSEC
ION Islamabad - Deploying DNSSEC
 
OpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform TechnologyOpenDNS Whitepaper: Platform Technology
OpenDNS Whitepaper: Platform Technology
 
ION Bucharest - Deploying DNSSEC
ION Bucharest - Deploying DNSSECION Bucharest - Deploying DNSSEC
ION Bucharest - Deploying DNSSEC
 
IGF 2023: DNS Privacy
IGF 2023: DNS PrivacyIGF 2023: DNS Privacy
IGF 2023: DNS Privacy
 

Mehr von APNIC

APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC
 
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC
 
APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024APNIC
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...APNIC
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024APNIC
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGAPNIC
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119APNIC
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119APNIC
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119APNIC
 
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119APNIC
 
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119APNIC
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...APNIC
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonAPNIC
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPNIC
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6APNIC
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!APNIC
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023APNIC
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAPNIC
 

Mehr von APNIC (20)

APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
APNIC Policy Roundup presented by Sunny Chendi at TWNOG 5.0
 
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...
 
APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOG
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
 
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
 
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff Huston
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet development
 

Kürzlich hochgeladen

Best SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasBest SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasDigicorns Technologies
 
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查ydyuyu
 
Real Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtReal Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtrahman018755
 
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime NagercoilNagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoilmeghakumariji156
 
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac RoomVip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Roommeghakumariji156
 
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样ayvbos
 
Indian Escort in Abu DHabi 0508644382 Abu Dhabi Escorts
Indian Escort in Abu DHabi 0508644382 Abu Dhabi EscortsIndian Escort in Abu DHabi 0508644382 Abu Dhabi Escorts
Indian Escort in Abu DHabi 0508644382 Abu Dhabi EscortsMonica Sydney
 
Microsoft Azure Arc Customer Deck Microsoft
Microsoft Azure Arc Customer Deck MicrosoftMicrosoft Azure Arc Customer Deck Microsoft
Microsoft Azure Arc Customer Deck MicrosoftAanSulistiyo
 
20240510 QFM016 Irresponsible AI Reading List April 2024.pdf
20240510 QFM016 Irresponsible AI Reading List April 2024.pdf20240510 QFM016 Irresponsible AI Reading List April 2024.pdf
20240510 QFM016 Irresponsible AI Reading List April 2024.pdfMatthew Sinclair
 
20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdfMatthew Sinclair
 
Russian Escort Abu Dhabi 0503464457 Abu DHabi Escorts
Russian Escort Abu Dhabi 0503464457 Abu DHabi EscortsRussian Escort Abu Dhabi 0503464457 Abu DHabi Escorts
Russian Escort Abu Dhabi 0503464457 Abu DHabi EscortsMonica Sydney
 
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查ydyuyu
 
Meaning of On page SEO & its process in detail.
Meaning of On page SEO & its process in detail.Meaning of On page SEO & its process in detail.
Meaning of On page SEO & its process in detail.krishnachandrapal52
 
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrStory Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrHenryBriggs2
 
75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptxAsmae Rabhi
 
Power point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria IuzzolinoPower point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria Iuzzolinonuriaiuzzolino1
 
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdfMatthew Sinclair
 
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...kajalverma014
 
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girls
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girlsRussian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girls
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girlsMonica Sydney
 
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge GraphsEleniIlkou
 

Kürzlich hochgeladen (20)

Best SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency DallasBest SEO Services Company in Dallas | Best SEO Agency Dallas
Best SEO Services Company in Dallas | Best SEO Agency Dallas
 
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
原版制作美国爱荷华大学毕业证(iowa毕业证书)学位证网上存档可查
 
Real Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtReal Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirt
 
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime NagercoilNagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
Nagercoil Escorts Service Girl ^ 9332606886, WhatsApp Anytime Nagercoil
 
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac RoomVip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
Vip Firozabad Phone 8250092165 Escorts Service At 6k To 30k Along With Ac Room
 
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样
一比一原版(Curtin毕业证书)科廷大学毕业证原件一模一样
 
Indian Escort in Abu DHabi 0508644382 Abu Dhabi Escorts
Indian Escort in Abu DHabi 0508644382 Abu Dhabi EscortsIndian Escort in Abu DHabi 0508644382 Abu Dhabi Escorts
Indian Escort in Abu DHabi 0508644382 Abu Dhabi Escorts
 
Microsoft Azure Arc Customer Deck Microsoft
Microsoft Azure Arc Customer Deck MicrosoftMicrosoft Azure Arc Customer Deck Microsoft
Microsoft Azure Arc Customer Deck Microsoft
 
20240510 QFM016 Irresponsible AI Reading List April 2024.pdf
20240510 QFM016 Irresponsible AI Reading List April 2024.pdf20240510 QFM016 Irresponsible AI Reading List April 2024.pdf
20240510 QFM016 Irresponsible AI Reading List April 2024.pdf
 
20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf20240508 QFM014 Elixir Reading List April 2024.pdf
20240508 QFM014 Elixir Reading List April 2024.pdf
 
Russian Escort Abu Dhabi 0503464457 Abu DHabi Escorts
Russian Escort Abu Dhabi 0503464457 Abu DHabi EscortsRussian Escort Abu Dhabi 0503464457 Abu DHabi Escorts
Russian Escort Abu Dhabi 0503464457 Abu DHabi Escorts
 
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查在线制作约克大学毕业证(yu毕业证)在读证明认证可查
在线制作约克大学毕业证(yu毕业证)在读证明认证可查
 
Meaning of On page SEO & its process in detail.
Meaning of On page SEO & its process in detail.Meaning of On page SEO & its process in detail.
Meaning of On page SEO & its process in detail.
 
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrStory Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
Story Board.pptxrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
 
75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx75539-Cyber Security Challenges PPT.pptx
75539-Cyber Security Challenges PPT.pptx
 
Power point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria IuzzolinoPower point inglese - educazione civica di Nuria Iuzzolino
Power point inglese - educazione civica di Nuria Iuzzolino
 
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
20240509 QFM015 Engineering Leadership Reading List April 2024.pdf
 
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
best call girls in Hyderabad Finest Escorts Service 📞 9352988975 📞 Available ...
 
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girls
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girlsRussian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girls
Russian Call girls in Abu Dhabi 0508644382 Abu Dhabi Call girls
 
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
2nd Solid Symposium: Solid Pods vs Personal Knowledge Graphs
 

DNS-OARC-36: Measurement of DNSSEC Validation with RSA-4096

  • 1. Measurement of DNSSEC Validation with RSA-4096 Geoff Huston, Joao Damas APNIC Labs November 2021
  • 2. RSA is not a “dense” algorithm Security “level” (bits) * RSA Key Length (bits) 80 1,024 112 2,048 128 3,072 140 4,096 192 7,680 * An n-bit security level implies that an attacker would need to perform 2n operations to “solve” it.
  • 3. And quantum computing is an “issue” (using a mere 20 million qubit quantum computer!)
  • 4. What if… You’re concerned by this because: • You want to protect the data for longer than 8 hours • You believe that quantum computers will develop quickly • You believe that ECDSA represents a lower level of resistance to quantum computing techniques • So you might want to keep using RSA, but extend its key length to defend against this risk • To 4,096 bit keys perhaps?
  • 5. Will RSA-4096 work for DNSSEC? The major concern is the size of the data to be carried in DNS payloads Algorithm Private Key (bytes) Public Key (bytes) Signature (bytes) Security Level RSA-1024 1,102 438 259 80 RSA-2048 1,776 620 403 112 RSA-4096 3,312 967 744 140 ECDSA P-256 187 353 146 128 Ed25519 179 300 146 128 These sizes impact DNS payload sizes
  • 6. RSA-4096 Performance Signing Time is the elapsed time to size a zone with 0.5M entries Validation Time is the elapsed time to validate 50K responses Algorithm Signing Time (secs) Validation Time (secs) None 905 RSA-1024 52 1,168 RSA-2048 126 1,173 RSA-4096 830 1,176 ECDSA P-256 159 1,036 Ed25519 205 1,008
  • 7. RSA-4096 signed DNS Response sizes by Query Type RR Type RSA-4096 (bytes) ECDSA P-256 (bytes) A 747 273 DS 721 245 DNSKEY 1,245 347 DNS Flag Day 2020 proposed a maximum DNS payload of 1,232 bytes when using UDP transport
  • 8. Will it fit? If we are looking at the point of UDP truncation then we need to look at the distribution of EDNS(0) UDP Buffer size settings on these DNSSEC validation queries 17% of users query via recursive resolvers that use a UDP buffer size of less than 1,245 bytes
  • 9. Test Rig • Configure an Ad campaign to ask for 2 URLs: • One has a domain name that is signed using an RSA-4096 key • One uses an invalidly signed domain name, again using a RSA-4096 key • The Domain names are dynamically generated with unique sub-labels • We perform a DNS packet capture at the authoritative server • We are looking for experiments that use resolvers that ask for DS and DNSKEY records https://0ds-udeb9087f-c13-a1283-s1632968189-i00000000.ape.dotnxdomain.net/1x1.png https://0di-udeb9087f-c13-a1283-s1632968189-i00000000.ape.dotnxdomain.net/1x1.png
  • 10. Experiment result classes 1. “Validating” The A / AAAA queries have the DO bit set DS / DNSKEY queries are made The user fetches the validly signed web object, but not the invalidly signed object 2. “Mixed Validating” The A / AAAA queries have the DO bit set DS / DNSKEY queries are made, but not necessarily by every resolver The user fetches both the validly-signed and invalidly signed web objects
  • 11. Single RSA-4096 Key • The zone uses a single yet as both the KSK and the ZSK • The DNSKEY records contains a single key • Test of 84M samples over 7 day period in September 2021 Algorithm Validating (% of tests) Mixed (% of tests) RSA-1024 29.7% 9.0% RSA-4096 29.4% 9.1% We use a RSA-1024 signed zone as a control, where the DNSKEY response is 491 octets
  • 12. RSA-4096 DNSKEY response processing • 74% of experiments received the DNSKEY response of 1,245 bytes over UDP • 26% of experiments had a smaller UDP buffer size and were sent a truncated UDP response • 23.5% of experiments followed up using TCP • And 2.5% did not! • 2% then re-queried with a different resolver that used a larger UDP buffer size • 0.5% failed DNS resolution
  • 13. But maybe this is not a “real” test • Perhaps a more realistic scenario for a DNSSEC-signed zone is to use a ZSK and a separate KSK, which means we should look at the DNSKEY record with 2 x RSA-4096 keys • And we should also consider a key roll scenario, which means we should also look at the DNSKEY record with 3 x RSA-4096 keys • So let’s go there!
  • 14. Multiple RSA-4096 Keys Key Count DNSKEY Response Size (bytes) 1 x RSA-4096 1,245 2 x RSA-4096 1,755 3 x RSA-4096 2,237
  • 15. Validation Outcomes with larger DNSKEY records Algorithm / Key Count Validating Mixed RSA-1024 29.7% 9.0% RSA-4096 x 1 29.4% 9.1% RSA-4096 x 2 27.9% 9.1% RSA-4096 x 3 24.0% 7.8% The comparison between the 2-key and 3-key cases shows that there are more issues than just UDP fragmentation and/or TCP re-query when the DNS response grows from 1,755 to 2,237 bytes Are we touching upon internal implementation issues? Or perhaps selective network responses to pre-empt potential DNS amplification attacks? Perhaps other causes are at work here to create this difference between the outcomes of these two cases.
  • 16. What’s going on? • Maybe the resolver’s UDP Buffer size in queries is being too optimistic and doesn’t reflect the resolver’s ability and the local network’s ability to admit fragmented UDP responses and reassemble the responses • Path MTU mismatch, security policies, receiver buffer limits? Or • The resolver is unable to perform a TCP fetch after receiving a truncated UDP response • Over-enthusiastic local security rules, or borked DNS implementations, misbehaving middleware, or load-distribution front end size filters?
  • 17. Failure to complete a TCP re-query rises with a larger DNS PAYLOAD Key Count TCP Failure Rate RSA-4096 x 1 (1,245 bytes) 0.1% RSA-4096 x 2 (1,755 bytes) 2.5% RSA-4096 x 3 (2,237 bytes) 7.2% Here we are looking for a query sequence where we respond to the original query with a truncated UDP DNS response, but there is no subsequent TCP completed re-query
  • 18. Where is this a problem? RSA-1024 RSA-4096x2 Difference Portugal 68% 40% -28% Morocco 59% 31% -27% Iceland 95% 72% -23% Guyana 41% 28% -13% USA 60% 48% -12% Ireland 27% 18% -9% Switzerland 81% 73% -9% Brunei 31% 23% -8% Singapore 71% 64% -8% Sweden 91% 84% -7% These are all % of users who complete DNSSEC Validation
  • 19. Which ISPs? RSA-1024 RSA-4096 x 2 Difference AS Name AS39603 93% 47% -45% P4 UMTS, Poland AS5466 94% 51% -44% Eircom, Ireland AS23688 93% 54% -39% Link3, Bangladesh AS45543 73% 34% -39% SCTV, Vietnam AS36903 77% 41% -36% MT-MPLS, Morocco AS34779 91% 56% -35% T-2, Slovenia AS35819 93% 65% -28% Etihad Etisalat, Saudi Arabia AS28573 63% 37% -26% Claro, Brazil AS3243 92% 67% -25% Meo Residencial, Portugal AS4818 91% 69% -22% Digi Telecom, Malaysia
  • 20. Does RSA-4096 have a future in DNSSEC? • It’s not looking good! • But does it matter? • Should we be turning to using 140-bit security level in DNSSEC in 2021 in any case? (i.e. is RSA-4096 over-achieving for DNSSEC?)
  • 21. It’s DNSSEC! • What is the “secure lifetime” of a signed item of DNS data? • It’s not hiding a “secret”! • It‘s protecting the integrity of the DNS data • And the integrity of the digital signature depends on the key lifetime • So the anticipated secure lifetime of a DNSSEC key needs to be greater than the key lifetime, but not that much longer! • So the longer the lifetime of a DNSSEC key, then the greater your requirement for a longer secure lifetime, which implies the greater your need a higher security level of your algorithm and key • For example, if your roll keys every 6 months then your secure lifetime requirement is less than 1 year • While RSA-1024 is probably incapable of providing a 10 year secure lifetime for encrypted messages, it is likely to still be useful in DNSSEC as long as you roll your keys more frequently than every decade!
  • 22. It’s Quantum Computing! • In our current understanding of the quantum computing environment the concept of “security level” does not transcribe from conventional to quantum computing cleanly • While some algorithms and key profiles have the same “security level” they have different levels of quantum resilience • For example, RSA with longer keys lengths is thought to be more quantum resilient than an equivalent security level elliptical curve profile