Re: DNSSEC validation without current time
On 2017-12-18 06:44, Timothe Litt wrote: On 18-Dec-17 01:07, Dave Warren wrote: On 2017-12-15 06:23, Petr Menšík wrote: Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): Hi there, On Fri, 15 Dec 2017, Petr Men??k wrote: ... current time is not available or can be inaccurate. ntpdate? Sure, of course. What would be default host after installation, that can be used in default installation image without manual configuration? And how does it resolve that name, when date of the system is 1970-1-1 or something a only a bit more accurate? Current pool.ntp.org adresses are unsigned now, so that would work anyway. If I want spoof protection, what should I do? Do two passes. First: Use DNS without DNSSEC validation to obtain a list of NTP servers, and thereby determine the current time. Second: Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and verify the time. The second pass might detect the list of IPs has changed and bypass the second NTP pass as we now know the previous IPs were valid, but you must be prepared for DNS to return different IPs from a pool and to therefore re-verify the time -- We don't care if the IP list has changed, only that the time is valid. The only real challenge is to avoid letting anything else trust the time received in phase 1 until it has been validated by phase 2. This proposal is involved, but doesn't seem to robustly solve the problem. * Pass 1 obtains "current time". But you don't trust that the IP addresses of the NTP servers were correctly resolved. So you don't trust this time. However, you need a reasonably trustworthy time to bootstrap DNSSEC. (On the order of minutes). Else DNSSEC validation can fail. Right, this is the whole point and why it works. If either DNS or NTP is malicious, pass 2's DNSSEC validation fails and we know we don't yet have valid time. * If you're using the pools (and they resolve correctly), you're pretty much guaranteed that any two queries will produce a different set of servers. So IP addresses will change. DNS caching may provide the same IP addresses. It is irrelevant as this is just an optimization which fails gracefully, or can be skipped entirely. * Pass 2 requires "trusted" NTP servers. If you have that list, why not resolve those names without validation in the first place? You could assume that a hostile actor knows which names you resolve, and assume that they will substitute bad timekeepers. But if they can do that, they can do the same for the pools' names. I think that this is the whole point -- There is no hardcoded list of trusted NTP servers. We need to obtain the list from DNS (pass 1) and verify that the list can be trusted using DNSSEC (pass 2). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On 18/12/2017 14:44, Timothe Litt wrote: > > On 18-Dec-17 01:07, Dave Warren wrote: >> On 2017-12-15 06:23, Petr Menšík wrote: >>> >>> Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): Hi there, On Fri, 15 Dec 2017, Petr Men??k wrote: > ... current time is not available or can be inaccurate. ntpdate? >>> Sure, of course. What would be default host after installation, that >>> can >>> be used in default installation image without manual configuration? And >>> how does it resolve that name, when date of the system is 1970-1-1 or >>> something a only a bit more accurate? >>> >>> Current pool.ntp.org adresses are unsigned now, so that would work >>> anyway. If I want spoof protection, what should I do? >> >> Do two passes. First: Use DNS without DNSSEC validation to obtain a >> list of NTP servers, and thereby determine the current time. Second: >> Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and >> verify the time. >> >> The second pass might detect the list of IPs has changed and bypass >> the second NTP pass as we now know the previous IPs were valid, but >> you must be prepared for DNS to return different IPs from a pool and >> to therefore re-verify the time -- We don't care if the IP list has >> changed, only that the time is valid. >> >> The only real challenge is to avoid letting anything else trust the >> time received in phase 1 until it has been validated by phase 2. >> > > This proposal is involved, but doesn't seem to robustly solve the problem. True but look at it this way, first get a guess on the time from "an" NTP server, then try using that time to get DNSSEC replies, if they work, the time was good enough, if the time was bad, DNSSEC will not work and you know you have a bad time,and will have to try again or die. > > * Pass 1 obtains "current time". But you don't trust that the IP > addresses of the NTP servers were correctly resolved. So you > don't trust this time. However, you need a reasonably trustworthy > time to bootstrap DNSSEC. (On the order of minutes). Else DNSSEC > validation can fail. > * If you're using the pools (and they resolve correctly), you're > pretty much guaranteed that any two queries will produce a > different set of servers. So IP addresses will change. > * If you use a reasonable number of NTP servers and NTP (not SNTP) > protocol, invalid timekeepers will be sorted out. NTP is quite > robust, and expects some variance - including some malicious > actors. The reasonably recent versions with pool support will > discard bad timekeepers and keep drawing from the pool until > consensus is attained. And again if it's lost (e.g. some go bad > due to system or network failures.) To fool NTP, you need to > provide a number of bad time sources, synchronized closely enough > for NTP to accept them. This is non-trivial. Suppose someone > puts in that effort and succeeds. What happens? DNSSEC is the > least of your problems. Other breakage will be more subtle. Like > filesystem times being inconsistent and breaking CMS and other > applications. > * To prevent DNSSEC from working, time error has to be quite large. > All that's necessary is some approximation that's accurate within > minutes. > * Pass 2 requires "trusted" NTP servers. If you have that list, why > not resolve those names without validation in the first place? > You could assume that a hostile actor knows which names you > resolve, and assume that they will substitute bad timekeepers. > But if they can do that, they can do the same for the pools' names. > * What can bad time do to DNSSEC? By rolling back, it could allow > validation of an expired signature - but the attacker would have > to be able to benefit from that. Or it could prevent validation > of a current signature (by making current time be outside the > validity period). Or it could prematurely force you to validate a > published, but not yet active signature. These amount to (at > worst) denial of service. > > None of this is news. See > https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5 > > > The bottom line is that you want accurate time. And if you have > accurate time, DNSSEC will follow. You also need to consider the > threat profile that you face - including the downside risks and costs > of a defense. > > Bootstrapping requires some reasonably accurate time source. The > easiest way to get there is with a locally trusted source. You can > add an RTC - again, here's one from Adafruit - > https://www.adafruit.com/product/3386 about $5 (US). [Same > disclaimer.] The RTCs (I haven't run this one) in general have poor > accuracy(2) - but if resynchronized with NTP time once in a while, > easily good enough to bootstrap DNSSEC. The one I use (1) is good to > less than 1PPM w
Re: Re: DNSSEC validation without current time
On 18-Dec-17 01:07, Dave Warren wrote: > On 2017-12-15 06:23, Petr Menšík wrote: >> >> Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): >>> Hi there, >>> >>> On Fri, 15 Dec 2017, Petr Men??k wrote: >>> ... current time is not available or can be inaccurate. >>> >>> ntpdate? >>> >> Sure, of course. What would be default host after installation, that can >> be used in default installation image without manual configuration? And >> how does it resolve that name, when date of the system is 1970-1-1 or >> something a only a bit more accurate? >> >> Current pool.ntp.org adresses are unsigned now, so that would work >> anyway. If I want spoof protection, what should I do? > > Do two passes. First: Use DNS without DNSSEC validation to obtain a > list of NTP servers, and thereby determine the current time. Second: > Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and > verify the time. > > The second pass might detect the list of IPs has changed and bypass > the second NTP pass as we now know the previous IPs were valid, but > you must be prepared for DNS to return different IPs from a pool and > to therefore re-verify the time -- We don't care if the IP list has > changed, only that the time is valid. > > The only real challenge is to avoid letting anything else trust the > time received in phase 1 until it has been validated by phase 2. > This proposal is involved, but doesn't seem to robustly solve the problem. * Pass 1 obtains "current time". But you don't trust that the IP addresses of the NTP servers were correctly resolved. So you don't trust this time. However, you need a reasonably trustworthy time to bootstrap DNSSEC. (On the order of minutes). Else DNSSEC validation can fail. * If you're using the pools (and they resolve correctly), you're pretty much guaranteed that any two queries will produce a different set of servers. So IP addresses will change. * If you use a reasonable number of NTP servers and NTP (not SNTP) protocol, invalid timekeepers will be sorted out. NTP is quite robust, and expects some variance - including some malicious actors. The reasonably recent versions with pool support will discard bad timekeepers and keep drawing from the pool until consensus is attained. And again if it's lost (e.g. some go bad due to system or network failures.) To fool NTP, you need to provide a number of bad time sources, synchronized closely enough for NTP to accept them. This is non-trivial. Suppose someone puts in that effort and succeeds. What happens? DNSSEC is the least of your problems. Other breakage will be more subtle. Like filesystem times being inconsistent and breaking CMS and other applications. * To prevent DNSSEC from working, time error has to be quite large. All that's necessary is some approximation that's accurate within minutes. * Pass 2 requires "trusted" NTP servers. If you have that list, why not resolve those names without validation in the first place? You could assume that a hostile actor knows which names you resolve, and assume that they will substitute bad timekeepers. But if they can do that, they can do the same for the pools' names. * What can bad time do to DNSSEC? By rolling back, it could allow validation of an expired signature - but the attacker would have to be able to benefit from that. Or it could prevent validation of a current signature (by making current time be outside the validity period). Or it could prematurely force you to validate a published, but not yet active signature. These amount to (at worst) denial of service. None of this is news. See https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5 The bottom line is that you want accurate time. And if you have accurate time, DNSSEC will follow. You also need to consider the threat profile that you face - including the downside risks and costs of a defense. Bootstrapping requires some reasonably accurate time source. The easiest way to get there is with a locally trusted source. You can add an RTC - again, here's one from Adafruit - https://www.adafruit.com/product/3386 about $5 (US). [Same disclaimer.] The RTCs (I haven't run this one) in general have poor accuracy(2) - but if resynchronized with NTP time once in a while, easily good enough to bootstrap DNSSEC. The one I use (1) is good to less than 1PPM with the help of some drift compensation that I put into the utility that manages the clock. [It's a replacement for 'hwclock' that drives this RTC.] (This reduces the jump when NTP starts, and helps keep logs straight. If you don't care about that, just update the RTC from NTP time every week or two - that's more than sufficient for DNSSEC & NTP bootstrap.) Alternatively, as previously discussed, if you need the best (non PTP) time, add a GPS receiver, with pool back
Re: DNSSEC validation without current time
On 2017-12-15 06:23, Petr Menšík wrote: Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): Hi there, On Fri, 15 Dec 2017, Petr Men??k wrote: ... current time is not available or can be inaccurate. ntpdate? Sure, of course. What would be default host after installation, that can be used in default installation image without manual configuration? And how does it resolve that name, when date of the system is 1970-1-1 or something a only a bit more accurate? Current pool.ntp.org adresses are unsigned now, so that would work anyway. If I want spoof protection, what should I do? Do two passes. First: Use DNS without DNSSEC validation to obtain a list of NTP servers, and thereby determine the current time. Second: Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and verify the time. The second pass might detect the list of IPs has changed and bypass the second NTP pass as we now know the previous IPs were valid, but you must be prepared for DNS to return different IPs from a pool and to therefore re-verify the time -- We don't care if the IP list has changed, only that the time is valid. The only real challenge is to avoid letting anything else trust the time received in phase 1 until it has been validated by phase 2. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Hi there, On Fri, 15 Dec 2017, Barry Margolin wrote: In article , "G.W. Haywood" wrote: On Fri, 15 Dec 2017, Petr Men??k wrote: ... current time is not available or can be inaccurate. ntpdate? I think the issue is that he needs to resolve the hostname of the NTP server. Perhaps he could set up some IPv6 time servers on a dedicated /48. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On 12/15/2017 08:10 AM, Timothe Litt wrote: I use an 19xLVC too (On Raspbian == Debian). But I also have an RTC. GPS does have outages, can take a while to get a fix, and NTP wants consensus. So I use my GPS receiver as a local clock source (preferred), but also configure several servers from the pools as a sanity check - and to deal with any GPS outages/slow starts. It's worked well for me. Along those lines, I haven't splurged yet, but Adafruit has an interesting module for ~$40 (US) with a breakout module, ($45 on a Pi Hat - which is cheaper/easier than building your own PCB), which includes a GPS patch antenna. If you need an external antenna, it comes up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a more modern receiver.) On paper it looks good. See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with Adafruit, and while I've looked at the specs, don't have direct experience. YMMV. Thank you for sharing info Mukund and Timothe. I suspect I'll be playing over the holidays. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
In article , "G.W. Haywood" wrote: > Hi there, > > On Fri, 15 Dec 2017, Petr Men??k wrote: > > > ... current time is not available or can be inaccurate. > > ntpdate? I think the issue is that he needs to resolve the hostname of the NTP server. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: DNSSEC validation without current time
On 15-Dec-17 07:44, Mukund Sivaraman wrote: On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote: >> Hi folks. >> >> I am looking for a way to validate name also on systems, where current >> time is not available or can be inaccurate. > I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232 > serial port. The device plus cables cost me $70 altogether, and ntpd > works natively with it using the NMEA refclock driver (there's no need > of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to > within +/- 100us on Fedora where due to no hardpps kernel support > because of tickless kernel, the PPS signal is timestamped and available > on /dev/pps0 but the kernel doesn't use it to directly maintain the > clock and it has to be done from userland which is affected by the > system load. If you were to recompile a kernel that's configured > appropriately, I feel the clock can be synchronized to about 1us > accuracy. > > It is more or less reliable and value for $70 if one wants UTC on their > computer without accessing the internet. This is more than sufficient > for DNSSEC validation and many other network services, and certainly > more accurate than using the ntp.org pools. > > Mukund > I use an 19xLVC too (On Raspbian == Debian). But I also have an RTC. GPS does have outages, can take a while to get a fix, and NTP wants consensus. So I use my GPS receiver as a local clock source (preferred), but also configure several servers from the pools as a sanity check - and to deal with any GPS outages/slow starts. It's worked well for me. Along those lines, I haven't splurged yet, but Adafruit has an interesting module for ~$40 (US) with a breakout module, ($45 on a Pi Hat - which is cheaper/easier than building your own PCB), which includes a GPS patch antenna. If you need an external antenna, it comes up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a more modern receiver.) On paper it looks good. See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with Adafruit, and while I've looked at the specs, don't have direct experience. YMMV. Enjoy. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On 15-Dec-17 06:45, Petr Menšík wrote: > Hi folks. > > I am looking for a way to validate name also on systems, where current > time is not available or can be inaccurate. > > This is related to booting with NTP client, when the only configuration > is hostname that has to be resolved. There is a bit circle dependencies. > First current time is required for DNSSEC validator to verify signatures > of all keys. However that is hard to maintain on systems without RTC > clock running when it is down. Raspberry PI is example of such system. > Until hostname is known, time cannot be synchronized and corrected to > real value. They sort of depend on each other. The only secure way I > found is to hardcode IP address into NTP client or obtain IP from other > trusted source (DHCP?). > > Available option is of course to disable validation until valid time is > received. It seems to me that is unnecessary lowering the security. I > would like some option to limit checking validity period of used keys > instead. Just validate existing keys from trust anchor and trust the > last key that can validate. I think that is far better than no > verification at all. > > Is it possible to do that in BIND? Maybe bootstrap verification could be > done only with delv tool with time-checking disabled. I found no way to > do that. Is there good reason why it is not available? Is better method > for solving secure configuration of timeless system available? > I added an RTC to my Pis :-) It makes life a lot simpler, even after I wrote a driver and calibration mechanism. But if you have access to a DHCP server, have the client request Option 42; this returns one or more NTP servers' IP addresses in preference order. You can use NTPD (or ntpdate) to get a time. ISC DHCP client supports this option; see dhcp-users if you need help. DNSSEC requires reasonably accurate time, as signatures have validity periods. Your scheme would not work; you need time to validate ANY signature - from the trust anchor down. If there's no time, you can't validate any part of the chain - so you might as well use ordinary DNS. NTP is fairly robust; it uses consensus from multiple servers to establish correct time. For a rogue DNS to inject bad time into your PI, it would have to know which NTP servers you are using. Another option is to use DHCP to get the address of a validating resolver, and rely on that for bootstrapping NTP. Again, this depends on whether your control/trust your DHCP server. More ISPs are providing validatiing DNS server, but it's not universal. Hardcoding one of the public ones (e.g. Google - 8.8.8.8, 8.8.4.4, 2001:4860:4860::, 2001:4860:4860::8844) is fairly safe. NTP server addresses are more volatile, and it's a serious breach of netiquette to hardcode them; there are a number of stories of how this has gone badly wrong for all concerned. The choice depends on your requirements, available resources, and risk tolerance. You also need valid time for many other applications; TSIGs require a reasonably close (on the order of minutes) time sync between sender and receiver. So rather than try to tweak NAMED, focus on getting a reasonable time early in boot - and make sure that dependencies on a valid time are properly expressed in your startup scripts. Bottom line: your problem is getting a reasonable time, not with the consumer(s). Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): > Hi there, > > On Fri, 15 Dec 2017, Petr Men??k wrote: > >> ... current time is not available or can be inaccurate. > > ntpdate? > Sure, of course. What would be default host after installation, that can be used in default installation image without manual configuration? And how does it resolve that name, when date of the system is 1970-1-1 or something a only a bit more accurate? Current pool.ntp.org adresses are unsigned now, so that would work anyway. If I want spoof protection, what should I do? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Petr Menšík wrote: > > This is related to booting with NTP client, when the only configuration > is hostname that has to be resolved. There is a bit circle dependencies. Yes awkward, and there still aren't any convincing answers. One of the more interesting projects is https://roughtime.googlesource.com/roughtime I have not actually tried it out myself or found out if it can be configured with only IP addresses so that it can get the time without the DNS. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Variable 3 or 4, but northerly 4 or 5 at first in east. Moderate or rough. Wintry showers, then fair. Good occasionally poor at first.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote: > Hi folks. > > I am looking for a way to validate name also on systems, where current > time is not available or can be inaccurate. I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232 serial port. The device plus cables cost me $70 altogether, and ntpd works natively with it using the NMEA refclock driver (there's no need of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to within +/- 100us on Fedora where due to no hardpps kernel support because of tickless kernel, the PPS signal is timestamped and available on /dev/pps0 but the kernel doesn't use it to directly maintain the clock and it has to be done from userland which is affected by the system load. If you were to recompile a kernel that's configured appropriately, I feel the clock can be synchronized to about 1us accuracy. It is more or less reliable and value for $70 if one wants UTC on their computer without accessing the internet. This is more than sufficient for DNSSEC validation and many other network services, and certainly more accurate than using the ntp.org pools. Mukund ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Hi there, On Fri, 15 Dec 2017, Petr Men??k wrote: ... current time is not available or can be inaccurate. ntpdate? -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC validation without current time
Hi folks. I am looking for a way to validate name also on systems, where current time is not available or can be inaccurate. This is related to booting with NTP client, when the only configuration is hostname that has to be resolved. There is a bit circle dependencies. First current time is required for DNSSEC validator to verify signatures of all keys. However that is hard to maintain on systems without RTC clock running when it is down. Raspberry PI is example of such system. Until hostname is known, time cannot be synchronized and corrected to real value. They sort of depend on each other. The only secure way I found is to hardcode IP address into NTP client or obtain IP from other trusted source (DHCP?). Available option is of course to disable validation until valid time is received. It seems to me that is unnecessary lowering the security. I would like some option to limit checking validity period of used keys instead. Just validate existing keys from trust anchor and trust the last key that can validate. I think that is far better than no verification at all. Is it possible to do that in BIND? Maybe bootstrap verification could be done only with delv tool with time-checking disabled. I found no way to do that. Is there good reason why it is not available? Is better method for solving secure configuration of timeless system available? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
