WikiStart: Signing_report.txt

Line 
1
2 Intro:
3
4 The signing tests used two different zones, in two different modes,
5 without opt-in and with.
6
7 There where 4 different signers used in this test:
8 jdns_signzone, ldns_signzone, pdns_signzone, Bind dnssec-signzone-9.5-pre
9
10 In this report the names of the actual signers will be obfuscated,
11 signers will be referred to as S1, S2, S3, S4 (not the same order as
12 above).
13
14 Structure:
15
16 In the signing test all signers used the same signing parameters
17   Signature Inception time: 20060919000000
18   Signature Expiration time: 20061231000000
19   TTL on all RRsets:         3600
20   NSEC3 iterations:          10
21   NSEC3 salt:                AFFE  (hex value)
22   same DNSKEY's              2 keys of alg 5
23                              2 keys of alg 133
24
25 By doing this the resulting zones where "directly" comparable,
26
27 The first zone used [REF1] had 10 different names including
28 apex, there were single label names, multiple label names and a
29 wild-card at multi-label name. There were delegations in the zone,
30 with and without DS records.
31
32 The second zone was an empty zone (only data at APEX).
33
34 Expected Results:
35 David Blacka had written a "zone normalizer" to convert the zones to a
36 standard format that then could be compared by diff to find any
37 discrepancies.
38
39 Actual Results:
40 The normalizer turned out to have two issues in processing the zones,
41 from various signers. The first issue was mixing of cases in names,
42 the second issue was ordering of RRSIG's covering a RRset.
43 Both issues have been addressed.
44 The initial report from the normalizer was that all zones differed.
45
46 At this point two humans where assigned to figure out the differences
47 in the zones, and what was correct.
48
49 John's tests
50 Checked the empty zones first. Visual check that all the signed zones
51 had the same
52     number of each type of RR
53     NSEC3-PARAM
54     hashes in the NSEC3 RR's
55     signatures in the RRSIG's
56     TTL's in all RR's
57
58 Several of the signatures had been done with incorrect
59 parameters. These were resigned. and the checks repeated.
60 Some signers signed zone with both algorithms and some only with alg
61 133. The room determined that this was an open issue that should not
62 be used to judge the signers validity.
63
64
65 Olafur's tests:
66 Started work on the non-empty zones, he wrote scripts to check the
67 consistency of the NSEC3 chains and if the NSEC3's matched the
68 NSEC3PARAM record at the apex. 
69 The scripts evolved from simply putting out the NSEC3 records to
70 actually checking the chain no matter what order provided.
71
72 Errors seen:
73 For the empty zones S2 and S1 were found to agree. S4 was found to use
74 the wrong TTL for DNSKEY's and S3 did not create a NSEC3-PARAM RR or
75 its RRSIG.
76
77 for the non-empty zones:
78 One implementation S4 did not include an NSEC3PARAM.
79 One implementation S1 had the right number of NSEC3 records but
80 multiple NSEC3's pointed to the same target.
81
82
83 Second run:
84 After reporting these results the developers sat down and updated
85 their signers to address the issues.
86
87 After second round of zone signing 3 of the signers  (S1, S2, S3)
88 agree on what should be in the NSEC3PARAM record and in the NSEC3
89 chain. S4 agrees with the the others on the NSEC3 chain but does not
90 include that NSEC3PARAM record in the zone.
91
92 At this point the opt-out zones where tested and they all passed, all
93 opted out the same name and had the same NSEC3 chain.
94
95 Conclusions:
96   (any difference between expected and actual results)
97
98 Signers agree on what NSEC3 records should be for the same NSEC3
99 settings. All of the signers generate NSEC3 from input flags or signer
100 configuration file.
101 Most of the issues seen where addressed and fixed at the workshop. S4
102 addressed their issue after testing completed.
103
104 Open issues:
105 Signing algorithms used. There is an open issue what to do if there are
106 both algorithm 133 and 5 DNSKEY records present.
107 Some singers sign with both algorithms but do NOT include NSEC chain.
108 One signer (S1) does not include the DNSKEY RR's with algorithm 5 when
109 instructed to generate NSEC3 chain.
110
111 DNSKEY record with algorithm 5 requires RRSIG's on the zone and/or
112 NSEC chain. What does it mean to have NSEC and NSEC3 specific DNSKEY
113 algorithms listed in the DNSKEY set at the apex?
114
115 Nit:
116 Some singers put their name and version into the signed zone, others
117 did not. Testers found the presence implementation information useful.
118
119
120  
121
122