Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec
Hi, A possible format issue: >[RFC6840] brings a few additions into the core of DNSSEC. It makes >NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes >the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of >the core as well. # Cryptographic Algorithms and DNSSEC > >Cryptography improves over time, and new algorithms get adopted by >various Internet protocols. Two new signing algorithms have been >adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080]. >The GOST signing algorithm [RFC5933] was also adopted, but has seen >very limited use, likely because it is a national algorithm specific >to a very small number of countries. > >Implementation developers who want to know which algorithms to >implement in DNSSEC software should refer to [RFC8624]. Note that >this specification is only about what algorithms should and should >not be included in implementations: it is not advice for which >algorithms that zone operators should and should not sign with, nor >which algorithms recursive resolver operators should or should not >validate. Based on the context, the format should probably be: >[RFC6840] brings a few additions into the core of DNSSEC. It makes >NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes >the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of >the core as well. > > 2.2 Cryptographic Algorithms and DNSSEC > >Cryptography improves over time, and new algorithms get adopted by >various Internet protocols. Two new signing algorithms have been >adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080]. >The GOST signing algorithm [RFC5933] was also adopted, but has seen >very limited use, likely because it is a national algorithm specific >to a very small number of countries. > >Implementation developers who want to know which algorithms to >implement in DNSSEC software should refer to [RFC8624]. Note that >this specification is only about what algorithms should and should >not be included in implementations: it is not advice for which >algorithms that zone operators should and should not sign with, nor >which algorithms recursive resolver operators should or should not >validate. Since the description above mainly focuses on the new cryptography adopted by DNSSEC, I think it would make more sense to use title like: Additional Cryptographic Algorithms in DNSSEC — During my reading of DNS and DNSSEC, I found another RFC (RFC 7129) very helpful in understanding the motivation from NSEC to NSEC3, besides RFC 5155, but it is not listed in the draft above (maybe because it is for informational purposes?). https://datatracker.ietf.org/doc/rfc7129/ <https://datatracker.ietf.org/doc/rfc7129/> Thanks. -- Joey Deng > On Mar 24, 2022, at 4:26 PM, dnsop-requ...@ietf.org wrote: > > [DNSOP] Call for Adoption: DNSSEC as BCP: > draft-hoffman-dnssec ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The serial arithmetic involved in the comparison of the inception and expiration timestamp of RRSIG record
Hello,
[RFC 4034 3.1.5. Signature Expiration and Inception
Fields](https://datatracker.ietf.org/doc/html/rfc4034#section-3.1.5) says:
> The Signature Expiration and Inception field values specify a date and time
> in the form of a 32-bit unsigned number of seconds elapsed since 1 January
> 1970 00:00:00 UTC
The description above seems to indicate that the two values in the RRSIG are
**absolute** values, and they can be compared directly:
```c
// Example 1
# inception is smaller than expiration
if (inception < expiration) {
// Do something.
}
# expiration is greater than inception
if (expiration > inception) {
// Do something.
}
# Comapre the current time with the two timestamps.
const uint32_t now_uint32 = (uint32_t)time(NULL);
if (now_uint32 >= inception && now_uint32 <= expiration) {
// RRSIG time valid
} else {
// RRSIG time invalid
}
```
However, it also says:
> An RRSIG RR can have an Expiration field value that is numerically smaller
> than the Inception field value if the expiration field value is near the
> 32-bit wrap-around point or if the signature is long lived. Because of this,
> all comparisons involving these fields MUST use "Serial number arithmetic",
> as defined in [RFC1982].
The description above seems to indicate that the two values in the RRSIG are
**relative** values, and they can only be compared with [Serial number
arithmetic](https://datatracker.ietf.org/doc/html/rfc1982):
```c
// Example 2
# inception is smaller than expiration
if (((int32_t)(inception - expiration)) < 0) {
// Do something.
}
# expiration is greater than inception
if (((int32_t)(expiration - inception)) > 0) {
// Do something.
}
# Compare the current time with two timestamps.
const uint32_t now_uint32 = (uint32_t)time(NULL);
if (((int32_t)(now_uint32 - inception)) >= 0 && ((int32_t)(expiration -
now_uint32)) >= 0) {
// RRSIG time valid
} else {
// RRSIG time invalid
}
```
## Questions
Therefore, my questions are:
1. Are the two descriptions in the RFC 4034 mentioned above contradictory with
each other?
2. How to compare `inception` and `expiration` correctly? (For example, if
`example 2` I mentioned above is correct?)
3. If we have a value `inception` returned by `time(NULL)`, how can we get a
value `expiration` that indicates the RRSIG will be valid for 68 years? (Of
course the RRSIG should never be valid for a so long time)
For example, something like `const uint32_t expiration =
(uint32_t)((int32_t)inception + INT32_MAX)`?
Thanks.
--
Joey Deng
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Why does RFC 4035 allows a security-aware authoritative name server to not send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response?
Hello, In RFC 4035 3.1.1. Including RRSIG RRs in a Response, it says: >When responding to a query that has the DO bit set, a security-aware >authoritative name server SHOULD attempt to send RRSIG RRs that a >security-aware resolver can use to authenticate the RRsets in the >response. A name server SHOULD make every attempt to keep the RRset >and its associated RRSIG(s) together in a response. Inclusion of >RRSIG RRs in a response is subject to the following rules: All the statements above use SHOULD, which means RECOMMENDED, which means that there exists valid reasons in particular circumstances to NOT SEND RRSIG RRs with the RRSet in the response. However, the paragraph below it uses MUST: > o When placing a signed RRset in the Answer section, the name server > MUST also place its RRSIG RRs in the Answer section. The RRSIG > RRs have a higher priority for inclusion than any other RRsets > that may have to be included. If space does not permit inclusion > of these RRSIG RRs, the name server MUST set the TC bit. It would be very helpful if someone could help me understand this SHOULD/MUST behavior difference 1. What are the particular circumstances in which a name server is allowed to do that? 2. One case I can think of is truncation, is truncation the only situation allowed to not include RRSIG? 3. If the name server is allowed to only include the RRSet, how could the security-aware resolver fetch the missing RRSIG separately (A specific RFC would be very helpful!)? (I tried to use dig to send query for RRSIG explicitly, but it seems that the name server will only return partial result or no result for the RRSIG query, so I guess the result of RRSIG query is similar to the result of type ANY query?). Thanks. -- Joey Deng ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] How does NSEC record(s) prove the Name Error?
_dmarc.ietf.org. If we follow the steps described by [RFC 4035 5.4. Authenticated Denial of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), we will find that: wwwtest.ietf.org. -> xml2rfc.ietf.org. tells us that the exact name match for .ietf.org does not exist, since it appears in-between the two names. Therefore, the remaining ietf.org. -> _dmarc.ietf.org. NSEC should be used to prove that “no possible wildcard RRset exists that could have been used to generate a positive response” for the name .ietf.org <http://.ietf.org/>. Therefore, my question is: How can ietf.org. -> _dmarc.ietf.org NSEC be used to prove that there is no wildcard record for the name .ietf.org? Do we need to prove that all the possible sources of synthesis for .ietf.org <http://.ietf.org/> appear in-between ietf.org. and _dmarc.ietf.org <http://dmarc.ietf.org/>? Or do we only need to prove that *.ietf.org <http://ietf.org/> appears in-between ietf.org. and _dmarc.ietf.org <http://dmarc.ietf.org/>? If so why do we choose *.ietf.org <http://ietf.org/> instead of *.org or *? Thanks. -- Joey Deng ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Real world examples that contain DNSSEC secure `Wildcard Answer` or `Wildcard No Data`
.com. RRSIG NSEC IThinkItShouldNeverExist.cloudflare.com. 300 IN RRSIG NSEC 13 3 300 20211023002429 20211020222429 34505 cloudflare.com. FbjDF2mF4pQrGJTDS/Ylo3ObhmrQUN7Jw601m/hz2A9nO4ZzOXfTR5ue G1CKy37Q9NuX7zBm8qyCnQbntO/q6w== ;; Query time: 4 msec ``` Note that the `labels` field of RRSIG is 3 instead of 2 for the wildcard answer, which means this record is created by using online signing, I guess? Therefore it is not what I expect to see. --- Could you give me some real world examples that contain DNSSEC Secure `Wildcard Answer` or `Wildcard No Data` as described by [RFC4035 3.1.3. Including NSEC RRs in a Response](https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3)? Thanks. -- Joey Deng ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
