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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
