[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.
On Sun, 19 May 2024, Steve Crocker wrote: [speaking as individual only] In my view, an algorithm moves through seven phases during its lifecycle. 1. Experimental – defined and included in the IANA registry 2. Adopted – begin inclusion in validation suite 3. Available – ok to use for signing 4. Mainstream – recommended for signing 5. Phaseout – transition to newer signing algorithm 6. Deprecated – signing should have stopped 7. Obsolete – ok to remove from validation suite This is a very theoretical transition in an ideal world. But that's not how things have gone in the past. GOST went from 3 to 7. SHA1 went from 5 to an unlisted state of "6 but avoid because broken at some OSes". Also you can't have validation without signing so implementation wise 2 and 3 are the same state. There is also no "Mainstream". For example some crowds need to follow FIPS, while other crowds try to avoid FIPS algoritms. There is also a huge difference in "supported by no one uses it" and "mainstream". An example over at TLS/IPsec, right now PCI DSS got rid of ffDH. Is that now no longer Mainstream or is it still Mainstream ? I think it is better to just have humans evaluate every few years and come up more flexible transitions. Sometimes that means it doesn't follow the above 7 steps though in general you'd hope something along these lines things would be done. Each transition from one phase to another should be controlled by an expert group that advises IANA. (In some cases, an algorithm might be deprecated before reaching the "Mainstream" stage.) There is a lot of interaction based on certifications, payment industries, webPKI, laws and cryptographic research. Comment: In the recent Red Hat snafu, I heard a comment that it was not possible to disable use of an algorithm for signing without also disabling the algorithm for validation. Note everything is possible. It is just that the system's crypto parameters are being controlled centrally using "crypto-policies" and require manual tweaking to work. See "man crypto-policies". For example on the fedora-40 version of crypto-policies: DEFAULT The DEFAULT policy is a reasonable default policy for today’s standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they are at least 2048 bits long. This policy provides at least 112-bit security with the exception of allowing SHA-1 signatures in DNSSec where they are still prevalent. Older versions of the crypto-policies had "sha1_in_dnssec" as option, but the current man page states to use the @DNSSec keyword instead: sha1_in_dnssec: Allow SHA1 usage in DNSSec protocol even if it is not present in the hash and sign lists (recommended replacements: hash@DNSSec, sign@DNSSec). Hence, when Red Hat wanted to shut off use of an algorithm for signing, it removed it from the crypto suite and thus disabled validation. It's more complicated. It disabled it but the dns software initially all just got crypto errors for the verify operations and thus returned ServFail. One had to recompile with --no-sha1 to ensure sha1 signatures were treated as unsigned data and skipped validation and were returned to the client without AD bit set - avoiding the servfail. Then DNS software started probing for working/not-working algo and handle this more dynamically. While it's understable that a straightforward implementation of a crypto suite might provide the same path to an algorithm irrespective of whether it will be used for signing or validation, it is possible provide distinct paths for these two uses and thereby permit validation but not signing during phases 2 and 6 at the beginning and end of the algorithm's life cycle. The problem lies in certifcations. If you have "some uses allowed" it becomes extremely complicated to prove you are compliant, and you have to make a case to auditors to prove "not doing this makes the system only weaker, and we guarantee this extra code doesn't cause different consumers from accidentally validating this". Yes, your 7 step program is great theory. But in practise it just won't be happening that often. Just like people tend to ignore our advise until something breaks and only then will they update their configs/OS/regulations. SHA1 was signing was "NOT RECOMMENDED" since June 2019. In October 2020 RSASHA1 finally got mostly turned off. In June 2021 there were still 2M RSASHA1-NSEC3 which finally got mostly turned off in Oct 2021. Are those the points where we could have said NO to sha1? Based on numbers yes, but what if a super important domain would still be using sha1 then? As such, I don't see a value in publishing an RFC with this lifecycle recommendation. It is already known and taken as input. But when the rubber meets the road we have to do things. I think one of the things we haven't done well (with DNSSEC, IPsec and to
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Actually, we are developing an unrelated scheme that has need of the same zone structure for signaling but not involving DNSSEC itself, and would see some advantage in utilizing the same standard top level underscore naming for signaling use in general. Would you want to put the signal info in the same zones with the DNSSEC stuff? If not, you don't want the same tag. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
[another (last) attempt of reposting this as it did not get delivered to dnsop@ietf.org on May 7, as evidenced by the list archive] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
[reposting as it did not get delivered to dnsop@ietf.org, as evidenced by the list archive] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes
On Mon, 6 May 2024, Petr Špaček wrote: R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200]. Operational impact of this recommendation is unclear. Why? Because clients belong to several sets: - One set clients cannot receive fragmented answers, Good because it has been proven to be very insecure. - another set of clients cannot use TCP to overcome unfragmented UDP size limitations, TCP is a mandatory part of DNS now, so I'm not sure how much sympathy I would have. If I were a flagday person, I'd call a flagday for this :P - yet another set of clients actually depend on large answers to function (say because they DNSSEC validate, or need to follow huge NS sets geneated by MS AD, or they need large RRs to deliver e-mail, or ...). You mean, those exact records with value to attack using DNS fragments. Is the right operational concern to keep them vulnerable instead of breaking them to fix it to avoid a security issue? Why wait for a specific attack to come out before giving up on these dangerously broken clients? It's unclear what proportion of clients belong to intersection of these three sets. Banning fragmentation on the **outgoing** side might break these clients, and it's extremely hard to measure and debug from the server side. Breaking them _also_ ensures they can't be victim of fragmentation attacks. R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. At the time of writing, most DNS server software did not set the DF bit for IPv4, and many operating systems' kernels constraint make it difficult to set the DF bit in all cases. E.g. on Linux socket API does not expose DF bit directly. Application can request DF bit to be turned on in outgoing packets but at the same time this implicitly enables receipt and processing of unauthenticated ICMP messages. These messages can be used to manipulate Path MTU records in the kernel and mount attacks misusing this technique. That's clear, and someone should take this up with the linux-net people? R3. UDP responders SHOULD compose response packets that fit in the minimum of the offered requestor's maximum UDP payload size [RFC6891], the interface MTU, the network MTU value configured by the knowledge of the network operators, and the RECOMMENDED maximum DNS/UDP payload size 1400. (See Appendix A for more information.) In practice doing syscall to determine MTU _estimate_ for every single peer address is impractical, and in most cases the value exposed by kernel is just a garbage anyway. It's more practical to assume that outgoing EDNS buffer size is configured to a reasonable lower bound by system admin. I don't think it is asking for a syscall here is it? It is saying the minimum of: 1) ENDS0 option value received 2) interface MTU 3) Preset network MTU by admin in config 4) 1400 Only 2) would require some syscalls but those are per interface so not per packet, and one could listen for interface changes to reread these. What syscalls do you think are impractical? R4. If the UDP responder detects an immediate error indicating that the UDP packet cannot be sent beyond the path MTU size, the UDP responder MAY recreate response packets fit in the path MTU size, or with the TC bit set. Same note about MTU determination applies here. TC=1 sounds reasonable and does not require more guesswork or reconstructing and recompressing the answer packet. Once you did the above calcuation, wouldn't you just use that result? I think you are both not saying things too different? eg you are building the packet, know the max size (from above) and start adding additional records, until you run out of space? Or if you are still writing mandatory data (eg Answer or Authority Section), you set TC=1 ? R5. UDP requestors SHOULD limit the requestor's maximum UDP payload size. It SHOULD use a limit of 1400 bytes, but a smaller limit MAY be used. (See Appendix A for more information.) Some operators have better experience with 1400, others with other values. We at ISC go with lower value of 1232 because it's easier to have conservative value which is more likely to work. Debugging this in production is total pain, and using a bit smaller value is in our limited experience not causing new issues. That's why we went with lower values. Let the implementers pick the value. They have the most experience dealing with support calls. I was assuming the WG discussed this at length, but perhaps it didn't :) R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. AFAIK this is impossible to do using normal socket API. The application has no access to information about UDP reassembly. I imagine some userland stacks like DPDK could possibly enforce this. Having said that, even if it was implementable it's IMHO not the best advice for requestor. IF the requestor is able to detect that a fragment was
