Subject: [DNSOP] Time to update RSAMD5 and perhaps DSA (algs 1 and 3) to MUST NOT?

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Dec 2018 14:51:26 -0500

The IANA DNSSEC parameter registry lists RSAMD5 (algorithm 1) as
deprecated, and refers to [RFC3110], [RFC4034] which state that
RSAMD5 is "NOT RECOMMENDED".

    https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

"Survey says" that RSAMD5 is not only deprecated, but is in fact
no longer used, by any of the ~9 million DNSSEC-delegated domains
I've been able to find on the public Internet:

    https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018146.html

It only has the effect of breaking two domains that have only RSAMD5
in the DS RRset, but have no DNSKEY RRs.  11 domains, have working
keys for algorithms 5, 7, 8 or 13 with a DS RRset that also lists
an orphaned algorithm 1 with no RSAMD5 keys at the zone apex.  A
further 18 domains have RSAMD5 DS RRs, but are simply out of service
even sans validation.

This suggests to me that the deprecation of RSAMD5 is a stunning
success, it is gone, and perhaps it is time to say so:

    * Authoritative zones SHOULD NOT publish RSAMD5 DS RRs or
      DNSKEY records.

    * Validating resolvers MUST ignore RSAMD5 DS RRs and DNSKEY
      RRs, and MUST treat any zones with only ignored or unsupported
      DS records as "insecure".

Perhaps we could be bolder and say the same for DSA (algorithm 3),
this too is largely gone, but there's a cluster of ~4700 ".me"
domains with DSA keys.  It is not clear that enabling those domains
to validate merits ongoing support for algorithm 3.  So we might
also add DSA to the list, encouraging resolver implementations to
drop support for both RSAMD5 and DSA.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 1 Dec 2018 17:32:21 -0500 (EST)

>    https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

And our draft is going further and says you MUST NOT implement it :)

https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04#section-3.1

> success, it is gone, and perhaps it is time to say so:

I think more that it never really saw any deployment, so it seems a
little weird to claim success here. It shouldn't ever have gotten
an allocation even back then :P

>      DS records as "insecure".

How weak. We went for MUST NOT :)

> Perhaps we could be bolder and say the same for DSA (algorithm 3),

Funny, we also have MUST NOT there :)

> drop support for both RSAMD5 and DSA.

Done, as soon as the document gets a write up and goes into IETF LC :)

ping chairs :)

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 5 Dec 2018 00:38:31 +0100

Viktor,

apart from the I-D in the LC, the upcoming BIND 9.14 release will have:

* GOST removed (as it was deprecated by Russian “upstream”)
* Both DSA algorithms removed (insecure)
* RSAMD5 algorithm to be removed (I just finished the MR and it needs to be reviewed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1106)

Ondrej
--
Ondřej Surý
[email-masked]

> On 1 Dec 2018, at 20:51, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Dec 2018 17:14:17 -0500

> * RSAMD5 algorithm to be removed (I just finished the MR and it needs to be reviewed: https://gitlab.isc.org/isc-projects/bind9/merge_requests/1106)

Thanks for the cleanup.  I added a comment to the review noting
that no RSAMD5 DNSKEY RRs have been observed in the wild, at any
of the domains covered in my survey.  The survey does not descend
below child domains of the Mozilla PSL, so one could conjecture
some domains using RSAMD5 deeper in the DNS tree, in some internal
sub-domain of an organization, but even if the number of such domains
is not zero, it is time for them to move along or be correctly
considered "insecure".

I took a look at the most recent DS RRset data drop from FarSight
Security (credit to Paul Vixie), which includes some "deeper"
domains, and found one domain with four sub-domains with actual
RSAMD5 DNSKEYs:

    d1a1n1.rootcanary.net. IN DS 18698 1 1 [...]
    d1a1n1.rootcanary.net. IN DNSKEY 257 3 1 [...]
    ;
    d2a1n1.rootcanary.net. IN DS 11102 1 2 [...]
    d2a1n1.rootcanary.net. IN DNSKEY 257 3 1 [...]
    ;
    d3a1n1.rootcanary.net. IN DS 27842 1 3 [...]
    d3a1n1.rootcanary.net. IN DNSKEY 257 3 1 [...]
    ;
    d4a1n1.rootcanary.net. IN DS 1927 1 4 [...]
    d4a1n1.rootcanary.net. IN DNSKEY 257 3 1 [...]

I don't think this counts as a "production" RSAMD5 deployment.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Dec 2018 18:54:55 -0500

> I don't think this counts as a "production" RSAMD5 deployment.

Speaking of "production", some of the DS RRs, don't look like they
were ever intended to work.  The odds against a hex-encoded digest
containing only digits are ~146,000,000 : 1 for SHA1 and are
~11.6*10^12 : 1 for SHA2-256.  And yet looking at the DS RRs with
algorithm 1 I find a large proportion of highly implausible values
consisting of just decimal digits:

    abwg12616-459.com. IN DS 3 1 1 0000000500000000000000000000100000000000
    abwg12616-459.com. IN DS 5 1 1 0000880000000000000000000000100000000000
    abwg12616-459.com. IN DS 6 1 1 0005550000000000000000000000100000000001
    carelifesoftware.com. IN DS 1 1 1 0123456789012345678901234567890123456789
    virtualtechnologycenter.com. IN DS 1 1 1 0987654321012345678954321678900987654321
    adgraphs.com. IN DS 1000 1 1 1111111111111111111111111111111111111111
    digitransservices.com. IN DS 12345 1 1 1111111111111111111111111111111111111111
    floresti-online.net. IN DS 6733 1 1 1111111111111111111111111111111111111111
    redomain20160307.info. IN DS 2 1 1 1111111111111111111111111111111111111111
    rtgdsasdgfasdf.info. IN DS 1 1 1 1111111111111111111111111111111111111111
    techdeft.com. IN DS 3494 1 1 1111111111111111111111111111111111111111
    muakyuc.com. IN DS 111 1 2 1111111111111111111111111111111111111111111111111111111111111111
    zealwebtech.com. IN DS 65535 1 2 1111111111111111111111111111111111111111111111111111111111111234
    googleupdatetask.com. IN DS 1233 1 1 1111111111222222222233333333334444444444
    zenericpharma.com. IN DS 9876 1 1 1111111111222222223333333444444555556666
    antoinecommunications.com. IN DS 142 1 1 1111222233334444555566667777888899990000
    achteam.net. IN DS 12344 1 1 1123494393929493293239234291239423942394
    nobonesaboutitrealty.com. IN DS 1185 1 1 1185118511851185118511851185118511851185
    cossioinsurance.net. IN DS 12021 1 1 1202112021120211202112021120211202112021
    visionaryrhino.com. IN DS 12345 1 1 1234567812345678123456781234567812345678
    226pitsaktest.bid. IN DS 123 1 1 1234567890123456789012345678901234567890
    3-2-2012gdqatesting.com. IN DS 23213 1 1 1234567890123456789012345678901234567890
    cuhksis.com. IN DS 1996 1 1 1234567890123456789012345678901234567890
    diaryofthenarcissist.com. IN DS 2341 1 1 1234567890123456789012345678901234567890
    dooskers.com. IN DS 1212 1 1 1234567890123456789012345678901234567890
    eticaretif.com. IN DS 1453 1 1 1234567890123456789012345678901234567890
    netartdr.com. IN DS 1 1 1 1234567890123456789012345678901234567890
    pratechsol.com. IN DS 65420 1 1 1234567890123456789012345678901234567890
    precreto.com. IN DS 1 1 1 1234567890123456789012345678901234567890
    rastey.com. IN DS 1962 1 1 1234567890123456789012345678901234567890
    reliefsys.com. IN DS 2675 1 1 1234567890123456789012345678901234567890
    rodrigocastilho.com. IN DS 1 1 1 1234567890123456789012345678901234567890
    tokcan.com. IN DS 12345 1 1 1234567890123456789012345678901234567890
    alfahero.com. IN DS 1980 1 1 1234567890123456789012345678901234567899
    guidedtechnologies.net. IN DS 40223 1 1 1234567890987654321012345678909876543210
    civictra.com. IN DS 16738 1 1 1234567891234567891234567891234567891234
    radsw.com. IN DS 62660 1 1 1234567891234567891234567891234567891234
    brdtest011112.com. IN DS 2 1 1 1234567899876543211234567898741236547892
    resellerglobotec.com. IN DS 8110 1 1 1330133013301330133013301330133013301330
    parnanetra.com. IN DS 16 1 1 1641970127196318519661641970127196318519
    hotfix241117-live.info. IN DS 111 1 1 2222211111111111111111111111111111122222
    domcontact.bid. IN DS 1 1 1 2323343444444777444444444444444444444445
    280520143.com. IN DS 123 1 1 2343546788999999999999999999999999999999
    226pitsaktest.bid. IN DS 234 1 2 2345678901234567890123456789012345678901234567890123456788901223
    226pitsaktest.bid. IN DS 2345 1 2 2345678901234567890123456789012345678901234567890123456788901223
    smma.info. IN DS 2222 1 1 2364358523698745214569874563214569874562
    20160418uaqatest.com. IN DS 12423 1 1 3433333333333333333333333333333333455555
    catholicdevotees.com. IN DS 22021 1 1 5869745236789564123656897485236589785412
    careerfunction.com. IN DS 63267 1 1 6326739963267399632673996326739963267399
    laaraa.com. IN DS 45632 1 1 6565788980009087546456558814434135697645
    fatblack-sekai.info. IN DS 46239 1 1 8659796995795649986986869895955499595595
    niceandsharealstate.net. IN DS 65535 1 1 8888888888888888888888888888888888888888
    r2webtech.com. IN DS 1 1 1 9237923792379237923792379237923792379237
    gwaliortimes.in. IN DS 65535 1 1 9425738101942573810194257381019425738101
    poggyaservices.in. IN DS 6887 1 1 9665649035966564903596656490359665649035
    dvdschool.in. IN DS 45678 1 1 9878765413594321222346789009797543214567

There also some clearly made up values that are not all digits:

    0jl.com. IN DS 100 1 1 0123456789abcdef0123456789abcdef01234567
    noblezahotel.com. IN DS 1424 1 1 1111111111aaaaaaaaaa2222222222bbbbbbbbbb
    cardiagen.com. IN DS 2525 1 1 79843759877573822131098790129872653abcde 
    interpro-books.biz. IN DS 123 1 1 a123456789012345678911234567892123456789

No idea why people would just "make up" (non-)random DS records for
their domains, but for some reason some do.  These made-up DS RRs
are present for 56 out of the 139 domains with RSAMD5 DS RRs, but
only rootcanary.net actually has RSAMD5 keys.

Basically, the RSAMD5 DS RRs are toxic waste that often never worked,
or if they ever did, no longer match reality, rootcanary.net aside.

-- 
	Viktor.

---

From: Hugo Salgado-Hernández <[email-masked]>
Date: Thu, 6 Dec 2018 10:26:55 -0300

> their domains, but for some reason some do.  These made-up DS RRs

Could it be a bad (or nonexistent) validation in user input?

I've seen customers putting hostnames, google validation tokens
and even ftp passwords in DS fields.

Hugo

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Dec 2018 15:59:43 -0500

> and even ftp passwords in DS fields.

Well, the questionable values are well formed, they just have a
surprising "entropy deficit", which one would not expect in a SHA-1
or SHA256 output.  So syntactic input validation is unlikely to
catch this.

To prevent crappy DS records, the registrar or registry would need
to check that the zone contains a matching key (matching key tag
and hash value) before publishing the DS record.  In the examples
I posted, it seems clear that the values were accepted as-is,
without confirmation via the zone's DNSKEY RRset.

IIRC some registrars don't support direct input of DS records,
rather they accept DNSKEY RRs, and compute the DS.  That would
preclude some of the more creative junk values.  Of course one can
still upload a junk RSA key.  Junk keys are a bit more difficult
with ECDSA and EdDSA because keys have a fixed size and can be
validated as for correctness, here the worst one can do is use a
public key with a well known (example) or already leaked private
key.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 7 Dec 2018 08:19:17 +1100

> On 7 Dec 2018, at 7:59 am, Viktor Dukhovni <[email-masked]> wrote:
> 

Well if registries don’t care about checking NS and GLUE records
for consistency why would they check DS/DNSKEY pairs?

Garbage in - garbage out.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 6 Dec 2018 16:38:32 -0500

On 2018-12-06 15:59 -0500, Viktor Dukhovni wrote:> To prevent crappy DS 
records, the registrar or registry would need
> and hash value) before publishing the DS record. 

That would then prohibit prepublishing the DS record in advance of the 
DNSKEY one as it happens for some scenarios ("standby" key for 
emergencies for example).

See https://tools.ietf.org/html/rfc7583#section-3.3.2

DNSSEC data through EPP can be also done during the domain:create at 
which point obviously the domain name does not resolve yet and hence 
there are no DNSKEY to check, but you may still want to publish a DS 
record in advance.

See https://datatracker.ietf.org/doc/html/rfc4310#section-3.2.1

> rather they accept DNSKEY RRs, and compute the DS.  

Some registries also allow only DNSKEY and deal with DS records themselves.
Some others ask registrars to send DNSKEY + DS, probably in order to 
double check the DS was computed correctly.
-- 
Patrick Mevzek