On 4/1/19 3:25 PM, Gary E. Miller via devel wrote: >> 2) Since "noval" disables the security, using "noval" means one is >> essentially falling back to non-NTS. Therefore, "noval" doesn't make >> any sense for long-term production use. A user contemplating using >> "noval" indefinitely in production should either fix the validation >> so NTS is actually providing some security benefit, or just use plain >> NTP if they don't care about the security benefits of NTS. > > Agreed, sort of. This assumes fixes that do not exist. So "assuming > a canopener". It also assumes that less than perfect security is no > security. Part of the rationale for NTS is that since the cookies > change every request, then the user can not be tracked. "noval" does not > remove that feature, or some other goodness.
Changing the cookies is important so that NTS is not _worse_ than plain NTP. (That is, if the cookies didn't change, the cookies would provide a new way to link the client across networks.) The cookies don't make NTS any better than plain NTP in regards to unlinkability, whether the TLS for NTS is properly secured or not. The NTS draft, section 10.1 says: NTS's unlinkability objective is merely to not leak any additional data that could be used to link a device's network address. NTS does not rectify legacy linkability issues that are already present in NTP. Thus, a client that requires unlinkability must also minimize information transmitted in a client query (mode 3) packet as described in the draft [I-D.ietf-ntp-data-minimization]. Can you point to some other security benefit that NTS with unauthenticated TLS would provide over plain NTP? I'm not seeing any benefit, and more importantly, Daniel Franke has already weighed in to that effect: There's no point in doing NTS if you're not doing certificate validation. The result isn't any more secure than unauthenticated NTP. -- https://lists.ntpsec.org/pipermail/devel/2019-March/007804.html > Agreed, sort of. The "ca", which is an "assumed can opener", does > not solve many very similar cases. It solves the case it is intended to solve. Other cases need to be considered separately. >> 4B) If ntpd implements pinning, it should be in addition to the usual >> certificate validation, not instead of. >> - If validation is succeeding, there is no problem. > > No. Rememeber when Comodo issued the cert "*.google.com" to bad guys? The context here is whether pinning applies in addition to validation or instead of normal certificate validation. If normal certificate validation is already passing in a particular scenario, then there is "no problem" with pinning being "in addition to", as opposed to "instead of", normal validation. I never claimed that certificate validation means that everything is for sure secure. I'm fully aware that CAs mis-issue certificates and that's a reason why pinning is useful. (this quote reordered slightly down) > Once again, DANE goes over all of this. DANE has four models (see RFC 6698, section 2.1.1). To be clear, the numbers referenced below are from the DANE RFC: 0: Pin a CA certificate or public key. This is what I'd consider the most useful form of "typical pinning". 1: Pin the end certificate or public key. This is also "typical pinning" like 0, but for the end certificate. As I said, this is fine, except we all seem to agree that it can be a pain with certificates/keys that roll over frequently (e.g. Let's Encrypt). 2: Add a trust anchor. This is the DANE version of the "ca" option. 3: Pin the end certificate or public key and disable normal validation. Regarding usage 0: DANE agrees with me that you MUST do validation if pinning the CA: The presented certificate MUST pass PKIX certification path validation, and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path. Let's consider what would happen if you did NOT validate in this scenario. Imagine you pin the CA as the "Let's Encrypt Authority X3" public key _and_ disable normal validation. An attacker MITMs your connection. They serve you an end certificate which claims to be signed by "Let's Encrypt Authority X3", but isn't actually. They also serve you the "Let's Encrypt Authority X3" certificate. If you don't validate, you'll accept this connection in spite of your "pin", which isn't actually doing anything. Without normal validation of the chain, you will accept the connection because the attacker provided the Let's Encrypt certificate that matched the pin; it just wasn't related to the end certificate in any way. DANE separates the various modes, requiring it to be explicitly specified on the pin. My point previously was that if there is just a single "pin=HASH" configuration option that is matched against _any_ certificate/key in the chain, then we must carefully consider the interactions between pinning and validation. Specifically, we must perform validation before accepting that pin against a _CA_, as opposed to end, certificate/key. Otherwise, the pin is providing zero security as described above. In contrast, the "pin=HASH" is fine for end certificates/keys even without validation, as discussed below. Regarding usages 1 & 3: DANE requires validation for #1, by definition. The version without validation is #3. Since #3 is checking the end certificate or public key, there is no chain to worry about. So this is fine. In every case other than #3, pinning applies _in addition to_ normal validation, not _instead of_ normal validation. I've already said that pins in the style of DANE #0 and #1 should be options. I've said that DANE #2 (the "ca" option) should be implemented. That just leaves #3. I've argued against #3. #3 would typically be useful for self-signed end certificate scenarios. As I said, that's my position that I expect to be the most controversial. To recap, I believe it's not necessary to allow #3, because public certs are now free and readily available. Barring that, one can operate a private CA (as enterprises might already, e.g. on Windows, or as hobbyists can, e.g. as Hal is doing). Barring that, just use plain NTP. Gary, is our disagreement mainly that you want #3 (pinning an end certificate/key and bypassing validation) to be an option? For whatever my position matters, I'm willing to yield on #3 as long as it is explicitly configured by the user. I'm worried that a simplistic configuration approach of "noval pin=..." will be either too complicated under the hood and/or too dangerous. That syntax _adds_ security if it's used as a #3 (pinning an end certificate/key), but if it's used as a #1 (pinning a CA certificate/key), the "pin=" is completely useless (as described above) because of "noval", thus possibly providing a false sense of security. If we try to fix that by making "noval" mean "do some validation if 'pin=' is specified and it matches against a CA certificate/key", that's: A) really complicated for users and even NTPsec developers to understand, and B) breaks the literal meaning of "noval", which may hamper noval's debugging uses. >> - If validation is failing because the hostname doesn't match, >> something is configured wrong on either the server or client. Fix >> that. > > Ah, a new type of "assumed can opener'! Why exactly is it a problem to ask people to configure their security settings correctly? >> - If validation is failing because the chain is broken, fix that on >> the server. > > Except I'm the client, thus not possible. The user has gone to the work to opt-in to NTS, to authenticate their time. Given that, why do they want to use a server that has its TLS misconfigured? >> - If validation is failing due to legitimate time issues, fix that on >> the server or with the CA (which is presumably private, because a >> public CA certainly should have their clocks set correctly). > > Except I'm the client, I can't fix a bad server cert. Same question. You seem to want to require that the client software (ntpd) allow its administrator to bypass any and all possible TLS failures, to get the NTS connection to come up. Why is that a useful objective, given that plain NTP is an available fallback? This is different than, say, HTTPS. In HTTPS, I absolutely _do_ need my browser to let me bypass any failure, even if it completely throws away all the security, so I can get the page to load. A given HTTPS endpoint may not support HTTP (or may serve different content on HTTP), so I can't just fall back to HTTP if HTTPS fails. But with NTS, I can simply fall back to plain NTP. NTP is definitely going to work, since the actual time communication is using NTP in either case. It's also the case that with HTTPS, I might be logging into the web interface of something specifically to correct the certificate configuration. If my browser outright refuses to let me connect, I am stuck in a chicken-and-egg problem. This is not the case for NTS either. > Says someone with a static public IP. Not an option for private > networks, test networks, roaming servers, etc. You do not need a static IP to get a Let's Encrypt certificate. Dynamic DNS works just fine. My home router is on a dynamic cable IP address, runs pfSense, and has a web GUI to do both dynamic DNS and Let's Encrypt. This all works fine. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel