From ldns at xtaz.co.uk Mon Aug 17 19:49:33 2015 From: ldns at xtaz.co.uk (Matt Smith) Date: Mon, 17 Aug 2015 20:49:33 +0100 Subject: [ldns-users] ldns-signzone ECDSA random failure Message-ID: <20150817194933.GA1277@xtaz.uk> Hi, I've been using Unbound, NSD, and the ldns tools for a long time now succesfully signing zones for DNSSEC using algorithm 8 RSA keys. I've never had a single issue with this. I've been experimenting with using algorithm 13 ECDSA keys instead and keep hitting the same issue. Most of the time everything works as expected, the zone is signed, and unbound can validate it. Occasionally though I'll sign the zone and then notice the following failure: Aug 17 20:23:43 tao unbound: [96007:0] info: validation failure : use of signature for ECDSA crypto failed from 10.0.0.10 This will only affect maybe 1 or 2 records within the zone. Every other record in the zone will succesfully validate. If I resign the zone again then everything will either go back to normal or a different record might fail this time. It's completely random. If it helps I have saved copies of the syslog, KSK and ZSK keys along with the original zone file and the signed zone file if anybody wants to examine them. The commands I've been running are pretty standard: ldns-keygen -a ECDSAP256SHA256 -b 256 -k example.com ldns-keygen -a ECDSAP256SHA256 -b 256 example.com SALT=`head -c 512 /dev/random | sha1 | cut -b 1-16` ldns-signzone -n -t 10 -s $SALT $KSK $ZSK -- Matt From ldns at xtaz.co.uk Mon Aug 17 20:05:55 2015 From: ldns at xtaz.co.uk (Matt Smith) Date: Mon, 17 Aug 2015 21:05:55 +0100 Subject: [ldns-users] ldns-signzone ECDSA random failure In-Reply-To: <20150817194933.GA1277@xtaz.uk> References: <20150817194933.GA1277@xtaz.uk> Message-ID: <20150817200555.GA97201@xtaz.uk> On Aug 17 20:49, Matt Smith wrote: >If it helps I have saved copies of the syslog, KSK and ZSK keys along >with the original zone file and the signed zone file if anybody wants >to examine them. Actually I've just noticed something that stands out. In a record which works fine the RRSIG looks like this: host1.example.com. 3600 IN RRSIG A 13 3 3600 20150914191810 20150817191810 57320 xtaz.uk. ot+ASP55jXoBrNNqxT5yr3KIO/n+YazEc4NEq0/IpwhB4BucBRiBAiKihAdELzSf+CDTr2X7v8TiqE59mNBeSg== In one that fails to validate it looks like this: host2.example.com. 3600 IN RRSIG A 13 3 3600 20150914191810 20150817191810 57320 xtaz.uk. T0zvO7h5yAxTg5TqtGUAZqdsbj3T4EsvoWDzYOe4QaD/QJKs4eCvBwlLQ2DaQpxNIhd9oOqTWgLeeGL7aRwA It looks like the signature has been truncated and doesn't have == on the end of it? Forgot to say as well, I'm using ldns-tools 1.6.17. -- Matt From wouter at nlnetlabs.nl Tue Aug 18 08:12:02 2015 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 18 Aug 2015 10:12:02 +0200 Subject: [ldns-users] ldns-signzone ECDSA random failure In-Reply-To: <20150817200555.GA97201@xtaz.uk> References: <20150817194933.GA1277@xtaz.uk> <20150817200555.GA97201@xtaz.uk> Message-ID: <55D2E8D2.60608@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Matt On 17/08/15 22:05, Matt Smith wrote: > On Aug 17 20:49, Matt Smith wrote: >> If it helps I have saved copies of the syslog, KSK and ZSK keys >> along with the original zone file and the signed zone file if >> anybody wants to examine them. > > Actually I've just noticed something that stands out. In a record > which works fine the RRSIG looks like this: Thank you for the details, I have worked out that the shorter RRSIG is wrong. It is generated because ldns is omitting leading zeroes when generating the signature encoding, but the RFC mandates equal length parts (of length curvebits / 8). The fix is in git and basically adds leading zeroes to the created RRSIG . Because ecdsa signatures have a randomised component, this only happens when the leading bytes randomly happen to be zero. The ldns_convert_ecdsa_rrsig_asn12rdf is therefore not capable of generating good signatures, and is removed, replaced with ldns_convert_ecdsa_rrsig_asn1len2rdf that takes the curve length as a function call parameter. Best regards, Wouter > > host1.example.com. 3600 IN RRSIG A 13 3 3600 > 20150914191810 20150817191810 57320 xtaz.uk. > ot+ASP55jXoBrNNqxT5yr3KIO/n+YazEc4NEq0/IpwhB4BucBRiBAiKihAdELzSf+CDTr2 X7v8TiqE59mNBeSg== > > > > In one that fails to validate it looks like this: > > host2.example.com. 3600 IN RRSIG A 13 3 3600 > 20150914191810 20150817191810 57320 xtaz.uk. > T0zvO7h5yAxTg5TqtGUAZqdsbj3T4EsvoWDzYOe4QaD/QJKs4eCvBwlLQ2DaQpxNIhd9oO qTWgLeeGL7aRwA > > > > It looks like the signature has been truncated and doesn't have == > on the end of it? > > Forgot to say as well, I'm using ldns-tools 1.6.17. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV0ujSAAoJEJ9vHC1+BF+N+5wP/jnr51g5UOVJfOBWGmcJk8Xz uwsvjy43kgW/E3w+2IjPyoNrca1SlyzCGtcrvdNTJ4Mbr9MnN9AXscrrJJSW4oyB omQfzVKic5gO1YPIfomousXzD9BRL6DjBTrX0HkTR6VVB3rnzEBVll7NbC9ulAcY aHcTGXANFmG9/jC8DsVzrMc1E7WY+eqOe5kPFR0dfctZVOt1VysiAHkUahJCAndA uHhBzQ20NxrVv/aYG7j5Y/yK0/KJuEzxHKcwq+kCf88dnReEz3E3JeNUhJVOrY3P G7yyUn2aoW5THjHLzOu1W6Mi97OtbW/iBko5OCM7qz1bK1JjAw29IDsbJdR7r4GJ SnKGqiOtsIRSeeUmTGpkP8p164ID70E/VSED7qqAeCCawajpcLAfeuHOvrxeRpEf t/xNXM+gUqNdgvffRwzs8yM1qlC/Dck1e0Bn0HspF4VaeMhjHfUgT+bHOppP6hMI IcWHzGxN+3FVGW7+SSpENmR8NOZx0XW/fiOdW5tmtu61Hz4RtLvibZ9dqgrV+vRQ /qod5rDuADR7ja7NvLOeamu7E2ww6QTxQJCKx/aWnVKNBa6CHtashvo0p2LksMS8 AbO/Nyna4oUWksSpGN7or4v/ZU2MA+2+/AAd9p76bGCUDDvjDQd9brbfmN7DvC/z 6xb2C3eMV8ls//OkRQj9 =NzIJ -----END PGP SIGNATURE----- From ldns at xtaz.co.uk Tue Aug 18 08:51:26 2015 From: ldns at xtaz.co.uk (Matt Smith) Date: Tue, 18 Aug 2015 09:51:26 +0100 Subject: [ldns-users] ldns-signzone ECDSA random failure In-Reply-To: <55D2E8D2.60608@nlnetlabs.nl> References: <20150817194933.GA1277@xtaz.uk> <20150817200555.GA97201@xtaz.uk> <55D2E8D2.60608@nlnetlabs.nl> Message-ID: <20150818085126.GB97201@xtaz.uk> On Aug 18 10:12, W.C.A. Wijngaards wrote: >Thank you for the details, I have worked out that the shorter RRSIG is >wrong. It is generated because ldns is omitting leading zeroes when >generating the signature encoding, but the RFC mandates equal length >parts (of length curvebits / 8). > >The fix is in git and basically adds leading zeroes to the created RRSIG >. > >Because ecdsa signatures have a randomised component, this only >happens when the leading bytes randomly happen to be zero. > >The ldns_convert_ecdsa_rrsig_asn12rdf is therefore not capable of >generating good signatures, and is removed, replaced with >ldns_convert_ecdsa_rrsig_asn1len2rdf that takes the curve length as a >function call parameter. > >Best regards, Wouter > Hi, excellent! Thank you very much for this. I've applied that patch from git and tested signing a zone around 20 times now and have seen no evidence of any failures this time. So it looks like the patch works fine. Hopefully there are enough other changes in the pipeline to make a new release worthwhile soon which would contain this patch. -- Matt From willem at nlnetlabs.nl Tue Aug 18 13:04:54 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 18 Aug 2015 15:04:54 +0200 Subject: [ldns-users] ldns-signzone ECDSA random failure In-Reply-To: <20150818085126.GB97201@xtaz.uk> References: <20150817194933.GA1277@xtaz.uk> <20150817200555.GA97201@xtaz.uk> <55D2E8D2.60608@nlnetlabs.nl> <20150818085126.GB97201@xtaz.uk> Message-ID: <55D32D76.40408@nlnetlabs.nl> Op 18-08-15 om 10:51 schreef Matt Smith: > On Aug 18 10:12, W.C.A. Wijngaards wrote: >> Thank you for the details, I have worked out that the shorter RRSIG is >> wrong. It is generated because ldns is omitting leading zeroes when >> generating the signature encoding, but the RFC mandates equal length >> parts (of length curvebits / 8). >> >> The fix is in git and basically adds leading zeroes to the created RRSIG >> . >> >> Because ecdsa signatures have a randomised component, this only >> happens when the leading bytes randomly happen to be zero. >> >> The ldns_convert_ecdsa_rrsig_asn12rdf is therefore not capable of >> generating good signatures, and is removed, replaced with >> ldns_convert_ecdsa_rrsig_asn1len2rdf that takes the curve length as a >> function call parameter. >> >> Best regards, Wouter >> > > Hi, excellent! Thank you very much for this. I've applied that patch > from git and tested signing a zone around 20 times now and have seen no > evidence of any failures this time. So it looks like the patch works > fine. Hopefully there are enough other changes in the pipeline to make a > new release worthwhile soon which would contain this patch. There definitely are (for a while). But there are also remaining issues. I cannot promise for a specific date yet but a release does have top priority with me. -- Willem From dot at dotat.at Tue Aug 18 12:54:39 2015 From: dot at dotat.at (Tony Finch) Date: Tue, 18 Aug 2015 13:54:39 +0100 Subject: [ldns-users] ldns-signzone ECDSA random failure In-Reply-To: <55D2E8D2.60608@nlnetlabs.nl> References: <20150817194933.GA1277@xtaz.uk> <20150817200555.GA97201@xtaz.uk> <55D2E8D2.60608@nlnetlabs.nl> Message-ID: W.C.A. Wijngaards wrote: > > Because ecdsa signatures have a randomised component, this only > happens when the leading bytes randomly happen to be zero. Is there an option to use deterministic ECDSA? http://tools.ietf.org/html/rfc6979 Tony. -- f.anthony.n.finch http://dotat.at/ Northwest Fitzroy, Sole, Lundy, Fastnet: Southerly or southwesterly 5 or 6. Slight or moderate. Fair then rain or drizzle. Good, becoming moderate, occasionally poor. From jpmens.dns at gmail.com Tue Aug 25 14:58:34 2015 From: jpmens.dns at gmail.com (Jan-Piet Mens) Date: Tue, 25 Aug 2015 16:58:34 +0200 Subject: [ldns-users] Patch for ldns-keyfetcher Message-ID: <20150825145834.GA5794@tiggr.ww.mens.de> Hello, There's a very nasty bug in ldns-keyfetcher which prevents things like ldns-keyfetcher ... | wc -l from working properly. I discovered this very nasty bug ages ago, but only recently was I able to finally get around to producing this (cough) Jumbo Patch for it. It's been running in production for several hours now without any visible negative impact. As I'm not quite sure whether this list supports huge attachments, I'm adding the patch inline: please excuse the wasted bandwidth. Best regards ;-) -JP --- ldns-1.6.17/examples/ldns-keyfetcher.c.orig 2015-08-25 14:11:06.000000000 +0200 +++ ldns-1.6.17/examples/ldns-keyfetcher.c 2015-08-25 14:18:24.000000000 +0200 @@ -725,7 +725,6 @@ fprintf(stderr, "no answer packet received, stub resolver config:\n"); ldns_resolver_print(stderr, res); } - printf("\n"); ldns_rdf_deep_free(domain); ldns_resolver_deep_free(res); From willem at nlnetlabs.nl Thu Aug 27 09:33:00 2015 From: willem at nlnetlabs.nl (Willem Toorop) Date: Thu, 27 Aug 2015 11:33:00 +0200 Subject: [ldns-users] Patch for ldns-keyfetcher In-Reply-To: <20150825145834.GA5794@tiggr.ww.mens.de> References: <20150825145834.GA5794@tiggr.ww.mens.de> Message-ID: <55DED94C.60905@nlnetlabs.nl> Dear JP, After carefully reviewing this non-trivial patch, we've decided to apply it in its entirety unmodified: http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=e8490145 Thanks again! -- Willem Op 25-08-15 om 16:58 schreef Jan-Piet Mens: > Hello, > > There's a very nasty bug in ldns-keyfetcher which prevents things like > > ldns-keyfetcher ... | wc -l > > from working properly. I discovered this very nasty bug ages ago, but > only recently was I able to finally get around to producing this (cough) > Jumbo Patch for it. It's been running in production for several hours > now without any visible negative impact. > > As I'm not quite sure whether this list supports huge attachments, I'm > adding the patch inline: please excuse the wasted bandwidth. > > Best regards ;-) > > -JP > > --- ldns-1.6.17/examples/ldns-keyfetcher.c.orig 2015-08-25 14:11:06.000000000 +0200 > +++ ldns-1.6.17/examples/ldns-keyfetcher.c 2015-08-25 14:18:24.000000000 +0200 > @@ -725,7 +725,6 @@ > fprintf(stderr, "no answer packet received, stub resolver config:\n"); > ldns_resolver_print(stderr, res); > } > - printf("\n"); > > ldns_rdf_deep_free(domain); > ldns_resolver_deep_free(res); > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >