Cert pinning

Tue Apr 2 02:06:05 UTC 2019

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190401/0861fb9d/attachment.bin>