- dane-users - list.sys4.de

DANE presentation (in German)
by Patrick Ben Koetter 30 Jan '15

30 Jan '15

For those interested in DANE in general. If you understand German you might want to check out the presentation I gave at the DENIC Jahrestagung in September 2014. SMTP Sicherheit mit DANE https://www.youtube.com/watch?v=NuU8hbQjxWU p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

3 3

is this "normal" if not what to do about it?
by John 27 Jan '15

27 Jan '15

my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months. Is this a problem, and if so what do I do about it. The following dates were found in the source record and the output from dig. source record dig KSK -A 20150126163534 20150117012252 KSK -I 20150225173534 20150225144654 ZSK -A 20150126163534 20150126173534 ZSK -I 20150527015028 20150225173534 -- John Allen KLaM ------------------------------------------ If you are out to describe the truth, leave elegance to the tailor.

4 12

DNSSEC intervals
by John 23 Jan '15

23 Jan '15

I have been tying to find out if there are any recommendations about the various intervals in a keys life, e.g. how long between publication and activation? Ditto for activation to inactivation? Ditto for inactivation to deletion? I Googled it, but the info out there is not very helpful; Microsoft; 7 - 7300 days (recommends 755 days) for KSK and 7 to 1875 days (recommends 90 days) for ZSK. ENISA 365-1460 days (recommends 1 yr) KSK, 1 yr for ZSK NIST 1 - 2 yrs for KSK, 1 - 3 m for ZSK. Plus a lot of other recommendations ranging from 1 to 5yrs for KSK and from 14 days to 2 yrs for ZSK. I am currently think along the lines of 90 days from Creation to Deletion with active life of 30 days for ZSKs. 420 days from Creation to Deletion with an active life of 360 days for KSKs. Are these reasonable? Plus, what are the "names" for the various intervals, there does not seem to be a consistent naming convention, the various points in the timeline seem to have fairly standard names but not intervals. What is the period from creation to publication called? ditto publication to activation, activation to inactivation, inactivation to deletion? -- John Allen KLaM ------------------------------------------ You are off the edge of the map, mate. Here there be monsters!

4 5

DNSSEC key rollover
by John 23 Jan '15

23 Jan '15

I wrote myself a small bash script to handle ZSK rollover, it might handle KSK but I have tried it. All it does is to setup for a DNSSEC-keygen. My idea is to automatically pick a ZSK and use it as the base for the next key set, as per the -S param in DNSSEC-keygen. The only real additions are the calculation of an Inactivation and a Deletion date based upon the new keys Activation date retrieved from the base key. I use a param which I call the "active life" (Active - Inactive) and a second param called "retirement" (Inactive - deletion). A couple of questions: Does anybody know if key rolling is going to be part of Bind (as part of maintain/inline) maybe? Has the been any discussion on basing the +/-nn part of the date/time params, not on today, but on one of the existing params when the -S option is used? -- John Allen KLaM ------------------------------------------ Inside every older person is a younger person wondering what the hell happened!!

6 9

Postfix-Frage
by Frank Fiene 20 Jan '15

20 Jan '15

Something else: Beside my own actually not working DANE configuration, if i setup Postfix with smtpd_use_tls = yes smtp_tls_security_level = dane smtp_dns_support_level = dnssec i should see „Verified“ and „Untrusted“ TLS connections, right? There are appearing only „Anonymous“ connections as before. Regards! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene(a)veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster

11 22

Re: Algorithm rollover - OOOOPS!!!
by John 20 Jan '15

20 Jan '15

On 1/17/2015 11:11 AM, Carsten Strotmann wrote: > doing an DNSSEC algorithm rollover is not simple. To my knowledge there > is currently not software support for algorithm rollovers. Therefor it > is important to choose a good algorithm in the beginning. Choosing an algorithm is probable one of the more important decision to be made in the planning stage. I think my mistake was choosing the "wrong" algorithm. Overall under estimating the complexity of implementing DNSSEC and over confidence in my ability to implement it were my biggest problems. Fortunately I started with my lab rat DNS, and the only people affected were family and some friends. > RFC 6781, 4.1.4 describes the steps for such a rollover in detail (I > mention this here for admins that want to start an algorithm rollover > and come across this post): https://tools.ietf.org/html/rfc6781 Yep, I read this camel of a document. > > The Czech TLD registry did an algorithm rollover in 2010 and documented > their findings -> http://www.ripe.net/ripe/meetings/regional-meetings/moscow-2010/DNSSEC20101… > I totally agree with them - plan , plan - rehearse rehearse rehearse. -- John Allen KLaM ------------------------------------------ definition: Camel, a horse designed by a committee.

1 0

Aliasing a domain any implications for DNSSEC/DANE
by John 18 Jan '15

18 Jan '15

I originally thought of using dname records for the domain aliases and cname records for the TLSA records. But for this to work I would need to enable recursion on the authoritative server. I understand that for very good reasons this is considered a very bad idea., therefor I wont go tin this direction. As an alternative I a considering using the same zone file for all three zones. I assume that i should only have maintain and inline on the main domain domain entry in bind. Is this the "best" way of aliasing? What gotchas should I be aware of? -- John Allen KLaM ------------------------------------------ Save the whales. Collect the whole set.

2 9

Algorithm rollover
by John 17 Jan '15

17 Jan '15

This may be the wrong mailing list but I cannot find another concerning DNSSEC general. When I originally setup DNSSEC I used the RSASHA1 algorithm as this seemed to be the only one that could be used with NSEC3. However, further reading (and/or changes in DNSSEC) would indicate the RSASHA256... can also be used with NSEC3. As a result I would like change algorithm. I am using my families domain rather than a /live/ domain for testing which would seem to give me one of two options. 1) delete the keys that have been published including the .ca (? forgotten tech term), publish new keys for the site and wait for the dust to settle. As the site is small, not heavily used and does not support anything critical this may be the simplest solution. Problem, I don't learn anything! 2) generate new keys, publish them as new for rollover at all levels including TLD (?), on the date the current keys become inactive (or new keys become active) resign the domain. I am not sure that 2 is correct, and additionally I am not sure that I want to take the delay. ? -- John Allen KLaM ------------------------------------------ OK, so what is the speed of dark?

2 3

ANN: tlsa.info and dane.sys4.de merge
by Patrick Ben Koetter 17 Jan '15

17 Jan '15

Greetings! Yesterday night we merged tlsa.info and dane.sys4.de. Since then visitors to https://www.tlsa.info will be redirected to https://dane.sys4.de permanently. When Jan Münnich from dotplex <https://www.dotplex.de> set up tlsa.info there was no working DANE test site at all. And although the test suite at tlsa.info did only DNS based checks it became the most important DANE test site within short. From Viktor's surveys tlsa.info accounts for the largest number of DANE validated domains. Viktor and Jan had been in private conversation for a while. When Viktor told him we were planning to create a validator that fully checks DANE functionality Jan offered to merge the sites. Our DANE validator benefits from tlsa.info's popularity. Visitors to tlsa.info get to benefit from our validators functionality. One checker less to visit when you take out to create a working DANE policy. Thank you for this exceptional donation, Jan! p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

1 0

What would you like to read about DANE on the test site?
by Patrick Ben Koetter 16 Jan '15

16 Jan '15

Greetings, one of the tasks until v1 is a page/are some pages, that lets visitors of the test site read more about DANE. What would you want to read about DANE? Things that come to my mind are: - What is DANE? - Which problems does it solve? - How does it work? - Which SMTP software supports DANE? Please feel free to comment. I'd like to come up with something useful for those who want to read into DANE. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

4 9