[DNSOP] Alexey Melnikov's No Objection on draft-ietf-dnsop-dns-capture-format-09: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-dnsop-dns-capture-format-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ -- COMMENT: -- Thank you for addressing my DISCUSS and comments. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-dns-capture-format-09.txt
Hi All, We’ve published an updated version of the draft that we hope addresses all the points raised in the reviews apart from describing the new IANA requirements for allocating/extending the various fields (and a couple of idnits). We are working on a version to include that and hope to publish it next week. Please let us know if any other updates are needed. Best regards Sara. > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-09.txt > Date: 30 November 2018 at 18:36:00 GMT > To: > Cc: dnsop@ietf.org > Reply-To: dnsop@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > >Title : C-DNS: A DNS Packet Capture Format >Authors : John Dickinson > Jim Hague > Sara Dickinson > Terry Manderson > John Bond > Filename: draft-ietf-dnsop-dns-capture-format-09.txt > Pages : 74 > Date: 2018-11-30 > > Abstract: > This document describes a data representation for collections of DNS > messages. The format is designed for efficient storage and > transmission of large packet captures of DNS traffic; it attempts to > minimize the size of such packet capture files but retain the full > DNS message contents along with the most useful transport metadata. > It is intended to assist with the development of DNS traffic > monitoring applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : C-DNS: A DNS Packet Capture Format Authors : John Dickinson Jim Hague Sara Dickinson Terry Manderson John Bond Filename: draft-ietf-dnsop-dns-capture-format-09.txt Pages : 74 Date: 2018-11-30 Abstract: This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic monitoring applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-09 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
On Fri, 30 Nov 2018, Ted Lemon wrote: Separately, on the topic of provisioning, the right answer here is to just say that the whitelist is installed with the provisioning profile, and not recommend a UI flow. It's the recommendation for the UI flow that I'm objecting to. There is no "recommendation". There is a MAY clause: To determine this, an implementation MAY interactively ask the user when a VPN profile is installed or activated to confirm this. Alternatively, it MAY provide a special override keyword in its provisioning configuration to ensure non-interactive agreement can be achieved only by the party provisioning the VPN client, who presumbly is a trusted entity by the end-user. It seems our views differ here, which I would say is covered by the MAY not being a SHOULD/MUST or RECOMMEND. This is a bad security practice that is slowly falling into disfavor. I admit I'm ahead of the curve on this, but the writing is on the wall, and again, I'm not asking for ponies here. I disagree and find your reasoning a little conflicting. Your proposal is to always leave the user uninformed, ensuring that all users might not be aware of anything. This gives individuals who would recognise "do you agree to whitelist gmail.com" for VPN provider Cheap Access Inc no more notification to stop installing the provisioning changes. I explained big company's like Apple already do this when installing a Root CA as part of a provisioning step, and it seems logical to do the same for DNSSEC based trust anchors as we do for WebPKI based trust anchors. I agree that if you are going to use the whitelist method, you need to install it somehow. I am glad we agree there :) I do not agree that you need to advise implementors to do something which, while presently common, is actually a bad practice. I hope my explanation above about not recommending it but not forbidding it either is good enough for both of us. Paul On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters wrote: On Thu, 29 Nov 2018, Ted Lemon wrote: > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters wrote: > How could the use case be more constrained without breaking functionality? > > I discussed this in detail in several previous posts, e.g.: > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I Well, you argued for changing things so much that it breaks functionality :) And you would require the VPN client to have some kind of DNSSEC resolving capability before the tunnel is setup. And if those checks need to be done during tunnel setup then there is also a significant delay that would affect on-demand tunnels. I especially disagree with your text: I think that we should let the field tell us before figuring out how to solve that problem. > I explained this in the previous posts. I would be happy (really!) to help improve the text, but it would be a significant change, and I'm getting the impression from > Warren that he would like to not do that.. More specifically, the enterprise use case should not be further changed to a more manual problem. In our previous discussions, both with the list and the Security AD, we made it clear that this is as far as we can go without destroying the enterprise use case. That is, let the provisioning provide the list of names for override, give software a chance to warn, and treat it otherwise as trusted enterprise provisioning. It is up to the implementations on how or where they would support internal trust anchors. For example a phone OS could limit this via "enterprise managed" phone modes only and not allow "emailed profiles" to have these trust points. >> Have you ever installed a Configuration Profile on iOS device? If your profile contains a VPN profile which contains a PkCS12 it will warn (entity installing this >> can monitor all your traffic) and show you the root CA. > > Yes. That's a very bad UI flow. It means that I can just hand you a configuration profile to install, and you can install it easily. And you will install it—you're > installing it because you want to get something, and when you're presented with "ok" or "cancel," it's going to be very clear to you that "ok" will get you whatever it > is that you want, and "cancel" will not get you what you want. So even offering the user this choice has created a gigantic attack surface.. I think of UIs like this > as "social engineering enablement UIs." Well, this is where rubber meets the road. There is nothing I can come up with that will be rejected by the people who want to see dancing hamsters or playful kittens. An enterprise can hand out phones that
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
On Fri, 30 Nov 2018, Ted Lemon wrote: Suppose you have a company that has a subdomain that's internal (this is the case where they control the delegation). The way you make this work is that you publish a signed delegation to the internal zone. That means your public DNS zone must be signed for your internal DNS zone to be signed? Otherwise you cannot have this signed delegation? That would mean you cannot run DNSSEC internally before you run it externally. When you look things up in that zone outside the firewall, you get NXDOMAIN for everything but the SOA on the zone, which returns an old serial number. Inside the firewall, they get answers, which are signed, and which validate. There's no need for a special trust anchor here. This scheme seems to require both inside and outside zones are signed with the same key, or as Mark pointed out, both internal and external zones need to share their DS records and keep these in sync. As these are usually different organisations/groups/vendors/services, that is an actual management problem. I do not think a protocol should require this manual effort, or add requirements for where to run DNSSEC first in an organisation. So that works if the zone being queried is just nonexistent outside the firewall. If the zone looks different outside the firewall than inside the firewall, it's a bit more complicated, but essentially similar. With similar problems as above. There are two ways to approach this. One is to assume that the validator never checks the SOA on the zone. This is almost certainly the case for nearly any use case. In that case, you just run the internal and external name servers with the same ZSK, and have a delegation above it. You don't worry about zone serial numbers, because they don't affect validation. When you're inside the VPN, you get answers for the internal zone; when you're outside the vpn, you get answers for the outside. Both validate, because the DS record(s) are referring to the same ZSK(s). coordinating shared ZSK's is even harder then requiring sharing DS records! ZSKs roll every month, and a lot of software auto-generates and performs the roll without any humans involved. It seems extremely fragile to need to coordinate ZSKs between different organisations, be ready for the same algorithm rollovers, etc etc. So in this case, there is no need for a special trust anchor, and using one makes you substantially less secure, and hence is not something we should be advising. I think your proposal is far to fragile to suggest in real enterprise deployments. Paul On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters wrote: On Thu, 29 Nov 2018, Ted Lemon wrote: > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters wrote: > How could the use case be more constrained without breaking functionality? > > I discussed this in detail in several previous posts, e.g.: > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I Well, you argued for changing things so much that it breaks functionality :) And you would require the VPN client to have some kind of DNSSEC resolving capability before the tunnel is setup. And if those checks need to be done during tunnel setup then there is also a significant delay that would affect on-demand tunnels. I especially disagree with your text: I think that we should let the field tell us before figuring out how to solve that problem. > I explained this in the previous posts. I would be happy (really!) to help improve the text, but it would be a significant change, and I'm getting the impression from > Warren that he would like to not do that.. More specifically, the enterprise use case should not be further changed to a more manual problem. In our previous discussions, both with the list and the Security AD, we made it clear that this is as far as we can go without destroying the enterprise use case. That is, let the provisioning provide the list of names for override, give software a chance to warn, and treat it otherwise as trusted enterprise provisioning. It is up to the implementations on how or where they would support internal trust anchors. For example a phone OS could limit this via "enterprise managed" phone modes only and not allow "emailed profiles" to have these trust points. >> Have you ever installed a Configuration Profile on iOS device? If your profile contains a VPN profile which contains a PkCS12 it will warn (entity installing this >> can monitor all your traffic) and show you the root CA. > > Yes. That's a very bad UI flow. It means that I can just hand you a configuration profile to install, and you can install it easily. And you will
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
Separately, on the topic of provisioning, the right answer here is to just say that the whitelist is installed with the provisioning profile, and not recommend a UI flow. It's the recommendation for the UI flow that I'm objecting to. This is a bad security practice that is slowly falling into disfavor. I admit I'm ahead of the curve on this, but the writing is on the wall, and again, I'm not asking for ponies here. I agree that if you are going to use the whitelist method, you need to install it somehow. I do not agree that you need to advise implementors to do something which, while presently common, is actually a bad practice. On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters wrote: > On Thu, 29 Nov 2018, Ted Lemon wrote: > > > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters wrote: > > How could the use case be more constrained without breaking > functionality? > > > > I discussed this in detail in several previous posts, e.g.: > > > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk > > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I > > Well, you argued for changing things so much that it breaks > functionality :) And you would require the VPN client to have > some kind of DNSSEC resolving capability before the tunnel is > setup. And if those checks need to be done during tunnel setup > then there is also a significant delay that would affect on-demand > tunnels. > > I especially disagree with your text: > > I think that we should let the field tell us before figuring out > how to solve that problem. > > > I explained this in the previous posts. I would be happy (really!) to > help improve the text, but it would be a significant change, and I'm > getting the impression from > > Warren that he would like to not do that.. > > More specifically, the enterprise use case should not be further changed > to a more manual problem. In our previous discussions, both with the list > and the Security AD, we made it clear that this is as far as we can go > without destroying the enterprise use case. That is, let the provisioning > provide the list of names for override, give software a chance to warn, > and treat it otherwise as trusted enterprise provisioning. It is up to > the implementations on how or where they would support internal trust > anchors. For example a phone OS could limit this via "enterprise managed" > phone modes only and not allow "emailed profiles" to have these trust > points. > > >> Have you ever installed a Configuration Profile on iOS device? If your > profile contains a VPN profile which contains a PkCS12 it will warn (entity > installing this > >> can monitor all your traffic) and show you the root CA. > > > > Yes. That's a very bad UI flow. It means that I can just hand you a > configuration profile to install, and you can install it easily. And you > will install it—you're > > installing it because you want to get something, and when you're > presented with "ok" or "cancel," it's going to be very clear to you that > "ok" will get you whatever it > > is that you want, and "cancel" will not get you what you want. So even > offering the user this choice has created a gigantic attack surface.. I > think of UIs like this > > as "social engineering enablement UIs." > > Well, this is where rubber meets the road. There is nothing I can come > up with that will be rejected by the people who want to see dancing > hamsters or playful kittens. An enterprise can hand out phones that > are restricted with respect to provisioning and they can control it > as they see fit. If such an enterprise wants to support BYOD, they > can choose to forbid these trust anchors on those phones and/or > limit those VPN connections in other ways. > > If you let random internet companies install profiles with various > kinds of super powers, no RFC in the world will stop them. > > Paul > > > > > > > The idea of the text is that this can be similarly done and > warning you about the domains whitelisted. That would help if it suddenly > lists gmail.com or > > yahoo.com. I believe this adds value and is better than not > presenting the whitelist. Ignorant users will just click click click > regardless and knowledgeable > > users can go “wait a minute” > > > > > > I assume that knowledgable users will do the right thing if given the > right information; often these dialogs do not actually give the right > information. But it's the > > ignorant users I actually care about, because there are probably three > or four orders of magnitude more of them. As a knowledgable user, UIs > like this actually create > > a lot of stress for me, because they never actually tell me what they're > going to do, and yet I know that if they are doing something other than > what I hope they are > > doing, clicking "yes" will create a new attack surface on my device. > So I usually click "no," even though it's probably okay to click "yes." >
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
Paul, I think it is a bit much to accuse me of wanting a pony here. Suppose you have a company that has a subdomain that's internal (this is the case where they control the delegation). The way you make this work is that you publish a signed delegation to the internal zone. When you look things up in that zone outside the firewall, you get NXDOMAIN for everything but the SOA on the zone, which returns an old serial number. Inside the firewall, they get answers, which are signed, and which validate. There's no need for a special trust anchor here. So that works if the zone being queried is just nonexistent outside the firewall. If the zone looks different outside the firewall than inside the firewall, it's a bit more complicated, but essentially similar. There are two ways to approach this. One is to assume that the validator never checks the SOA on the zone. This is almost certainly the case for nearly any use case. In that case, you just run the internal and external name servers with the same ZSK, and have a delegation above it. You don't worry about zone serial numbers, because they don't affect validation. When you're inside the VPN, you get answers for the internal zone; when you're outside the vpn, you get answers for the outside. Both validate, because the DS record(s) are referring to the same ZSK(s). If you really care about SOAs being accurate, then you need to update the zones in lockstep: the external zone will always have a different serial number than the internal zone, and they will always differ by one, with the internal zone being the larger number. Whenever you make a change to either zone, you increment the serial numbers on both zones. Answers from the internal zone will always have the higher serial number, and therefore be preferred. So in this case, there is no need for a special trust anchor, and using one makes you substantially less secure, and hence is not something we should be advising. On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters wrote: > On Thu, 29 Nov 2018, Ted Lemon wrote: > > > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters wrote: > > How could the use case be more constrained without breaking > functionality? > > > > I discussed this in detail in several previous posts, e.g.: > > > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk > > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I > > Well, you argued for changing things so much that it breaks > functionality :) And you would require the VPN client to have > some kind of DNSSEC resolving capability before the tunnel is > setup. And if those checks need to be done during tunnel setup > then there is also a significant delay that would affect on-demand > tunnels. > > I especially disagree with your text: > > I think that we should let the field tell us before figuring out > how to solve that problem. > > > I explained this in the previous posts. I would be happy (really!) to > help improve the text, but it would be a significant change, and I'm > getting the impression from > > Warren that he would like to not do that.. > > More specifically, the enterprise use case should not be further changed > to a more manual problem. In our previous discussions, both with the list > and the Security AD, we made it clear that this is as far as we can go > without destroying the enterprise use case. That is, let the provisioning > provide the list of names for override, give software a chance to warn, > and treat it otherwise as trusted enterprise provisioning. It is up to > the implementations on how or where they would support internal trust > anchors. For example a phone OS could limit this via "enterprise managed" > phone modes only and not allow "emailed profiles" to have these trust > points. > > >> Have you ever installed a Configuration Profile on iOS device? If your > profile contains a VPN profile which contains a PkCS12 it will warn (entity > installing this > >> can monitor all your traffic) and show you the root CA. > > > > Yes. That's a very bad UI flow. It means that I can just hand you a > configuration profile to install, and you can install it easily. And you > will install it—you're > > installing it because you want to get something, and when you're > presented with "ok" or "cancel," it's going to be very clear to you that > "ok" will get you whatever it > > is that you want, and "cancel" will not get you what you want. So even > offering the user this choice has created a gigantic attack surface.. I > think of UIs like this > > as "social engineering enablement UIs." > > Well, this is where rubber meets the road. There is nothing I can come > up with that will be rejected by the people who want to see dancing > hamsters or playful kittens. An enterprise can hand out phones that > are restricted with respect to provisioning and they can control it > as they see fit. If such an enterprise wants to support BYOD,
Re: [DNSOP] request for adoption
Paul Wouters writes: > On Tue, 27 Nov 2018, Petr Špaček wrote: > >>> MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] MG >>> 8 a mail group member (EXPERIMENTAL) [RFC1035] MR 9 a >>> mail rename domain name (EXPERIMENTAL) [RFC1035] >> >> >> Is there any *technical* use for this field? Do we need it in the YANG >> model? > > The technical reason would be "It's dead Jim! Don't bother implementing this" > > But if people pick up the yang model and it has all these obsolete > entries, those people in turn will start some basic implementation / > support of these. So I understand yang is not the group that should They should not, if they follow RFC 7950: o "obsolete" means that the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. But again, the question is whether OBSOLETE in IANA registries means the same thing. > make this decision, hence my thought of quickly adding a column to the > registry to obsolete/deprecate so that yang can skip these. > >> Maybe we can just omit it while transforming the registry into model and >> be done with it ... > > But then people think the yang model is incomplete? Yes, I think it is important to keep the 1-1 mapping between the registry and YANG module. Enums tagged as obsolete should be no problem for implementors of the module, and clients of management protocols such as NETCONF cannot expect anything else from the server than an error, if they use such an enum value. Lada > > Paul > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
On Thu, 29 Nov 2018, Ted Lemon wrote: On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters wrote: How could the use case be more constrained without breaking functionality? I discussed this in detail in several previous posts, e.g.: https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I Well, you argued for changing things so much that it breaks functionality :) And you would require the VPN client to have some kind of DNSSEC resolving capability before the tunnel is setup. And if those checks need to be done during tunnel setup then there is also a significant delay that would affect on-demand tunnels. I especially disagree with your text: I think that we should let the field tell us before figuring out how to solve that problem. I explained this in the previous posts. I would be happy (really!) to help improve the text, but it would be a significant change, and I'm getting the impression from Warren that he would like to not do that.. More specifically, the enterprise use case should not be further changed to a more manual problem. In our previous discussions, both with the list and the Security AD, we made it clear that this is as far as we can go without destroying the enterprise use case. That is, let the provisioning provide the list of names for override, give software a chance to warn, and treat it otherwise as trusted enterprise provisioning. It is up to the implementations on how or where they would support internal trust anchors. For example a phone OS could limit this via "enterprise managed" phone modes only and not allow "emailed profiles" to have these trust points. Have you ever installed a Configuration Profile on iOS device? If your profile contains a VPN profile which contains a PkCS12 it will warn (entity installing this can monitor all your traffic) and show you the root CA. Yes. That's a very bad UI flow. It means that I can just hand you a configuration profile to install, and you can install it easily. And you will install it—you're installing it because you want to get something, and when you're presented with "ok" or "cancel," it's going to be very clear to you that "ok" will get you whatever it is that you want, and "cancel" will not get you what you want. So even offering the user this choice has created a gigantic attack surface.. I think of UIs like this as "social engineering enablement UIs." Well, this is where rubber meets the road. There is nothing I can come up with that will be rejected by the people who want to see dancing hamsters or playful kittens. An enterprise can hand out phones that are restricted with respect to provisioning and they can control it as they see fit. If such an enterprise wants to support BYOD, they can choose to forbid these trust anchors on those phones and/or limit those VPN connections in other ways. If you let random internet companies install profiles with various kinds of super powers, no RFC in the world will stop them. Paul The idea of the text is that this can be similarly done and warning you about the domains whitelisted. That would help if it suddenly lists gmail.com or yahoo.com. I believe this adds value and is better than not presenting the whitelist. Ignorant users will just click click click regardless and knowledgeable users can go “wait a minute” I assume that knowledgable users will do the right thing if given the right information; often these dialogs do not actually give the right information. But it's the ignorant users I actually care about, because there are probably three or four orders of magnitude more of them. As a knowledgable user, UIs like this actually create a lot of stress for me, because they never actually tell me what they're going to do, and yet I know that if they are doing something other than what I hope they are doing, clicking "yes" will create a new attack surface on my device. So I usually click "no," even though it's probably okay to click "yes." If we want devices to be more secure, we have to come up with UI flows that get the user what they need without forcing them to choose between "win and get hacked" and "lose and don't get hacked." ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
On Thu, 29 Nov 2018, Petr Špaček wrote: I'm wondering if we could add NXDOMAIN mandatory check and accept INTERNAL_DNSSEC_TA only if "external DNS server" resolves given name to NXDOMAIN. You cannot do that. Imagine .company being run locally and publicly. They might still be different zones. While it would be ideal for companies to put all their non-public stuff in one internal zone (eg corp.example.com), we cannot and should not require them to do so. Although we surely recommend them to do so. It seems to me that it would eliminate most problematic cases like com. hijack etc. And introduce lots of new ones :) Only problem I can see are cases where "external view" actually serves non-NXDOMAIN answers - I have no idea how common is that. And I don't know how we would find out how common that is. What do you think? I think in an ideal world, yes. but on this internet, no :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Waiting for DNSSEC...
On 05. 11. 18 19:30, Tony Finch wrote: > Mukund Sivaraman wrote: >> On Fri, Nov 02, 2018 at 02:30:15PM -0400, Viktor Dukhovni wrote: >>> >>> To move DNSSEC adoption higher, CDS/CDNSKEY/... need to be supported >>> by most registries and the signing and key rollover tooling needs >>> to become less brittle and more user-friendly. > > Yes! > >>> Updates of ZSKs are still too manual. For example, BIND's "auto-dnssec >>> maintain" should be able to automatically generate new ZSKs on >>> master server from time to time, completely without user intervention. > > Knot DNS's automated key handling is quite a lot further ahead in > usability. It's a great example. Details for reference: https://www.knot-dns.cz/docs/2.7/html/configuration.html#dnssec-automatic-ksk-management or here http://ripe75.ripe.net/wp-content/uploads/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf (including the registry side) >> There is a part-protocol part-tooling issue in DNSSEC. A mistake in >> configuration (operator) or software bug (developer) is capable of >> making validation of answers unusable (DoS) for a long period of time. > > I hope that better automation will make it harder to make mistakes, > especially since the automation should includes checks to prevent bad > configurations from screwing things up. Bugs notwithstanding :-) Automation will certainly help, e.g. with problems like http://smoogespace.blogspot.com/2017/09/fedora-project-outage-rca-dns-outage.html -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
