Re: [IPsec] Suresh Krishnan's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Hi Paul, On Wed, Nov 21, 2018, 12:25 AM Paul Wouters wrote: > On Tue, 20 Nov 2018, Suresh Krishnan wrote: > > > -- > > COMMENT: > > -- > > > > * Sections 3.1 and 7 > > > > I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN > attribute > > would ever be zero. Do you expect someone to send an empty attribute? If > not, > > the attribute definition should be updated in Section 7. > > If the initiator has no domains listed, it can send a zero-length > attribute to indicate support for this feature. The responder can then > decide to include INTERNAL_DNS_DOMAIN replies (non-zero). or perhaps > even indicate support, but no configured domains, with a zero length > reply. > That makes sense. Thanks for clarifying. > Since the draft needs and uses a lot of example domain names, I would > suggest > > using a reserved TLD (e.g. ".example") from BCP32 to build up the > examples > > instead of using registered domain names. > > Yes, others have made similar comments and I will make the changes. > Excellent. Regards Suresh ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Mon, 19 Nov 2018, Alissa Cooper wrote: -- COMMENT: -- Section 5: "Enterprise Certificate Agency" --> I would have expected this to say Enterprise Certificate Authority. Your expectation is correct :) I will fix. "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." Under what exceptional circumstances would it make sense to whitelist a TLD? Is this like if I run Example Corp and I own .example? Exactly. Or if you would use .internal or if Warren gets his way .alt :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Ben Campbell wrote: -- COMMENT: -- - General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved via the private DNS servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? (I've known some IT managers who would think that was a fine idea.) Nothing prevents that. Just like they can run a transparent proxy on port 53 to accomplish the same. When you install a split-tunnel VPN, you place some trust in those enterprise administrators (forced or not) Local policy might of course prevent it. Libreswan allows a client to configure modecfdomains="redhat.com ibm.com" and when connected would not send any DNS queries for catpictures.com to the internal DNS even if the VPN server response contained an INTERNAL_DNS_DOMAIN for catpictures.com. §6: "the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity" How does a client determine the connections are part of the same logical entity? I can think of some ways, but I think the draft should be give some explicit guidance. I think that would be very vendor specific. Some vendors might have hierarchical structures so "Red Hat" can have two VPN connections, others might just do it based on the same remote VPN server ID (eg vpn.redhat.com) I'll add some text similar to this. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Terry Manderson's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Terry Manderson wrote: -- COMMENT: -- Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client MUST be in the administrative control of the VPN provider (I'm not sure I read that in the draft) might be one way out, yet I wonder if this is a case of simply having to trust that the VPN provider does the right thing (as cold as that leaves me) regardless of the words in the document. The defense mechanisms against that are (and I will clarify the text for that): 1) If there is no split-tunnel, then split-DNS payloads MUST be ignored. (this covers the third party VPN providers, but note those services can also specify INTERNAL_IPV4_DNS to take all your queries. Of course, they can see /modify all your packets that have no cryptogrpahic protection beyond the IPsec layer) 2) Don't accept TLDs (and/or wellknown SLDs) This might be easy for com/net/org, but harder for facebook.com or gmail.com) 3) Any DNSSEC trust anchor overrides MUST come in via the provisioning proces and NOT via the IKE protocol. It is step 2) that might require user interaction and is hard to do, but I do not think it is a solvable problem, and note that split-tunnel setups that require split-dns are typically enterprise deployments where you must trust the enterprise. There is some question about 1) being abused, eg offer 0.0.0.0/1 and 128.0.0.0/1 to trick the client into believing it is on split-tunnel even though it is not, but we feel any VPN actor being that malicious can do more evil things secretly after decrypting your traffic anyway, such as a transparent proxy for port 53. That is why we allow INTERNAL_DNS_DOMAIN without the provisioning step, but do not allow INTERNAL_DNSSEC_TA without it being provisioned outside of IKE. Paul Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Spencer Dawkins wrote: -- COMMENT: -- Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains SHOULD be sent to the regular external DNS server. DNS queries for other domains might not be sent to the regular external DNS server? I'm thinking of one, but I'm flat-out guessing. I think you are right, and we are mixing up INTERNAL_IP4_DNS with INTERNAL_DNS_DOMAIN. the idea is that the client can decide to not only use some authoritative internal servers, but also use some recursive internal servers. But I think those should be specified in the exiting INTERNAL_IP4_DNS / INTERNAL_IP6_DNS attributes. I suggest we change the above to: A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains MAY be sent to an internal recursive DNS server specified in an INTERNAL_IP4_DNS or INTERNAL_IP6_DNS Configuration Payload but MAY also be resolved using the client's regular DNS resolving mechanisms outside of the IPsec connection. Tommy, let me know what you think about this change? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Suresh Krishnan's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Suresh Krishnan wrote: -- COMMENT: -- * Sections 3.1 and 7 I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute would ever be zero. Do you expect someone to send an empty attribute? If not, the attribute definition should be updated in Section 7. If the initiator has no domains listed, it can send a zero-length attribute to indicate support for this feature. The responder can then decide to include INTERNAL_DNS_DOMAIN replies (non-zero). or perhaps even indicate support, but no configured domains, with a zero length reply. Since the draft needs and uses a lot of example domain names, I would suggest using a reserved TLD (e.g. ".example") from BCP32 to build up the examples instead of using registered domain names. Yes, others have made similar comments and I will make the changes. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
On Tue, 20 Nov 2018, Warren Kumari wrote: -- DISCUSS: -- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. No, you missed something subtle that clearly needs to stand out more :) What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) This sentence: When only a subset of traffic is routed into a private network using an IPsec SA, these Configuration Payload options can be used to define which private domains are intended to be resolved through the IPsec connection without affecting the client's global DNS resolution. I think we had more explicit text in earlier versions that didn't make the cut on future revisions. I will re-add proper text in Section 4 and the Security Section. and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... There is a whole section on that. https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14#section-5 Specifically: IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains that can be updated out of band. IKE clients with an empty whitelist MUST NOT use any INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- whitelisted domain as an indication that their local configuration may need to be updated out of band. We basically said this is too dangerous to only authenticate via IKE. So now, you need to _also_ do a (remote) configuration update, which presumbly involves some Enterprise management system or humans. The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? What we tried to say was that any generic domain open for any registrant for registration should never be accepted. While if you are Red Hat, maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree that it is difficult to determine this. The idea of the whitelist is that VPN clients will show/confirm/enable the listed DNS domains, so that if Honest Paul's VPN service includes "gmail.com", the enduser can freak out properly. It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? Split-DNS is meant for Enterprise use of actual domains. If your auntie works for Foo Inc., hopefully she can either have Foo's sysadmin configure and install her VPN, or if the admin gives her some kind of profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants to whitelist internal.foo.com" and she would be familiar with using the internal.foo.com domain from the office. Note that our text basically meant to say the IKE software should probably never allow com/net/org/CCtld ever, but that would be difficult to hardcode because we _still_ haven't fixed the PublicSuffix issue :/ Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. What is wavey? -- COMMENT: -- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? It should not think about "through the VPN or not". We had that text originally, but Tero pointed out a lot of Enterprise VPN's can come up on demand. So the initial IKE negotiation could be for 10.1.2.3/32, and include the DNS configuration for the internal auth servers on 192.168.1.1. It needs to
Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03
> On Nov 21, 2018, at 00:54, Yoav Nir wrote: > > Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux > can work, which is why I agree with your conclusion, except for the tweak > that MUST- is also OK. Okay, if one of the expected deployments is 10 year old ikev2 code, then we should add AES-CBC. I don’t know of any ikev2 code not supporting SHA2, so I would still suggest to leave SHA1 behind. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Terry Manderson's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Terry Manderson has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: 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-ipsecme-split-dns/ -- COMMENT: -- Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client MUST be in the administrative control of the VPN provider (I'm not sure I read that in the draft) might be one way out, yet I wonder if this is a case of simply having to trust that the VPN provider does the right thing (as cold as that leaves me) regardless of the words in the document. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: 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-ipsecme-split-dns/ -- COMMENT: -- - General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved via the private DNS servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? (I've known some IT managers who would think that was a fine idea.) §6: "the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity" How does a client determine the connections are part of the same logical entity? I can think of some ways, but I think the draft should be give some explicit guidance. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss 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-ipsecme-split-dns/ -- DISCUSS: -- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. -- COMMENT: -- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: Discuss 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-ipsecme-split-dns/ -- DISCUSS: -- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding what the INTERNAL_DNSSEC_TA bit does - please help allay my fears... -- COMMENT: -- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Spencer Dawkins has entered the following ballot position for draft-ietf-ipsecme-split-dns-14: 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-ipsecme-split-dns/ -- COMMENT: -- Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains SHOULD be sent to the regular external DNS server. DNS queries for other domains might not be sent to the regular external DNS server? I'm thinking of one, but I'm flat-out guessing. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Tero Kivinen wrote:
Yes, as I have seen so many times that people pass strings for
configuration directly from the remote end to the configuration file,
either because of it is easy, or by accident (shellshock, all kind of
CGI issues etc).
That's why we have the Security Considerations:
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
passed to another (DNS) program for processing. As with any network
input, the content SHOULD be considered untrusted and handled
accordingly.
Using wireformat and forcing IKE library to do one line of code to
convert wireformat to restricted presentation format removes that kind
of issues:
Sure, but it would add two conversions that shouldn't be needed at all.
On the other hand generating the wire format from the values coming
from configuration is similarly very easy (provided it comes from
normal config file not from dns configuration file):
Most likely, when automating this, it would be coming from live DNS
output, eg the dig command. And not some new config file syntax for
this. If I wouldnt use files as in my previous email's example, I
would still want to be able to configure it like:
modecfgdns-ds="example.com. IN DS 12345 8 1 BLOB"
But pointing to a file with just DNS RRTYPEs is much easier, especially
if you have 20 internal domains, as most universities seem to have :P
Then you don't have to have duplicate keywords and/or ordening issues,
and you wouldn't have large blobs in your config file. It is just much
easier to create and maintain this in dig command output, so DNS
presentation format.
Presentation format includes things like comments, newlines,
whitespace etc.
That is the reason I do not like to have presentation format inside
the binary wire formats like IKE. We do not need to do string parsing,
or regex processing in IKE library, but to properly parse presentation
format you need to do that.
I think you can do this without regexp Tero :)
going to be in the presentation format. I think most people do use
configuration formats like:
modecfgdns1=1.2.3.4
modecfgdns2=8.8.8.8
modecfgdomain1=example.com
modecfgtadnsseckeytag1=1270
modecfgtadnssecalg1=8
modecfgtadigesttype1=1
modecfgtadigestdata1=506AD3A656...
This would be terrible to generate from live DNS output. Much harder
than "dig ds example.com @internalDNS > dns.txt"
Yes. This is needed. I would actually also would like to have text
explaining can you have comments whitespace, newlines etc inside the
Digest Data or not too, while we are at it. I would expect that most
of the implementations would not necessarely like those and sending
those over the wire is just wasting bytes.
I'm confused what you are suggesting here. You say it should support the
crazy stuff but then suggest implementations will just not support the
crazy stuff?
and so on, instead of:
INTERNAL_DNSSEC_TA(1270,8,1,0x506AD3A656D14D924655877628FFD6A98D7A847E)
It would be:
INTERNAL_DNSSEC_TA("1270 8 1 0x506AD3A656D14D924655877628FFD6A98D7A847E")
Note that here the domain name is not even part of the data. If you were
sending presentation format, it would be nicer:
INTERNAL_DNSSEC_TA("example.com. IN DS 1270 8 1
0x506AD3A656D14D924655877628FFD6A98D7A847E")
And there would be no ordering constraints for INTERNAL_DNSSEC_TA()
needing to immediately follow INTERNAL_DOMAIN()
Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
On Tue, 20 Nov 2018, Michael Richardson wrote: Tero Kivinen wrote: > Presentation format includes things like comments, newlines, > whitespace etc. > That is the reason I do not like to have presentation format inside > the binary wire formats like IKE. We do not need to do string parsing, > or regex processing in IKE library, but to properly parse presentation > format you need to do that. +1 For all the reasons you cited. Parsing wouldn't happen the way Tero envisions this. IKE software like have something like an option that reads RRTYPEs, so that a DNS/VPN administrator can do: dig ds internal.example.com > /etc/ipsec.d/internal.example.com.ds dig ns internal.example.com > /etc/ipsec.d/internal.example.com.ns And put that in a cron job in case they do internal DNSSEC with key rollovers. with a config line in the IKE config that loads these entries. conn example.com modecfgdns=example.com modecfgdns-ns=/etc/ipsec.d/internal.example.com.ns modecfgdns-ds=/etc/ipsec.d/internal.example.com.ds [...] Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Tero Kivinen wrote: > Presentation format includes things like comments, newlines, > whitespace etc. > That is the reason I do not like to have presentation format inside > the binary wire formats like IKE. We do not need to do string parsing, > or regex processing in IKE library, but to properly parse presentation > format you need to do that. +1 For all the reasons you cited. (Mind, I think split-horizon dns is perpetuation of a bad idea from 1989. Unrouted IPv6 for internal use has no split-dns needs, so I don't really care if gateway's will find a way to attack client systems.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Benjamin Kaduk's Yes on draft-ietf-ipsecme-split-dns-14: (with COMMENT)
Paul Wouters writes:
> The authors would have been happy with full presentation format for
> both :)
>
> You were the one that raised an issue that strings would be passed
> carelessly and could be abused by peer's to try and get a shell :P
Yes, as I have seen so many times that people pass strings for
configuration directly from the remote end to the configuration file,
either because of it is easy, or by accident (shellshock, all kind of
CGI issues etc).
Using wireformat and forcing IKE library to do one line of code to
convert wireformat to restricted presentation format removes that kind
of issues:
printf("DS %d %d %d %s\n", unpack("nCCH*", $cfg_payload));
On the other hand generating the wire format from the values coming
from configuration is similarly very easy (provided it comes from
normal config file not from dns configuration file):
$cfg_payload = pack("nCCH*", $dnskey_key_tag, $dnskey_alg,
$digest_type, $digest_data_in_hex);
On the other hand parsing presentation format is much harder issue...
> >
> > INTERNAL_DNSSEC_TA(1270,8,1,"( 506AD3A656 ; comments
> > D14D9246558 ; in file
> > 77628FFD6A98D7A847E ) ; more")
>
> I don't remember that I wanted to have comments. If I did, I certainly
> don't care now and I would be happy to move everything back to DNS
> presentation format.
Presentation format includes things like comments, newlines,
whitespace etc.
That is the reason I do not like to have presentation format inside
the binary wire formats like IKE. We do not need to do string parsing,
or regex processing in IKE library, but to properly parse presentation
format you need to do that.
> I would not want to use wireformat anywhere, because as I argued in the
> past, the IKE daemon is just passing on this information and for it to
> need to convert its DNS configuration, which is guaranteed to be in DNS
> presentation format, it would need to copy some DNS conversion code or
> link against some DNS library to convert it to wire format.
I do not see any reason why the incoming configuration from IKE is
going to be in the presentation format. I think most people do use
configuration formats like:
modecfgdns1=1.2.3.4
modecfgdns2=8.8.8.8
modecfgdomain1=example.com
modecfgtadnsseckeytag1=1270
modecfgtadnssecalg1=8
modecfgtadigesttype1=1
modecfgtadigestdata1=506AD3A656...
or pseudo presentation format (which really isn't presentation format
as it does not allow comments or newlines inside () etc).
modecfgta1=1270 8 1 506AD3A656...
> And a security check could simply reject all characters outside
> [A-Za-z0-9\-_\.]*
For presentation format that is not enough (for example it does not
git rid of comments or newlines and paranthesis), and even then it is
wrong is it does not allow any whitespace. For pseudo simplified
presentation format it is too much, as it allows dash, underline, and
period which are not needed...
> On the other end, passing the DNS information from IKE daemon to the
> system is most likely happening over a DNS presentation API as well, as
> all API's supporting commandline configurations cannot take DNS wire
> format but take DNS presentation format.
As I said converting wire format to simplified presentation format
(which is still valid presentation format) is trivial.
> So I think we have two options:
>
> 1) Clarify the text that the DS RRtype data is not in either wire or
> presentation format.
Yes. This is needed. I would actually also would like to have text
explaining can you have comments whitespace, newlines etc inside the
Digest Data or not too, while we are at it. I would expect that most
of the implementations would not necessarely like those and sending
those over the wire is just wasting bytes.
> 2) Change the DS RRtype data to also be fully DNS presentation format.
>
>
> I have a preference for 2) but I guess the working group in the past
> reached consensus on 1)
>
> > Which is then encoded as:
> >
> > 1 2 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+---+
> > |R| Attribute Type 0x19 | Length 0x48 |
> > +-+-+---+---+
> > | DNSKEY Key Tag 0x04 0xf6 |DNSKEY Alg 0x8 |Digest Type 0x1|
> > +---+---+---+
> > | 0x28 "("0x20 " "0x35 "5"0x30 "0" |
> > | 0x36 "6"0x41 "A"0x44 "D"0x33 "3" |
> > | 0x41 "A"0x36 "6"0x35 "5"0x36 "6" |
> > | 0x20 " "0x20 " "0x2B ";"0x20 " " |
> > | 0x63 "c"0x6f "o"0x6d "m"0x6d "m" |
> > | 0x65 "e"0x6e "n"0x74 "t"0x73 "s" |
> > | 0x0a "\n" 0x09
