resolve: add support for RFC 8080 #7600

ott · 2017-12-10T01:41:19Z

RFC 8080 describes how to use EdDSA keys and signatures in DNSSEC. It
uses the curves Ed25519 and Ed448. Libgcrypt 1.8.1 does not support
Ed448, so only the Ed25519 is supported at the moment. Once Libgcrypt
supports Ed448, support for it can be trivially added to resolve.

ott · 2017-12-10T01:46:02Z

src/resolve/resolved-dns-dnssec.c

+        } else
+                fclose(f);
+
+        switch (rrsig->rrsig.algorithm) {


The control flow within dnssec_verify_rrset is somewhat complicated. I would appreciate if someone verify that it's correct.

poettering

looks really good. Just some minor fixups

poettering · 2017-12-11T12:37:54Z

src/resolve/resolved-dns-dnssec.c

-                return -EIO;
+        f = open_memstream(&sig_data, &sig_size);
+        if (!f)
+                return -ENOMEM;


hmm, given that this is somewhat performance-sensitive I figure it would be low-hanging but worthy to call __fsetlocking(f, FSETLOCKING_BYCALLER) on the memstream, to turn off all locking on it. For just concatenating a few bytes we really shouldn't pay the hefty locking price stdio makes us pay normally

poettering · 2017-12-11T12:38:44Z

src/resolve/resolved-dns-dnssec.c

+        if (ferror(f)) {
+                fclose(f);
+                free(sig_data);
+                return -ENOMEM;


please use fflush_and_check() like everywhere else for this

poettering · 2017-12-11T12:39:55Z

src/resolve/resolved-dns-dnssec.c

@@ -613,6 +707,9 @@ int dnssec_verify_rrset(
        gcry_md_hd_t md = NULL;
        int r, md_algorithm;
        size_t k, n = 0;
+        FILE *f = NULL;
+        size_t sig_size = 0;


Please use cleanup_free and cleanup_fclose on these and avoid manual freeing/closing

poettering · 2017-12-11T12:41:07Z

src/resolve/resolved-dns-dnssec.c

@@ -445,9 +530,18 @@ static void md_add_uint16(gcry_md_hd_t md, uint16_t v) {
        gcry_md_write(md, &v, sizeof(v));
 }

-static void md_add_uint32(gcry_md_hd_t md, uint32_t v) {
+static size_t fwrite_uint8(uint8_t v, FILE *fp) {


could you swap the two args please? libc is weird that fputc() take the argument first, and the object to operate on second, but we really shouldn't replicate that here...

poettering · 2017-12-11T12:41:18Z

src/resolve/resolved-dns-dnssec.c

+        return fwrite(&v, sizeof(v), 1, fp);
+}
+
+static size_t fwrite_uint16(uint16_t v, FILE *fp) {


poettering · 2017-12-11T12:41:24Z

src/resolve/resolved-dns-dnssec.c

+        return fwrite(&v, sizeof(v), 1, fp);
+}
+
+static size_t fwrite_uint32(uint32_t v, FILE *fp) {


poettering · 2017-12-11T12:42:08Z

src/resolve/resolved-dns-rr.h

@@ -57,6 +57,8 @@ enum {
        DNSSEC_ALGORITHM_ECC_GOST = 12,        /* RFC 5933 */
        DNSSEC_ALGORITHM_ECDSAP256SHA256 = 13, /* RFC 6605 */
        DNSSEC_ALGORITHM_ECDSAP384SHA384 = 14, /* RFC 6605 */
+        DNSSEC_ALGORITHM_ED25519 = 15,


please add the RFC number as comment for this too!

ott · 2017-12-11T17:13:17Z

I did incorporate the comments.

ott · 2017-12-11T17:15:37Z

src/resolve/resolved-dns-dnssec.c

@@ -613,6 +711,9 @@ int dnssec_verify_rrset(
        gcry_md_hd_t md = NULL;
        int r, md_algorithm;
        size_t k, n = 0;
+        size_t sig_size = 0;
+        _cleanup_free_ char *sig_data = NULL;


free has to be called after fclose. The GCC documentation for the cleanup attribute does not state in which order the functions are called. I only found a Google+ post by Lennart Poettering that claims that they are called “in order”, presumably in the reverse order of declaration. I would like to avoid that we depend on undefined behaviour as the wrong order caused a memory corruption when I tested it.

well, we do that all over the place already by ordering the declarations properly, so by doing this you are not going to break anything new...

Moreover the gcc C cleanup stuff is pretty much identical to the C++ destructor logic, and exposes the same semantics. And for C++ the standard is very explicit about the destruction order, see https://stackoverflow.com/a/2254306

poettering · 2017-12-11T19:52:34Z

src/resolve/resolved-dns-dnssec.c

@@ -445,9 +534,18 @@ static void md_add_uint16(gcry_md_hd_t md, uint16_t v) {
        gcry_md_write(md, &v, sizeof(v));
 }

-static void md_add_uint32(gcry_md_hd_t md, uint32_t v) {
+static size_t fwrite_uint8(FILE *fp, uint8_t v) {
+        return fwrite(&v, sizeof(v), 1, fp);


hmm, thinking about this, these function prototypes are actually weird since they are declared size_t, but will only return 0 or 1... (that's because fwrite() returns the "nmemb" paramater on success, not the first. It's kinda strange to return a "size_t" if we never actually return anything non-binary there... dunno.

Given that we don't care about the return value, and these functions are static anyway, I am pretty sure it would make more senseto just return void here...

poettering · 2017-12-11T19:53:14Z

src/resolve/resolved-dns-dnssec.c

-        hash = gcry_md_read(md, 0);
-        if (!hash) {
-                r = -EIO;
+        if (fflush_and_check(f))


r = fflush_and_check(f); if (r < 0) return r;

ott · 2017-12-11T20:07:33Z

I incorporated the comments.

poettering · 2017-12-11T20:57:56Z

src/resolve/resolved-dns-dnssec.c

-                r = -EIO;
+        r = fflush_and_check(f);
+        if (r < 0)
+                return -ENOMEM;


why not return r?

poettering · 2017-12-11T21:01:34Z

Patch looks good to me, but the semaphore CI does not: does that work correctly locally for you?

(maybe semaphore's gcrypt is too old for this. Might be worth skipping the test if gcrypt doesn't know the EC algs yet)

DS: example.com. IN DS 3613 15 2 dda6b969bdfb79f71ee7b7fbdfb7dcd7adbbd35ddf79ed3b6dd7f6e356ddd747f76f5f7ae1a6f9e5cefc7bbf5adf4e1b
MX: example.com. IN MX 10 mail.example.com.
RRSIG: example.com. IN RRSIG MX ED25519 2 3600 20150819220000 20150729220000 3613 example.com. 
        oL9krJun7xfBOIWcGHi7mag5/hdZrKWw15jPGrHpjQeRAvTdszaPD+QLs3fx8A4M3e23mRZ
        9VrbpMngwcrqNAg==
Assertion 'dnssec_verify_rrset(answer, mx->key, rrsig, dnskey, rrsig->rrsig.inception * USEC_PER_SEC, &result) >= 0' failed at ../src/resolve/test-dnssec.c:211, function test_dnssec_verify_rfc8080_ed25519_example1(). Aborting.
-------

Full log written to /home/runner/systemd/build/meson-logs/testlog.txt
FAILED: meson-test 
/usr/bin/python3 -u /home/runner/.local/bin/meson test --no-rebuild --print-errorlogs
ninja: build stopped: subcommand failed.

ott · 2017-12-11T21:24:07Z

I successfully built systemd on Debian Stretch. It includes Libgcrypt 1.7.6 and test-dnssec runs without problems. I think Semaphore CI uses 1.7.8. Can you run libgcrypt-config --version and libgcrypt-config --algorithms as part of the build on Semaphore CI?

poettering · 2017-12-11T22:16:55Z

hmm, best would be to just add some versioning printing code to the test case, and then push it to see what version it is. That's how I'd do this myself at least...

ott · 2017-12-11T23:17:51Z

Semaphore CI uses Libgcrypt 1.5.3. Ed25519 support was introduced 1.5.4. If you install the libgcrypt20-dev package, version 1.7.6 should be used on Ubuntu 17.04.

poettering · 2017-12-11T23:31:06Z

@martinpitt any chance you can update the libgrcypt package for the semaphore CI?

@ott I think it would make sense to change the test case for now to simply skip testing this bit if gcrypt doesn't support the algorithm. That way, we can merge your patch now, and as soon as @martinpitt does the CI update we'll test it on semaphore too. Note that semaphore isn't out only CI, we also test on current development ubuntu (which should hvae the new gcrypt) , hence it's entirely OK if one CI only tests a subset of what there is to test..

if you change the test as suggested, please change it so that the availability of the algorithm is tested itself, rather than a version check, to cover for backporting distros...

poettering · 2017-12-11T23:32:36Z

hmm, i see you just updated the patch already. test version check doesn't look too bad, hence i figure it's ok to leave it as is.

RFC 8080 describes how to use EdDSA keys and signatures in DNSSEC. It uses the curves Ed25519 and Ed448. Libgcrypt 1.8.1 does not support Ed448, so only the Ed25519 is supported at the moment. Once Libgcrypt supports Ed448, support for it can be trivially added to resolve.

ott · 2017-12-11T23:33:30Z

I included a check that checks that Libgcrypt is at least version 1.6.0 before it enables EdDSA support.

martinpitt · 2017-12-12T07:03:38Z

Semaphore CI uses Libgcrypt 1.5.3. Ed25519 support was introduced 1.5.4.

No, semaphore uses version 1.6.1 (in Ubuntu 14.04), so in theory that should satisfy the check #if GCRYPT_VERSION_NUMBER >= 0x010600 that you added here. If 1.6.1 is not enough, can you please bump the version in that check? I can then backport a newer one.

ott · 2017-12-12T15:26:52Z

You can see in build 6 of Semaphore CI of this pull request that it uses Libgcrypt 1.5.6.

I successfully built and tested systemd with Libgcrypt 1.6.0. The configuration was as follows:

version:1.6.0:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
threads:undefined:
hwflist:
fips-mode:y:n:
rng-type:fips:2:

The build on Semaphore CI is also successful now. test-dnssec also seems to have passed on artful-s390x, xenial-amd64 and artful-i386. I'm unsure what the problem with Fedora Rawhide CI x86_64 is.

poettering · 2017-12-12T15:29:00Z

CI failures are unrelated (KVM and dpkg locking issues)

poettering · 2017-12-12T15:29:57Z

looks good. merging

ott · 2017-12-12T15:30:53Z

It is possible that Libgcrypt was compiled without EdDSA support. But it can be also compiled without RSA, ECDSA or SHA support and we don't check for that. We could test that via gcry_pk_test_algo and so on. I can make this a separate pull request though.

ott commented Dec 10, 2017

View reviewed changes

yuwata added the resolve label Dec 10, 2017

poettering requested changes Dec 11, 2017

View reviewed changes

poettering added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Dec 11, 2017

ott commented Dec 11, 2017

View reviewed changes

poettering requested changes Dec 11, 2017

View reviewed changes

poettering reviewed Dec 11, 2017

View reviewed changes

src/resolve/resolved-dns-dnssec.c Outdated

r = -EIO;

r = fflush_and_check(f);

if (r < 0)

return -ENOMEM;

Copy link

Member

poettering Dec 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not return r?

poettering removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Dec 12, 2017

poettering merged commit cb9eeb0 into systemd:master Dec 12, 2017

resolve: add support for RFC 8080 #7600

resolve: add support for RFC 8080 #7600

ott commented Dec 10, 2017

ott Dec 10, 2017 •

edited

poettering left a comment

poettering Dec 11, 2017

poettering Dec 11, 2017

poettering Dec 11, 2017

poettering Dec 11, 2017

poettering Dec 11, 2017

poettering Dec 11, 2017

poettering Dec 11, 2017

ott commented Dec 11, 2017

ott Dec 11, 2017

poettering Dec 11, 2017 •

edited

poettering Dec 11, 2017

poettering Dec 11, 2017

ott commented Dec 11, 2017

poettering Dec 11, 2017

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

poettering commented Dec 11, 2017

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

martinpitt commented Dec 12, 2017

ott commented Dec 12, 2017

poettering commented Dec 12, 2017

poettering commented Dec 12, 2017

ott commented Dec 12, 2017

resolve: add support for RFC 8080 #7600

resolve: add support for RFC 8080 #7600

Conversation

ott commented Dec 10, 2017

ott Dec 10, 2017 • edited

Choose a reason for hiding this comment

poettering left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ott commented Dec 11, 2017

Choose a reason for hiding this comment

poettering Dec 11, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ott commented Dec 11, 2017

Choose a reason for hiding this comment

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

poettering commented Dec 11, 2017

poettering commented Dec 11, 2017

ott commented Dec 11, 2017

martinpitt commented Dec 12, 2017

ott commented Dec 12, 2017

poettering commented Dec 12, 2017

poettering commented Dec 12, 2017

ott commented Dec 12, 2017

ott Dec 10, 2017 •

edited

poettering Dec 11, 2017 •

edited