Re: Cert pinning
Yo Richard! On Mon, 1 Apr 2019 21:06:05 -0500 Richard Laager via devel wrote: > 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]. Yes, that is my understanding as well. > Can you point to some other security benefit that NTS with > unauthenticated TLS would provide over plain NTP? Yes, see the Proposed RFC Section 1.1. Objectives: o Confidentiality: Although basic time synchronization data is considered non-confidential and sent in the clear, NTS includes support for encrypting NTP extension fields. o Replay prevention: Client implementations may detect when a received time synchronization packet is a replay of a previous packet. o Request-response consistency: Client implementations may verify that a time synchronization packet received from a server was sent in response to a particular request from the client. > 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 Well, Section 1.1 disagrees. Remeber, I;'m not advocating for insecurity, just for all the security I can get under bad conditions. > > 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. Wow, that is circular. We've not agreeed on the the case intended to solve. But, please don't bother to add that distraction. We already agreed "ca' is sometimes good to have. > >> 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 can't tell who you are arguing against. Certainly not me. Can't imagine why I need to keep agreeing with things already stipulated. What we have here is a failure to converge. So I'll stop going around the May Pole right now. Let Hal work it out. [...] RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpNxim4eWDE2.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
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 validati
Re: Cert pinning
Yo Hal! On Mon, 01 Apr 2019 15:23:58 -0700 Hal Murray wrote: > > Sad. Seems we've been around this May Pole way too many times > > already... You have nothing new to say below, and my answers are > > also not new. > > Richard's summary matches my understanding. Then you are learning, much more to go. > > 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. > > The problem with pseudo security is that people might think it really > is secure. Yup. But nothing is totally secure, sometimes you know what you are compromising, sommetimes you do not. Sometimes you have no choice. Such as earlier this year when the NIST certs were broken, yet people were legally required to maintain NIST traceable time. > If it's not (real) secure, I think we should make a lot of noise > about using it. 100 agree. Flash the room in red light, sound the klaxons, spin the disks up and down so the server shakes. > > 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. > > Why are you bringing up tracking? Is it related to security? To > pinning? I bring it up because it is part of the RFC. The RFC writers think is important, so I do too. I suggest you ask them if you want to know why they feel it is a key part of NTS. Just because the initial contact, exchanging the first cookies, is not 100% perfect, does not mean there is no significant value remaining to address other concerns. I'll avoid repeating recent emails on the NTP mailing list on the subject. > > Agreed, sort of. The "ca", which is an "assumed can opener", does > > not solve many very similar cases. > > My plan is to implement the per-server "ca" as soon as I can. The > API I want isn't available, but I think I see a reasonable way to > implement it. Good. another small piece of the puzzle. Personnaly, I'd rather see pinning before "ca". I sent you the code to do it. It solves more problems than simple "ca". Such as the "*.google.com" one. But, order is up to you, eventually it all needs to get done. > That will solve the problem of self-certified certificates. How many > of your "many very similar" cases are interesting? Well, "*.google.com" seemed to get peoples attention. Ditto for NIST earlier this year. > > Personally, I'd rather have DANE type pinning before "ca". And > > once "ca" is implemented would like to do both. > > Are you trying to use DANE as a substitute for normal certificate > checking or as a supplement? Around the May Pole again... Neither. DANE is a very well thought out, well deployed, and comprehensive approach for certificate pinning using DNS. We don't need (yet) the DNS part, but the other 90% is on point for any application doing pinning. Don't reinvent a good wheel. > I don't fully understand DANE yet. Very few fully understand DANE. Not required. I think Matt Selsky will agree it took us much of a year to get it "right" for ntpsec.org. > A good example might help. Look at the ntpsec.org DNS for a good example. Or, just use the pinning code I sent you. Basically: hash one of the certs or public keys you get from a server, store the hash algorithm and the hash. Next time you see the cert and/or key, compare the hash. > Is > there a HOWTO type web page telling me how to set things up? ... Many, just google "DANE TLSA". That is why I keep bring up DANE over the many other similar ways to do cert pinning: it is so well documented and understood. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://joscor.com/blog/dane-tlsa-tutorial/ https://blog.webernetz.net/how-to-use-danetlsa > Is it widely deployed? Does my browser use it? You use ntpsec.org, so you use pinning. Do not get too hung up on DANE and DNS. Just look at the part that calculates all the dozens of ways that pinning can be computed. Then pick one, or four. Similarly HPKP also does pinning, inside HTTP. So your browser uses HPKP, few browsers use DANE, but the actual pin concept is the same. The transfer mechanisms are different, but the core concept of pinning is the same. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpd92XOkRCg4.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
[Argh. Sorry for the duplicate. I forgot to cc the list.] > Sad. Seems we've been around this May Pole way too many times already... You > have nothing new to say below, and my answers are also not new. Richard's summary matches my understanding. > 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. The problem with pseudo security is that people might think it really is secure. If it's not (real) secure, I think we should make a lot of noise about using it. > 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. Why are you bringing up tracking? Is it related to security? To pinning? > Agreed, sort of. The "ca", which is an "assumed can opener", does not solve > many very similar cases. My plan is to implement the per-server "ca" as soon as I can. The API I want isn't available, but I think I see a reasonable way to implement it. That will solve the problem of self-certified certificates. How many of your "many very similar" cases are interesting? > Personally, I'd rather have DANE type pinning before "ca". And once "ca" is > implemented would like to do both. Are you trying to use DANE as a substitute for normal certificate checking or as a supplement? I don't fully understand DANE yet. A good example might help. Is there a HOWTO type web page telling me how to set things up? ... Is it widely deployed? Does my browser use it? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 21:57:22 -0500 Richard Laager via devel wrote: > Let me try this again, as one standalone post, updated with the latest > information, including that we already have a documented "ca" option > which just needs implementation. Sad. Seems we've been around this May Pole way too many times already... You have nothing new to say below, and my answers are also not new. So anyone following along can just quit reading right now. > 1) I agree that "noval" is useful for _debugging_. For now, and > probably indefinitely, it should stay. Agreed. > 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. > 3) Right now, you (Gary) are trying to connect to some server, which > is failing because it uses a private root CA, which you are (quite > reasonably) unwilling to trust system-wide. Once the "ca" option is > implemented, you can use that option for that particular association, > and you will no longer need "noval" for that particular association. Agreed, sort of. The "ca", which is an "assumed can opener", does not solve many very similar cases. > 4) Implementing certificate pinning would be a "nice to have" feature > that can increase security above and beyond normal certificate > validation. "nice to have", or "must have", depending on other "assumed can openers". Personally, I'd rather have DANE type pinning before "ca". And once "ca" is implemented would like to do both. > 4A) The pins could come from manual configuration and/or DANE, > depending on what someone is willing to implement in ntpd. Yes, this all comes down to Hal for now. > Those somewhat cover different use cases. Manual configuration allows > the administrator of the client to manually tighten the requirements. > DANE allows the server operator to request (via DNS records) that > clients automatically tighten the requirements. There is overlap where > the client and server administrators are the same person, in which > case either option may meet their needs (if DNSSEC is available so > DANE works securely). And now your talking about features we might get in 2025. Pretty premature. Way beyond Hal's current horizon. > 4B) If ntpd implements pinning, it should be in addition to the usual > certificate validation, not instead of. Of course. But completly missing the point. Once again, DANE goes over all of this. The problem at hand is where "The usual certificate validation" fails. > This may be controversial with others. Let me explain my thoughts, so > we can determine if/where the disagreement lies: Not controversial, just missing key corner cases, and sometimes wrong. > - If validation is succeeding, there is no problem. No. Rememeber when Comodo issued the cert "*.google.com" to bad guys? That was partly the reson for HPKP, DANE, etc. > - If validation is failing due to a private root, add it system wide > or use the "ca" option to fix the validation. Or, pinning, or just "assume a can opener". > - 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'! > - If validation is failing because the chain is broken, fix that on > the server. Except I'm the client, thus not possible. > - 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. > - If validation is failing due to bootstrapping time issues, that's a > separate discussion we've already covered, expanding on the guidance > from the NTS draft. That affects servers with certificates from > public CAs, too. Yup, a whole 'nother rat hole. > This is probably the most controversial one: > - If the server has a self-signed certificate, they should switch to > either a certificate from a public CA (e.g. Let's Encrypt) or setup > a private CA. In a world where "real" certificates are readily and > freely available, I see no reason that security-minded folks (who > are doing extra work to opt-in to NTS!) can't use a real certificate > or setup a private CA. Says someone with a static public IP. Not an option for private networks,
Re: Cert pinning
Let me try this again, as one standalone post, updated with the latest information, including that we already have a documented "ca" option which just needs implementation. 1) I agree that "noval" is useful for _debugging_. For now, and probably indefinitely, it should stay. 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. 3) Right now, you (Gary) are trying to connect to some server, which is failing because it uses a private root CA, which you are (quite reasonably) unwilling to trust system-wide. Once the "ca" option is implemented, you can use that option for that particular association, and you will no longer need "noval" for that particular association. 4) Implementing certificate pinning would be a "nice to have" feature that can increase security above and beyond normal certificate validation. 4A) The pins could come from manual configuration and/or DANE, depending on what someone is willing to implement in ntpd. Those somewhat cover different use cases. Manual configuration allows the administrator of the client to manually tighten the requirements. DANE allows the server operator to request (via DNS records) that clients automatically tighten the requirements. There is overlap where the client and server administrators are the same person, in which case either option may meet their needs (if DNSSEC is available so DANE works securely). 4B) If ntpd implements pinning, it should be in addition to the usual certificate validation, not instead of. This may be controversial with others. Let me explain my thoughts, so we can determine if/where the disagreement lies: - If validation is succeeding, there is no problem. - If validation is failing due to a private root, add it system wide or use the "ca" option to fix the validation. - If validation is failing because the hostname doesn't match, something is configured wrong on either the server or client. Fix that. - If validation is failing because the chain is broken, fix that on the server. - 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). - If validation is failing due to bootstrapping time issues, that's a separate discussion we've already covered, expanding on the guidance from the NTS draft. That affects servers with certificates from public CAs, too. This is probably the most controversial one: - If the server has a self-signed certificate, they should switch to either a certificate from a public CA (e.g. Let's Encrypt) or setup a private CA. In a world where "real" certificates are readily and freely available, I see no reason that security-minded folks (who are doing extra work to opt-in to NTS!) can't use a real certificate or setup a private CA. Am I missing other scenarios where validation fails? If so, please be specific. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 21:06:25 -0500 Richard Laager via devel wrote: > On 3/31/19 8:58 PM, Gary E. Miller via devel wrote: > > Yo Richard! > > > > On Sun, 31 Mar 2019 18:47:35 -0500 > > Richard Laager via devel wrote: > > > >> This option would allow Gary's scenario to validate, without > >> needing to trust that root system-wide. He would presumably then > >> eliminate "noval" from that configuration line. > > > > Failing to match a root CA in the local cert is only one of many > > ways that a cert can fail to validate. Before noval can be removed > > there must be a workaround for all of them. > > I don't know how I can be more clear about this. I'm suggesting that > you, individually, would remove "noval" from one particular NTS > association once we have "root" or "ca" to fix validation in that > scenario. I am not suggesting the "noval" option be removed from ntpd. If wishes were dreams then beggars would ride. We may, or may not, ever have the "root" or "ca" options per server. Personally, I find them more confusing than helpful. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgppbCrLRBDgW.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 18:33:54 -0500 Richard Laager via devel wrote: > On 3/28/19 6:06 PM, Gary E. Miller via devel wrote: > > On Thu, 28 Mar 2019 17:54:04 -0500 > > Richard Laager via devel wrote: > > > Updating the pins every 90 days > > was a PITA. > Yes, pinning the end certificate or end public key is going to be > annoying if those rotate frequently. That's why you probably want to > pin the intermediate or root CA public key. Or to one of the public keys in the chain. These are all DANE options. > >> So > >> either pinning needs to override validation, or you'll still need > >> to continue to specify "noval". > > > > Uh, no. > > I'm not sure what you're disagreeing with. In your case, validation is > currently failing for one NTS association, and you have suggested > pinning as a possible solution. Yes, suggested, and shown prior art, and code, to do so. > The quoted text from me above is only claiming that one of the > following must be true: > A) Pinning overrides validation. This allows you to remove "noval" > from this association when you add the pin. > B) Pinning does not override validation. You would still need "noval" >even with the pin. Which ignores all the other ways a cert can fail: before date, after date, hostname mismatch, etc. We need to be able to override all of them at some pint. > > Pinning does not necessarily override validation, it is another > > type of validation. Just as the pinning in the ntpsec.org records > > add to, but does not replace, other validation. > > Right, that's the latter option, so we're on the same page. In that > case, normal validation is still going to fail for you, so you'd have > to keep using "noval". Or, you'd need to add that root for that > association, as discussed below. I was deliberately vague there, so we can't be on the same page. > >> That's all fine. The only tricky thing is that if you pin something > >> other than the end public key (i.e. you pin the intermediate or > >> root CA), then we _do_ need to validate the chain up to that point > >> (albeit maybe still ignoring the NotBefore/NotAfter times). > > > > Uh, no. Just as easy to pin to the end cert. No need to go up. > > But then you need to adjust your pin every 60-90 days when the > certificate changes. As you noted above, this is a pain. Still, you're > welcome to do that. Sigh, we went over this before. You can pin to the root CA, one of the chain CAs, or the final cert. Ditto you can pin to the public key of any, or all, of these. As Matt Salksy mentioned in this thread earlier, he pins the ntpsec.org DANE to the chain cert which only changes every 5 years or so. > But unless ntpd's pinning implementation _only_ allows pinning the end > certificate or public key, then it is possible that someone could pin > an intermediate. Yes, that is a good thing, to be encouraged, for the reasons stated above. > And if someone does that, we either need to disallow > the combination of pinning and "noval" or, if they specify "noval", > we need to do enough validation to verify the pin. Many other options. So I'll not swing at that straw man. > In other words, > imagine that you pin the intermediate CA public key and specify > "noval". We need to verify that the end certificate corresponds to > the server's key Say what? You just said pin to the intermediate cert, not to the any key. How did the key get in here? > and has a valid signature corresponding to the > pinned intermediate CA's public key. That is how we know the pin has > matched. You just moved from pinning to a cert to pinning to a key. Does not compute. > If someone pins the root CA's public key and uses "noval", we would > need to validate the chain another step further, up to the root. Yes, that is how root certs work. You also need to validate the not before date, not after date and FQDN. Stop trying to make this simple. DANE is a long RFC for good reasons. > >> An alternative approach to meet this particular demand would be to > >> allow specifying a root certificate per NTS association. > > > > Gee, I think that is called pinning. DANE type 1. > > I proposed specifying a root certificate for the association, which is > _not_ the same as pinning. Agreed. Hal already said that was on his long term todo list, so that is a distraction here... > Specifying a root certificate for this particular association would > make normal validation pass, which is currently failing (for lack of > that root certificate being in your trusted root certificate list). > This would allow you to remove noval. For this one case, at one point in time. I was using noval to connect to this host long before I was told I could get a copy of the cert. Other participants in the hackathin were on the private IETF LAN, and thus could not get an FQDN, so they needed noval as well. > In other words, these would all pass: > server ... nts noval > server ... nts noval pin=THE
Re: Cert pinning
On 3/31/19 8:58 PM, Gary E. Miller via devel wrote: > Yo Richard! > > On Sun, 31 Mar 2019 18:47:35 -0500 > Richard Laager via devel wrote: > >> This option would allow Gary's scenario to validate, without needing >> to trust that root system-wide. He would presumably then eliminate >> "noval" from that configuration line. > > Failing to match a root CA in the local cert is only one of many ways > that a cert can fail to validate. Before noval can be removed there > must be a workaround for all of them. I don't know how I can be more clear about this. I'm suggesting that you, individually, would remove "noval" from one particular NTS association once we have "root" or "ca" to fix validation in that scenario. I am not suggesting the "noval" option be removed from ntpd. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 18:47:35 -0500 Richard Laager via devel wrote: > This option would allow Gary's scenario to validate, without needing > to trust that root system-wide. He would presumably then eliminate > "noval" from that configuration line. Failing to match a root CA in the local cert is only one of many ways that a cert can fail to validate. Before noval can be removed there must be a workaround for all of them. There are also checks for validity dates, certificate revocation, hostname matching, etc. > 2) If we want more, implement some form of pinning. As the intention > of pinning is to further restrict the trust anchors, this would be in > addition to normal validation, not instead of it. Why? Many other protocols use pinning sometimes to suplement a cert chain, sometimes in addition to it. No reason not to support both options. > The pinning options > would be mutually exclusive of "noval" to keep the implementation > straightforward and to help prevent people from shooting themselves in > the foot. We should be so lucky... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpXkf3cRtqnB.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Sun, Mar 31, 2019, 4:47 PM Richard Laager via devel wrote: > On 3/31/19 5:07 AM, Achim Gratz via devel wrote: > > So yes, injecting the trust anchor(s) to use for a specific set of > > NTS-KE would be the easier option. > > How about this: > > 1) Add a root=file (or dir?) option. This overrides the allowed roots > for that association. Only the root(s) in that file are allowed for that > association, regardless of what is normally on the system. So this can > be used to restrict (sort of like pinning, but only for roots), but > assuming we implement pinning, it would be mainly intended to allow a > particular root that is not trusted generally. > > This option would allow Gary's scenario to validate, without needing to > trust that root system-wide. He would presumably then eliminate "noval" > from that configuration line. > According to the ntp.conf man page there already is a ca option (unimplemented) for that. I did not remember seeing that detail earlier. > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/31/19 5:07 AM, Achim Gratz via devel wrote: > So yes, injecting the trust anchor(s) to use for a specific set of > NTS-KE would be the easier option. How about this: 1) Add a root=file (or dir?) option. This overrides the allowed roots for that association. Only the root(s) in that file are allowed for that association, regardless of what is normally on the system. So this can be used to restrict (sort of like pinning, but only for roots), but assuming we implement pinning, it would be mainly intended to allow a particular root that is not trusted generally. This option would allow Gary's scenario to validate, without needing to trust that root system-wide. He would presumably then eliminate "noval" from that configuration line. 2) If we want more, implement some form of pinning. As the intention of pinning is to further restrict the trust anchors, this would be in addition to normal validation, not instead of it. The pinning options would be mutually exclusive of "noval" to keep the implementation straightforward and to help prevent people from shooting themselves in the foot. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Cert pinning
On 3/28/19 6:06 PM, Gary E. Miller via devel wrote: > On Thu, 28 Mar 2019 17:54:04 -0500 > Richard Laager via devel wrote: > Updating the pins every 90 days > was a PITA. Yes, pinning the end certificate or end public key is going to be annoying if those rotate frequently. That's why you probably want to pin the intermediate or root CA public key. >> So >> either pinning needs to override validation, or you'll still need to >> continue to specify "noval". > > Uh, no. I'm not sure what you're disagreeing with. In your case, validation is currently failing for one NTS association, and you have suggested pinning as a possible solution. The quoted text from me above is only claiming that one of the following must be true: A) Pinning overrides validation. This allows you to remove "noval" from this association when you add the pin. B) Pinning does not override validation. You would still need "noval" even with the pin. > Pinning does not necessarily override validation, it is another > type of validation. Just as the pinning in the ntpsec.org records add > to, but does not replace, other validation. Right, that's the latter option, so we're on the same page. In that case, normal validation is still going to fail for you, so you'd have to keep using "noval". Or, you'd need to add that root for that association, as discussed below. >> That's all fine. The only tricky thing is that if you pin something >> other than the end public key (i.e. you pin the intermediate or root >> CA), then we _do_ need to validate the chain up to that point (albeit >> maybe still ignoring the NotBefore/NotAfter times). > > Uh, no. Just as easy to pin to the end cert. No need to go up. But then you need to adjust your pin every 60-90 days when the certificate changes. As you noted above, this is a pain. Still, you're welcome to do that. But unless ntpd's pinning implementation _only_ allows pinning the end certificate or public key, then it is possible that someone could pin an intermediate. And if someone does that, we either need to disallow the combination of pinning and "noval" or, if they specify "noval", we need to do enough validation to verify the pin. In other words, imagine that you pin the intermediate CA public key and specify "noval". We need to verify that the end certificate corresponds to the server's key and has a valid signature corresponding to the pinned intermediate CA's public key. That is how we know the pin has matched. If someone pins the root CA's public key and uses "noval", we would need to validate the chain another step further, up to the root. >> An alternative approach to meet this particular demand would be to >> allow specifying a root certificate per NTS association. > > Gee, I think that is called pinning. DANE type 1. I proposed specifying a root certificate for the association, which is _not_ the same as pinning. Specifying a root certificate for this particular association would make normal validation pass, which is currently failing (for lack of that root certificate being in your trusted root certificate list). This would allow you to remove noval. In other words, these would all pass: server ... nts noval server ... nts noval pin=THE_ROOT_PUBLIC_KEY_HASH server ... nts root=/path/to/this/root.pem while this would fail (because the root still isn't trusted): server ... nts pin=THE_ROOT_PUBLIC_KEY_HASH >> The >> advantage of this approach would be that you can remove "noval" and >> thus get the usual validation, including checking certificate >> NotBefore/NotAfter times. > > Ugh, please no. Pinning is an alternative to noval, not a replacement. I was saying you would "remove noval from the configuration line for that NTS server", not "remove the noval option from ntpd entirely". -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Matthew Selsky via devel writes: > Do you have an example of software the implements pinning as BOTH a > central trust store + a specific pin? Pinning doesn't provide a trust store, it restricts it. > postfix allows the user to specific a trust-anchor file per destination. So a > typical postfix tls policy table (when you need specific TLS policy rules) > might have: > > foo.com secure tafile=/etc/ssl/certs/QuoVadis_Root_CA_2_G3.pem > bar.com secure > > So foo.com is required to match a specific commercial CA and bar.com is > allowed to match any CA in the system trust store. Yes, except that larger servers would probably want to have multiple CA listed. But in general I think giving NTS it's own trust anchors (either generally or per host) is the right way forward. Also scope restrictions (PKIX) should be evaluated. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Richard Laager via devel writes: > I think public key (as opposed to certificate) pinning is the common > approach these days. The application simply requires that one of the > public keys in the chain match the pinned public key. The user can > decide if they want to pin the server public key, the intermediate CA, > or the root CA. Normally pinning is provided from the DNS or from the transport protocol to reduces the number of trust anchors that are possibly valid. > That said, we need to think carefully about the intended interactions > between pinning and validation (or lack thereof with noval). Pinning does not relieve you of any validation, it only tells you which validation paths are valid regardless of what trust anchors you have. > I think that you in particular are using pinning to avoid adding the > server operator's private root certificate that you don't trust. That's not what pinning is for and properly implemented it will not work for that. > An alternative approach to meet this particular demand would be to allow > specifying a root certificate per NTS association. Then you could > specify the private root CA for this particular association, without > needing to trust it system-wide, or even ntpd-wide. The advantage of > this approach would be that you can remove "noval" and thus get the > usual validation, including checking certificate NotBefore/NotAfter times. Actually the correct way to implement this is to import the root CA and constrain the scope of its certificates via PKIX stapling to just the subset of purposes that you indeed trust it for. Unfortunately that is not yet implemented by default for most Linux systems, although gnutls will use such constraints if its new enough (and compiled with the requisite option). So yes, injecting the trust anchor(s) to use for a specific set of NTS-KE would be the easier option. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Thu, Mar 28, 2019 at 04:38:44PM -0700, Gary E. Miller via devel wrote: > Potential extra security is just an added feature that you get for free > once you add certificate pinning to handle the ostfalia case. > > Check the pin, but do not check the chain: > > server ostfalie.de noval pin XXX > > Check the pin, and check the chain: > > server rellim.com pin YY > > Now if someone can trick a CA into giving them a valid rellim.com cert > the connection will still be secure. Do you have an example of software the implements pinning as BOTH a central trust store + a specific pin? postfix allows the user to specific a trust-anchor file per destination. So a typical postfix tls policy table (when you need specific TLS policy rules) might have: foo.com secure tafile=/etc/ssl/certs/QuoVadis_Root_CA_2_G3.pem bar.com secure So foo.com is required to match a specific commercial CA and bar.com is allowed to match any CA in the system trust store. See http://www.postfix.org/postconf.5.html#smtp_tls_trust_anchor_file Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Thu, Mar 28, 2019 at 04:06:05PM -0700, Gary E. Miller via devel wrote: > > I think public key (as opposed to certificate) pinning is the common > > approach these days. The application simply requires that one of the > > public keys in the chain match the pinned public key. The user can > > decide if they want to pin the server public key, the intermediate CA, > > or the root CA. > > Tell that to Matt Selsky. He changed the ntpsec.org pinning to > be that if the signing cert. Updating the pins every 90 days > was a PITA. In the LE cert via GitLab Pages case, yes, cert pinning to the leaf was too much trouble, so I created TLSA records for the LE root certificate. But I can see a case where longer lifetimes are used, or the certs are self-signed, then having the flexibility to match anything in the chain would be quite useful as Richard was describing. > > That said, we need to think carefully about the intended interactions > > between pinning and validation (or lack thereof with noval). > > Not need to think about it. Lot's of prior art. Just use that. > The DANE is well thought out. So we want to support the equivalent of DANE's 311 and 211 modes? > > I think that you in particular are using pinning to avoid adding the > > server operator's private root certificate that you don't trust. > > Today, yes. And no way I'll ever add a provate root cert I don't > have enourmous trust in. You probably wouldn't add a private root cert to your system trust store, but you might allow it for a specific NTS server entry. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 18:43:15 -0500 Richard Laager via devel wrote: > You've mentioned DANE a couple of times. I've been mostly ignoring > that, as I was discussing manually pinning in ntp.conf. Bad idea. We are both discussing manual pinning in ntp.conf > Do we want to support DANE? If so, instead of or in addition to manual > pinning in ntp.conf? Nope. At least not for a long time. I bring up DANE because it is very well documented. we;ll understood, and well deployed. Even ntpsec.org uses it. The DANE people thought of all the different ways you might want to do the hash and what gets hashed. That hash, with its options of hash type and what is hashed, can go in DNS, or just in the ntp.conf file. So 90% of the RFC can be the template for what goes in ntp.conf. Oh, just to make this fraudulent cert thing real, I'll remind everyone of when someone got a valid *.google.com cert: https://www.esecurityplanet.com/browser-security/fraudulent-ssl-cert-for-google-revoked.html A simple google will bring up many other serious events. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpl8OdiPyX4J.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
You've mentioned DANE a couple of times. I've been mostly ignoring that, as I was discussing manually pinning in ntp.conf. Do we want to support DANE? If so, instead of or in addition to manual pinning in ntp.conf? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 18:36:54 -0500 Richard Laager via devel wrote: > On 3/28/19 6:26 PM, Hal Murray via devel wrote: > > > > Gary said: > >>> There is a downside. Every time it changes, you have to take > >>> a leap of faith when you re-pin it, rather than getting normal > >>> CA validation. > >> You miss the point, this is addition to normal CA validation, not > >> an alternative to it. Just like HPKP. > > > > I'm missing something important. Why would I need additional > > validation? Isn't normal certificate validation good enough? > > In normal validation, ANY root CA can sign a certificate for my domain > and it will be trusted by clients. Yes, a bad thing. Why DANE and HPKP were invented. > I might want to pin the NTS association for ntp1.wiktel.com to require > that its certificate be issued by Let's Encrypt. Or, I might want to > pin it to my internal CA. Yup. Now you're getting it. Thus the 4 DANE types. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpZsUfWKRcsd.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Hal! On Thu, 28 Mar 2019 16:26:55 -0700 Hal Murray via devel wrote: > Gary said: > >> There is a downside. Every time it changes, you have to take > >> a leap of faith when you re-pin it, rather than getting normal > >> CA validation. > > You miss the point, this is addition to normal CA validation, not an > > alternative to it. Just like HPKP. > > I'm missing something important. Why would I need additional > validation? Isn't normal certificate validation good enough? There have been many cases, some in the last year, where black hats have tricked CA's into issuing them certs for major domains. Then the bogus certs used for fraud. That is why HPKP and DANE were invented. Please note, I am not suggesting this will be a problem for ntpd like it has become a problem for XMPP, smtp, https, etc. Yet. One cool thing about HPKP and DANE is that zero user configuration is required to get the extra security. Potential extra security is just an added feature that you get for free once you add certificate pinning to handle the ostfalia case. Check the pin, but do not check the chain: server ostfalie.de noval pin XXX Check the pin, and check the chain: server rellim.com pin YY Now if someone can trick a CA into giving them a valid rellim.com cert the connection will still be secure. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgprpKl0_6vk6.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 6:26 PM, Hal Murray via devel wrote: > > Gary said: >>> There is a downside. Every time it changes, you have to take >>> a leap of faith when you re-pin it, rather than getting normal >>> CA validation. >> You miss the point, this is addition to normal CA validation, not an >> alternative to it. Just like HPKP. > > I'm missing something important. Why would I need additional validation? > Isn't normal certificate validation good enough? In normal validation, ANY root CA can sign a certificate for my domain and it will be trusted by clients. I might want to pin the NTS association for ntp1.wiktel.com to require that its certificate be issued by Let's Encrypt. Or, I might want to pin it to my internal CA. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Gary said: >> There is a downside. Every time it changes, you have to take >> a leap of faith when you re-pin it, rather than getting normal >> CA validation. > You miss the point, this is addition to normal CA validation, not an > alternative to it. Just like HPKP. I'm missing something important. Why would I need additional validation? Isn't normal certificate validation good enough? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 18:14:16 -0500 Richard Laager via devel wrote: > On 3/28/19 6:07 PM, Gary E. Miller via devel wrote: > > Yo Richard! > > > > On Thu, 28 Mar 2019 17:55:36 -0500 > > Richard Laager via devel wrote: > > > >> On 3/28/19 5:47 PM, Gary E. Miller via devel wrote: > >>> Don't care. I like that the cert is pinned. > >> > >> There is a downside. Every time it changes, you have to take a > >> leap of faith when you re-pin it, rather than getting normal CA > >> validation. > > > > You miss the point, this is addition to normal CA validation, not > > an alternative to it. Just like HPKP. > > No, it's not. Pidgin only pops up that dialog if it can't validate the > certificate. So validation has failed, and you're taking a leap of > faith to accept the new certificate each time it changes. So, maybe, the message is imprecise: The cert changed, please approve. But, once again, I don't care exactly what Pidgin is doing. Just using it as one of many comman examples of how key pinning is done all around us all the time. There are the good, the bad, and the ugly. We just need to decide what is correct for NTPsec to do. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpTFrV0UQ46j.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 6:07 PM, Gary E. Miller via devel wrote: > Yo Richard! > > On Thu, 28 Mar 2019 17:55:36 -0500 > Richard Laager via devel wrote: > >> On 3/28/19 5:47 PM, Gary E. Miller via devel wrote: >>> Don't care. I like that the cert is pinned. >> >> There is a downside. Every time it changes, you have to take a leap of >> faith when you re-pin it, rather than getting normal CA validation. > > You miss the point, this is addition to normal CA validation, not > an alternative to it. Just like HPKP. No, it's not. Pidgin only pops up that dialog if it can't validate the certificate. So validation has failed, and you're taking a leap of faith to accept the new certificate each time it changes. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 17:55:36 -0500 Richard Laager via devel wrote: > On 3/28/19 5:47 PM, Gary E. Miller via devel wrote: > > Don't care. I like that the cert is pinned. > > There is a downside. Every time it changes, you have to take a leap of > faith when you re-pin it, rather than getting normal CA validation. You miss the point, this is addition to normal CA validation, not an alternative to it. Just like HPKP. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpoVhTDKWwZ8.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 17:54:04 -0500 Richard Laager via devel wrote: > On 3/28/19 5:35 PM, Gary E. Miller via devel wrote: > > Yo Richard! > > > > On Thu, 28 Mar 2019 17:00:51 -0500 > > Richard Laager via devel wrote: > > > >> On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: > >>> server nts3-e.ostfalia.de:443 nts noval pin > >>> 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 > >> > >> I think the "pin" option should take (as an argument or in its > >> name), the hash algorithm being used (presumably SHA-256 here, but > >> it could change in the future). For example, HPKP uses pin-sha256 > >> as the name. > > > > If we are going to design the option, then it needs to algorithm, > > and what it is pinned to. You can pin to the provided cert, the > > cert that signed the cert, the full chain of the cert, the root > > that signed the cert, or just the public key of the cert. > > I think public key (as opposed to certificate) pinning is the common > approach these days. The application simply requires that one of the > public keys in the chain match the pinned public key. The user can > decide if they want to pin the server public key, the intermediate CA, > or the root CA. Tell that to Matt Selsky. He changed the ntpsec.org pinning to be that if the signing cert. Updating the pins every 90 days was a PITA. > That said, we need to think carefully about the intended interactions > between pinning and validation (or lack thereof with noval). Not need to think about it. Lot's of prior art. Just use that. The DANE is well thought out. > I think that you in particular are using pinning to avoid adding the > server operator's private root certificate that you don't trust. Today, yes. And no way I'll ever add a provate root cert I don't have enourmous trust in. > So > either pinning needs to override validation, or you'll still need to > continue to specify "noval". Uh, no. Pinning does not necessarily override validation, it is another type of validation. Just as the pinning in the ntpsec.org records add to, but does not replace, other validation. ? I think you're intending for the latter. Uh, no. Many combination are possible, they all have a use case. > That's all fine. The only tricky thing is that if you pin something > other than the end public key (i.e. you pin the intermediate or root > CA), then we _do_ need to validate the chain up to that point (albeit > maybe still ignoring the NotBefore/NotAfter times). Uh, no. Just as easy to pin to the end cert. No need to go up. And, please note, I have not brought up cert times. That is yet another lengthy discussion. Let us do that later and not confuse this discussion. > An alternative approach to meet this particular demand would be to > allow specifying a root certificate per NTS association. Gee, I think that is called pinning. DANE type 1. > The > advantage of this approach would be that you can remove "noval" and > thus get the usual validation, including checking certificate > NotBefore/NotAfter times. Ugh, please no. Pinning is an alternative to noval, not a replacement. smtp, https, XMPP, etc. have all gone down this road before, let us not try to reinvent a wheel that already works very well. And, let's do the cert time discussion later... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpaHoL73Csra.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 5:35 PM, Gary E. Miller via devel wrote: > Yo Richard! > > On Thu, 28 Mar 2019 17:00:51 -0500 > Richard Laager via devel wrote: > >> On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: >>> server nts3-e.ostfalia.de:443 nts noval pin >>> 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 >> >> I think the "pin" option should take (as an argument or in its name), >> the hash algorithm being used (presumably SHA-256 here, but it could >> change in the future). For example, HPKP uses pin-sha256 as the name. > > If we are going to design the option, then it needs to algorithm, and > what it is pinned to. You can pin to the provided cert, the cert that > signed the cert, the full chain of the cert, the root that signed the > cert, or just the public key of the cert. I think public key (as opposed to certificate) pinning is the common approach these days. The application simply requires that one of the public keys in the chain match the pinned public key. The user can decide if they want to pin the server public key, the intermediate CA, or the root CA. That said, we need to think carefully about the intended interactions between pinning and validation (or lack thereof with noval). I think that you in particular are using pinning to avoid adding the server operator's private root certificate that you don't trust. So either pinning needs to override validation, or you'll still need to continue to specify "noval". I think you're intending for the latter. That's all fine. The only tricky thing is that if you pin something other than the end public key (i.e. you pin the intermediate or root CA), then we _do_ need to validate the chain up to that point (albeit maybe still ignoring the NotBefore/NotAfter times). An alternative approach to meet this particular demand would be to allow specifying a root certificate per NTS association. Then you could specify the private root CA for this particular association, without needing to trust it system-wide, or even ntpd-wide. The advantage of this approach would be that you can remove "noval" and thus get the usual validation, including checking certificate NotBefore/NotAfter times. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 5:47 PM, Gary E. Miller via devel wrote: > Don't care. I like that the cert is pinned. There is a downside. Every time it changes, you have to take a leap of faith when you re-pin it, rather than getting normal CA validation. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 17:37:48 -0500 Richard Laager via devel wrote: > On 3/28/19 5:29 PM, Gary E. Miller via devel wrote: > > Tell that to the pidgin folks. > I haven't been active in a while, but I'm a Pidgin developer. > > > I've seen it for years on many > > workstations. If there is a setting for it, I can't find it... > > I have my Gmail XMPP account setup this way: Don't care. I like that the cert is pinned. I just bring it up as yet another very common example of pinning. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpnWKORLsXuS.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 5:29 PM, Gary E. Miller via devel wrote: > Tell that to the pidgin folks. I haven't been active in a while, but I'm a Pidgin developer. > I've seen it for years on many > workstations. If there is a setting for it, I can't find it... I have my Gmail XMPP account setup this way: Basic tab: Protocol: XMPP Username: rlaager Domain: gmail.com Advanced tab: Connection security: Require encryption [ ] Allow plaintext auth over unencrypted streams ^ That is UNchecked. Connect port: 5222 Connect server: (blank) >> Is this for XMPP? > > Yup. XMPP to talk.google.com My guess is that you have a "Connect server" of talk.google.com specified. It's been a long time, but perhaps that was previously a default or previously recommended or previously required. But if the SRV records are setup correctly on the domain (for me, gmail.com), it should not be necessary to specify the "Connect server". -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 17:00:51 -0500 Richard Laager via devel wrote: > On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: > > server nts3-e.ostfalia.de:443 nts noval pin > > 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 > > I think the "pin" option should take (as an argument or in its name), > the hash algorithm being used (presumably SHA-256 here, but it could > change in the future). For example, HPKP uses pin-sha256 as the name. If we are going to design the option, then it needs to algorithm, and what it is pinned to. You can pin to the provided cert, the cert that signed the cert, the full chain of the cert, the root that signed the cert, or just the public key of the cert. Some pinning clients also specify a max age for the pin. This goes into detail on many of the options: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning Here is sample C code to have OpenSSL do pinning: https://www.owasp.org/images/f/f7/Pubkey-pin-openssl.zip RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpVqu6uXXmVf.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Thu, 28 Mar 2019 17:01:50 -0500 Richard Laager via devel wrote: > On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: > > Ever notice in pidgin how every time google > > changes there cert you are asked to approve the new one? > > That shouldn't be happening. It sounds like you have something setup > wrong. Tell that to the pidgin folks. I've seen it for years on many workstations. If there is a setting for it, I can't find it... > Is this for XMPP? Yup. XMPP to talk.google.com RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpyd1usMmTVv.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: > Ever notice in pidgin how every time google > changes there cert you are asked to approve the new one? That shouldn't be happening. It sounds like you have something setup wrong. Is this for XMPP? -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/28/19 3:01 PM, Gary E. Miller via devel wrote: > server nts3-e.ostfalia.de:443 nts noval pin > 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 I think the "pin" option should take (as an argument or in its name), the hash algorithm being used (presumably SHA-256 here, but it could change in the future). For example, HPKP uses pin-sha256 as the name. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Hal! On Wed, 27 Mar 2019 22:08:14 -0700 Hal Murray via devel wrote: > > Only if the cert is not pinned. Pretty much every else I do with > > certs eventually requires pinning. NTPsec will be no different. > > Could somebody please give me a lesson on this area? google and wikipedia are good places to start: https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning etc. > What is pinning? Why have I not encountered it before? You have. Just did not grok it happening. All the browsers do it. Ever noticed when a cert fails with https you are given the option to accept the cert? That is pinning. Browsers also use HPKP, HTTP Public Key Pinning (RFC 7469): https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning Many chat clients do it. Ever notice in pidgin how every time google changes there cert you are asked to approve the new one? That is pinning. Ever notice how when a email to an email list is directed to another email list and it bounces with a DANE error? That is pinning. DANE uses TLSA records in DNS that contain the cert pin hashs. There are many online tools to generate the hash per RFC 6698; https://ssl-tools.net/tlsa-generator > If ntpsec supported it, what would it look like and what would you do > to use it? Right now ostfalia uses a private CA. So to connect I do this: server nts3-e.ostfalia.de:443 nts noval I happen to know the root CA for LE has this pin hash: 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 Since I use LE certs, I have pinning records in my DNS so end users have another way to validate the certs I use: # dig _443._tcp.www.rellim.com ANY ; <<>> DiG 9.12.3-P4 <<>> _443._tcp.www.rellim.com ANY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39525 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 0b91fbce1dcc17f0b1a287195c9d25e1690aeb81b3edcb63 (good) ;; QUESTION SECTION: ;_443._tcp.www.rellim.com. IN ANY ;; ANSWER SECTION: _443._tcp.www.rellim.com. 86400 IN RRSIG TLSA 8 5 86400 20211216234627 20190322234627 6366 rellim.com. UEtz0oHRGpezsZSHox8NAj2GwZQFeW+MWnf9ioe1nSEn2OBaNnFx7WFB 93UcYdVx9i0XH/oR5FM49MsaJP/9Qb9qLfXSsZAp6KSEgwEOwAOO2uq3 svDjA3Rml3XLXugw49J7WJYNNvbleHb2msv4UakrQeWm53Pj6UVqNYvR D2E= _443._tcp.www.rellim.com. 86400 IN RRSIG TLSA 8 5 86400 20211216234627 20190322234627 9234 rellim.com. lWQN0pFrXwwuyG3ksCou9LVa1WmDWF/eGN0Ypz/+HGoFe7sZYyy58yS4 xP+ruMbjHxM5IxxxeYNcMGnZqm8rNYLxho/4QUXqV9JjYYkGphULivj1 DnV/Bi5u8jmYYPtg6OJq4b0/h35fSI/hDtaAmwEOC9pZ16fhhOh8UDJC OZw= _443._tcp.www.rellim.com. 86400 IN RRSIG TLSA 8 5 86400 20211216234627 20190322234627 14625 rellim.com. F8NQNAIFrv1AEr+Vy817LAAFcLbqpueBPX9VLzlWiOC0kecHcro1SQl9 zdvD6D1x0z5qbfkUBoLQ0e6nfnYrli/Vl8nTzEH9f/4LCjy/lFkcou1c HSiPfqEGq8HvDdxzcPsZF8bbwHAfxPw8AlUGzapb92VK0f43EWjwRTXo Poc= _443._tcp.www.rellim.com. 86400 IN RRSIG TLSA 13 5 86400 20211216234627 20190322234627 10167 rellim.com. wc+u0lQE3nTPLkoK11J9urVamjQbGeSDkR+wvtzYYLnIjPe9Ph5ujSSw eys0uf6iSJ1ZGKi5qfR1SRQ69un5Yw== _443._tcp.www.rellim.com. 86400 IN TLSA2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18 So, if I was going to pin the ostfalia server, I could check to see if they pin in DNS. They do not. So I would generate their pin has, and attach it to their server record: server nts3-e.ostfalia.de:443 nts noval pin 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 To make it eay, NTSs could always generate the hash and put it in the logs. On that note, I'd also like the logs to show the NTPD server and port from the NTS-KE exchange. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpSjcKwYKb27.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Cert pinning
> Only if the cert is not pinned. Pretty much every else I do with certs > eventually requires pinning. NTPsec will be no different. Could somebody please give me a lesson on this area? What is pinning? Why have I not encountered it before? If ntpsec supported it, what would it look like and what would you do to use it? Any good URLs discussing this area? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
