Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >A large attack surface can't be avoided with the MTI for these protocols. It can be vastly reduced by only implementing the MTI rather than every possible bell and whistle in existence. Also since an RTU (remote terminal unit) doesn't need to talk to every single piece of broken software on the planet but only what the master station it's talking to is running, all you need is whatever the de facto universal standard config is, either DH+RSA+AES or P256 ECDH/ECDSA+AES and nothing else, no suite negotiation, no extensions, nothing. And that goes all the way up and down the protocol stack. TCP options, fragmentation, UDP, ICMP, packet reordering, most flow control and congestion avoidance, none of that's there. Fuzzing these things is mostly a waste of time because there's no alternate code paths or corner cases to discover in the fuzzing. Makes them remarkably resistant to attack because there's very little there to attack. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Wed, Aug 17, 2022 at 11:34 AM Peter Gutmann wrote: > Kyle Rose writes: > > >IMO, the two requirements "Prohibit upgrades" and "Leverage > general-purpose > >network protocols with large attack surfaces" are in direct conflict. > > Only if you implement them with large attack surfaces, for which again see > my > earlier comments. > A large attack surface can't be avoided with the MTI for these protocols. And if you don't implement what's required, don't complain when it doesn't interop. 路♂️ Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >IMO, the two requirements "Prohibit upgrades" and "Leverage general-purpose >network protocols with large attack surfaces" are in direct conflict. Only if you implement them with large attack surfaces, for which again see my earlier comments. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Wed, Aug 17, 2022 at 11:10 AM Peter Gutmann wrote: > See my earlier comments on this. > Honestly, it sounds like these devices maybe shouldn't be using internet technologies that were designed with certain assumptions about extensibility in mind. With such strong constraints not only on behavior but on implementation, it really seems like the right thing to do is to shrink-wrap every interface around exactly what you need and avoid all unnecessary complexity. That means no TLS, no X.509, no IP, etc. IMO, the two requirements "Prohibit upgrades" and "Leverage general-purpose network protocols with large attack surfaces" are in direct conflict. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >I wish I had some more context for this area of embedded devices. For example: > > * Why is an RTC more expensive (along whatever axis you choose) than a NIC >(wifi or ethernet)? Quoting "IoT / SCADA Crypto, What you Need to Know": The device often won't have any on-board time source because it's not feasible to include an RTC in the design. An RTC adds considerable cost (possibly as much as the rest of the device), may be larger/heavier than the rest of the device, typically requires one or more extra assembly steps to fit because they can't be installed via pick-and-place and reflow soldering, make the device more vulnerable to issues like high and low temperatures that embedded devices are typically exposed to, and wear out (the batteries die) long before the rest of the device does. > * What classes of devices would reasonably sit on a shelf for ten years and >subsequently prove useful without being updated? Any number of SCADA devices. They're an exact replacement for an existing device, so the fact that you're replacing something that's failed with something else that's exactly identical is a requirement. You don't want to replace it with something that someone's fiddled with in the meantime because you can't guarantee that it'll behave the same as the original device did. > * If it's been sitting on a shelf for ten years, why is reattaching it to >the network easy, while plugging it into an upgrade klosk first and *then* >reattaching it to the network is hard? See my earlier comments on this. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >Expired CAs are definitely a problem for PKI participation after such a >delay, but probably one that is dwarfed by the near certain existence of >known vulnerabilities in firmware that hasn't been updated in 10 years. So >it's probably best they remain air-gapped and don't participate in active >networked systems until they've been updated, which would then include new CA >certificates. Getting a bit off-track, but the ones I've encountered won't be updated, typically because there's no way to do so and/or because the software is written to a higher standard than the usual Internet-facing stuff. One common defence, although it's not really intended as such, is that there's nothing there to attack, everything is hardcoded and fixed and does just barely enough to communicate with the other side, so there's very little attack surface. >Consequently, I would not recommend any device interact with the web without >being able to establish that server certificates have not expired. Sure, but that's web use. For SCADA use you don't care (or check) whether the certificates have expired or not because that's the difference between "things work" and "things don't work": "When PLCs’ certificates expire, they just disappear off the network. Plus, 99 percent of the industrial world has no idea what a certificate is, so how do they troubleshoot the problem at 2am?" (from "Control Systems Security from the Front Lines"). I would assume this extends to lots of non-SCADA cases as well: If you want things to work, you don't check for cert expiry. Or revocation. >>Ignoring CA billing-cycle^H^H^Hexpiry dates > >You repeatedly bring up this point, but you do realize that one of the people >you're arguing with was instrumental in the establishment of a mechanism for >provisioning *free* web PKI certificates, right? The cost of procuring signed >certificates is no longer an obstacle to participating in the web PKI. Sure, and I pointed out that it was a thing for commercial CAs. In any case though I wasn't commenting on that but on why a 1-year expiration period is used, because the alternative was to point out that tying a supposed security parameter to the earth's (approximate) orbital period seems a bit paleolithic [0]. And in that case I think we should take a less geocentric view of certificate expiry and instead use the orbital period of the largest planet in the solar system, Jupiter, over 300 times the size of the earth so it's got to be more significant. Giving certificates an expiry time of 12 years to match Jupiter's orbital period should be enough to cover most use cases (extending this to Pluto, and whether it should actually be Pluto or stop at full planets like Neptune, is left as an open discussion point). Peter. [0] Based on nature-worship dating back to the Old Stone Age, I don't know whether they knew the earth's orbital period back then or not but I believe it was well known by the Bronze Age. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Sun, Aug 14, 2022 at 5:25 PM Hal Murray wrote: > Thanks. > > > It's been a few years, but IIRC my thinking was that the degree of trust > > required in the Roughtime servers' long-term public keys is very low: > you're > > trusting them only for one server's assertion of the current time, not > for > > general web traffic; and if you ask enough servers, the likelihood of > being > > tricked into trusting a bad timestamp is very low even over long time > > periods. > > I've been assuming self-signed certificates with long lifetimes -- one per > server. > It's a testament to how certificate infrastructure has evolved that one year is now considered "long lived". :-) I was responding to an earlier hypothetical about a device sitting on a shelf for ten years, and trying to figure out how one could bootstrap the PKI after that time without explicit intervention. I'm starting to think I was trying too hard to address a (possibly contrived) edge case that really deserves a simpler solution: manual re-bootstrapping. > In other words, much of the security of the scheme is in the practical > > difficulty of mounting a successful attack even if the keys have been > > compromised. NTS doesn't even attempt to address this kind of attack > vector. > > Is there a first order difference between NTS using self signed > certificates > and Roughtime? > Miroslav's answer is probably the right one: Roughtime gives you the ability not only to detect bad timestamps but to prove it to others. Upon reflection, that doesn't seem especially useful in this context because you're already talking about devices that have appeared out of nowhere after a long period of inactivity. There have been semi-endless debates about how many NTP servers to use. (I > haven't seen one recently.) With 3 servers, 2 can outvote 1 bad guy. With > 4 > servers, you still have 3 if one is down. ... Adding security > complicates > that discussion. You have to add deliberate malfeasance to the list of > things > that can go wrong. And things can change over 10 years. > > Are there any good papers or web pages discussing the security of TLS? > Did you mean NTP here? The security of TLS has been discussed far and wide. :-) One quirk on my 10 year problem. If the boxes are sitting on a shelf, it's > at > least possible to open them up and update firmware. It would be > expensive, > but it is another branch of the cost-benefit tree. > And this was my first bit of advice to Peter: if it's out of service that long, it probably has known vulnerabilities, so you should probably upgrade the firmware before reattaching it to a network or it's likely to get pwn3d. That firmware update would come with updated CAs, and a notion of the current time (to bootstrap the first TLS handshakes, after which trusted sources can provide updated timestamps) if the device has no RTC of its own. I wish I had some more context for this area of embedded devices. For example: * Why is an RTC more expensive (along whatever axis you choose) than a NIC (wifi or ethernet)? * What classes of devices would reasonably sit on a shelf for ten years and subsequently prove useful without being updated? * If it's been sitting on a shelf for ten years, why is reattaching it to the network easy, while plugging it into an upgrade klosk first and *then* reattaching it to the network is hard? After this thread, I'm now trying to figure out why this whole endeavor isn't contrived. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Thanks. > It's been a few years, but IIRC my thinking was that the degree of trust > required in the Roughtime servers' long-term public keys is very low: you're > trusting them only for one server's assertion of the current time, not for > general web traffic; and if you ask enough servers, the likelihood of being > tricked into trusting a bad timestamp is very low even over long time > periods. I've been assuming self-signed certificates with long lifetimes -- one per server. > Such an attack would require both access to a large number of long-term > private keys whose public keys are embedded in the client attack target, as > well as the ability to intercept traffic intended for each of these servers > at whatever moment the client initiates the Roughtime protocol (which > probably implies a long-term undetected network presence). This is clearly a > higher bar than simply trusting a web PKI certificate signed some > indeterminate time ago without respecting the expiration date and without > being able to update CRLs on startup (which also poses trust anchor turtles > all the way down). > In other words, much of the security of the scheme is in the practical > difficulty of mounting a successful attack even if the keys have been > compromised. NTS doesn't even attempt to address this kind of attack vector. Is there a first order difference between NTS using self signed certificates and Roughtime? There have been semi-endless debates about how many NTP servers to use. (I haven't seen one recently.) With 3 servers, 2 can outvote 1 bad guy. With 4 servers, you still have 3 if one is down. ... Adding security complicates that discussion. You have to add deliberate malfeasance to the list of things that can go wrong. And things can change over 10 years. Are there any good papers or web pages discussing the security of TLS? One quirk on my 10 year problem. If the boxes are sitting on a shelf, it's at least possible to open them up and update firmware. It would be expensive, but it is another branch of the cost-benefit tree. Again, thanks for your helpful input. -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Sat, Aug 13, 2022 at 11:16 PM Hal Murray wrote: > > IIRC, this is one of the main arguments for advancing Roughtime: > > I took a look at draft 06. I don't see how it helps. Am I missing > something? > > Here is the key section: > > 6.4 Validity of Response > A client MUST check the following properties when it receives a > response. We assume the long-term server public key is known to the > client through other means. > > If I can distribute valid long-term keys, I can use them to sign the > certificates for NTS-KE servers and don't need Roughtime to get started. > It's been a few years, but IIRC my thinking was that the degree of trust required in the Roughtime servers' long-term public keys is very low: you're trusting them only for one server's assertion of the current time, not for general web traffic; and if you ask enough servers, the likelihood of being tricked into trusting a bad timestamp is very low even over long time periods. Such an attack would require both access to a large number of long-term private keys whose public keys are embedded in the client attack target, as well as the ability to intercept traffic intended for each of these servers at whatever moment the client initiates the Roughtime protocol (which probably implies a long-term undetected network presence). This is clearly a higher bar than simply trusting a web PKI certificate signed some indeterminate time ago without respecting the expiration date and without being able to update CRLs on startup (which also poses trust anchor turtles all the way down). In other words, much of the security of the scheme is in the practical difficulty of mounting a successful attack even if the keys have been compromised. NTS doesn't even attempt to address this kind of attack vector. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Christian Huitema writes: >For example, the device will get some notion of time from the dates in the >certificates that are provisioned during enrollment. Maybe that's enough to >move from the 10 years scenario to the one year scenario, and then call NTP. >But it would probably be better to spell it out. That's one of several ways I've seen of getting an approximate time, if you get fed a cert with validFrom = X then you know that it's at least time X. A more common one is to use HTTP as NTP and take the time from the "Date:" line. For store-and-forward, you take the message signing time, e.g. the CMS signingTime attribute. One I haven't seen for awhile (thankfully) is to take the time in the TLS server hello, the gmt_unix_time, and use that (I never set that to anything valid so as not to expose the client or server to time-based attacks, problem was that sometimes it looked valid enough that it messed up the other side). In any case there's no need to implement yet another protocol on top of the existing ones, you can make do with what you've got - there are timestamps in so many things that you can typically find one in existing messaging. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
> IIRC, this is one of the main arguments for advancing Roughtime: I took a look at draft 06. I don't see how it helps. Am I missing something? Here is the key section: 6.4 Validity of Response A client MUST check the following properties when it receives a response. We assume the long-term server public key is known to the client through other means. If I can distribute valid long-term keys, I can use them to sign the certificates for NTS-KE servers and don't need Roughtime to get started. -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On 8/11/2022 1:54 PM, Benjamin Kaduk wrote: On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote: Isn't the ANIMA WG working on these scenarios? If there is a formal "enrollment" process for adding a device to a network, that process could include setting the time, and possibly performing updates. I say "possibly" here, because in scenarios like "disaster recovery", the local network may not have global connectivity. But even so, setting the time during enrollment seems logical. https://www.rfc-editor.org/rfc/rfc8995.html#section-2.6 seems to already have some discussion of how to handle the lack of a(n accurate) real-time clock, yes. There is a bit of a missed opportunity here. That section explains how to perform enrollment despite not having a good notion of time on the device, but it does not explain how the device could use enrollment to reset its clocks. Maybe that's obvious and I am just missing it. For example, the device will get some notion of time from the dates in the certificates that are provisioned during enrollment. Maybe that's enough to move from the 10 years scenario to the one year scenario, and then call NTP. But it would probably be better to spell it out. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On 8/9/22 4:12 PM, Eric Rescorla wrote: n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote: On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > 3. Are you aware of some other set of rules for certificate issuance that require revocation after the certificate has expired? Removing certs from revocation lists after the certificate has expired is pretty much required in any scalable deployment which has a non-trivial time horizon (basically any commercial CA). That is because the list would grow without bounds. It's not necessary to solve the 'Getting started, clock not set yet' feature, however. For that case you only need to ignore 'not Before' when validating a TLS cert associated with an NTS call. You can always arrange for the unset clock to be older than the current time, so if the cert is expired based on the unset clock, the cert is expired for real. bob -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote: > > Isn't the ANIMA WG working on these scenarios? If there is a formal > "enrollment" process for adding a device to a network, that process could > include setting the time, and possibly performing updates. I say "possibly" > here, because in scenarios like "disaster recovery", the local network may > not have global connectivity. But even so, setting the time during > enrollment seems logical. https://www.rfc-editor.org/rfc/rfc8995.html#section-2.6 seems to already have some discussion of how to handle the lack of a(n accurate) real-time clock, yes. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On 8/11/2022 8:56 AM, Kyle Rose wrote: On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann wrote: So we're down to mostly non-web-PKI devices and/or the ten year problem, of which I've encountered the latter several times with gear that sits on a shelf for years and then when it's time to provision it all the certificates have long since expired, which is another reason why you ignore expiry dates (or at least you ignore them after you get hit by the first major outage caused by this because until then no-one realised that it was an issue, a ticking time- bomb that may take years to detonate). Expired CAs are definitely a problem for PKI participation after such a delay, but probably one that is dwarfed by the near certain existence of known vulnerabilities in firmware that hasn't been updated in 10 years. So it's probably best they remain air-gapped and don't participate in active networked systems until they've been updated, which would then include new CA certificates. Isn't the ANIMA WG working on these scenarios? If there is a formal "enrollment" process for adding a device to a network, that process could include setting the time, and possibly performing updates. I say "possibly" here, because in scenarios like "disaster recovery", the local network may not have global connectivity. But even so, setting the time during enrollment seems logical. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann wrote: > So we're down to mostly non-web-PKI devices and/or the ten year problem, of > which I've encountered the latter several times with gear that sits on a > shelf > for years and then when it's time to provision it all the certificates have > long since expired, which is another reason why you ignore expiry dates > (or at > least you ignore them after you get hit by the first major outage caused by > this because until then no-one realised that it was an issue, a ticking > time- > bomb that may take years to detonate). > Expired CAs are definitely a problem for PKI participation after such a delay, but probably one that is dwarfed by the near certain existence of known vulnerabilities in firmware that hasn't been updated in 10 years. So it's probably best they remain air-gapped and don't participate in active networked systems until they've been updated, which would then include new CA certificates. That leaves revocation, which alongside ignoring expiry dates is another > thing > that's commonly ignored in SCADA, both for the same reason as expiry dates > are > ignored, you don't want to DoS yourself, and because in many cases there's > neither a logical nor a practical basis for revocation or revocation > checks. > For example in typical SCADA networks a device is removed by shutting off > its > access, not by adding an entry to a CRL somewhere and hoping someone > notices. > In fact it's not even clear what certificate would be revoked in order to > achieve some effect, or why. Revocation of device certs to remove their access isn't what I'm thinking of. I'm talking about devices that need to establish trust in remote services via networks of questionable integrity (the public internet, but maybe moreso private networks with lots of hiding places and little active monitoring). Revocation/expiration are complementary tools: periodic expiration means you don't need to maintain revocations forever, and revocation means you don't need expirations to be *too* short and still strictly limit the hazard period resulting from private key compromise. You want to respect both, but for better or for worse the web's threat model has seen revocation as really-nice-to-have and expiration as mandatory-for-interoperation. Consequently, I would not recommend any device interact with the web without being able to establish that server certificates have not expired. That means there is a requirement to somehow bootstrap the current time when needed, whether via device RTC or via some network-connected entity in which trust may be established in some way that is far less general than web PKI. This is a rule-of-thumb: clearly there are ways to safely interact with the web even via cleartext transports, assuming some other kind of out-of-band mechanism for establishing trust in any transferred content. But that goes beyond the scope of the web security model. Ignoring CA billing-cycle^H^H^Hexpiry dates > You repeatedly bring up this point, but you do realize that one of the people you're arguing with was instrumental in the establishment of a mechanism for provisioning *free* web PKI certificates, right? The cost of procuring signed certificates is no longer an obstacle to participating in the web PKI. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Kyle Rose writes: >What Peter said isn't quite right, since (for example) you wouldn't want to >be obliged to distribute revocations for compromised but long-expired >certificates under the assumption that a properly-functioning client wouldn't >accept them anyway Ah, good point. However, you also need to look at what problem is being solved. The OP mentioned systems without real-time clocks, which most of the time means systems outside of the web PKI - try starting a PC whose clock is too far off and lots and lots of things break badly, at which point you ask the user to set the time correctly regardless of NTP availability. So we're down to mostly non-web-PKI devices and/or the ten year problem, of which I've encountered the latter several times with gear that sits on a shelf for years and then when it's time to provision it all the certificates have long since expired, which is another reason why you ignore expiry dates (or at least you ignore them after you get hit by the first major outage caused by this because until then no-one realised that it was an issue, a ticking time- bomb that may take years to detonate). That leaves revocation, which alongside ignoring expiry dates is another thing that's commonly ignored in SCADA, both for the same reason as expiry dates are ignored, you don't want to DoS yourself, and because in many cases there's neither a logical nor a practical basis for revocation or revocation checks. For example in typical SCADA networks a device is removed by shutting off its access, not by adding an entry to a CRL somewhere and hoping someone notices. In fact it's not even clear what certificate would be revoked in order to achieve some effect, or why. In addition since revocation checking assumes online access to a CA, which typically isn't the case (I know of one setup where CRL delivery is by USB key once a year or so, and AFAIK the CRL is always empty because you don't want to knock a system offline with a revocation), there's no practical revocation checking done even if someone can figure out a logical reason for performing one. So I think before jumping in with a solution, we'd need to look at actual real-world usage cases to determine what actually needs to be solved. Ignoring CA billing-cycle^H^H^Hexpiry dates seems to be the simplest solution for many cases, and is more or less necessary for the ten-year problem. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 09, 2022 at 04:12:37PM -0700, Eric Rescorla wrote: > n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote: > > > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > > > > > > Be that as it may, the browsers generally require conformance to the BRs > > > (see, for > > > instance > > > > > https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$ > > > > > S 2.3, > > > > > https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$ > > S 1) > > > so what the BRs say is relevant in this discussion. > > > > While it seems almost inevitable that the Web PKI will be used for some > > deployments of NTS, it also seems that NTS as a protocol is quite > > untethered to > > browser behavior or the Web PKI. So while I agree that the CABF BRs are > > relevant, they probably ought not be treated as the sole authority. > > > > Fair enough. I would make several points: > > 1. Peter's message was not qualified to NTS. He wrote > "For commercial CAs, the expiry time is a billing mechanism, not a security > mechanism. " > > So I was attempting to respond to the bigger picture. Ok. > 2. It seems quite likely that many of the NTS certificates will be from > WebPKI CAs, > just because that's what's easy to get, and so you can't count on them > providing > revocation after expiry. Agreed, that's my "almost inevitable". > 3. Are you aware of some other set of rules for certificate issuance that > require > revocation after the certificate has expired? No. And to be honest I would be somewhat surprised to learn of one, since one of the big gains of having an expiration at all (vs just tracking revocation information) is to simplify the database of revocation information by allowing for pruning after expiry. Perhaps some sort of "official records" system might need it, but that's pure speculation. Private parties not part of a broader PKI can of course use whatever policies and procedures they want. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote: > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > > > > Be that as it may, the browsers generally require conformance to the BRs > > (see, for > > instance > > > https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$ > > > S 2.3, > > > https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$ > S 1) > > so what the BRs say is relevant in this discussion. > > While it seems almost inevitable that the Web PKI will be used for some > deployments of NTS, it also seems that NTS as a protocol is quite > untethered to > browser behavior or the Web PKI. So while I agree that the CABF BRs are > relevant, they probably ought not be treated as the sole authority. > Fair enough. I would make several points: 1. Peter's message was not qualified to NTS. He wrote "For commercial CAs, the expiry time is a billing mechanism, not a security mechanism. " So I was attempting to respond to the bigger picture. 2. It seems quite likely that many of the NTS certificates will be from WebPKI CAs, just because that's what's easy to get, and so you can't count on them providing revocation after expiry. 3. Are you aware of some other set of rules for certificate issuance that require revocation after the certificate has expired? -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > > Be that as it may, the browsers generally require conformance to the BRs > (see, for > instance > https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$ > > S 2.3, > https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$ >S 1) > so what the BRs say is relevant in this discussion. While it seems almost inevitable that the Web PKI will be used for some deployments of NTS, it also seems that NTS as a protocol is quite untethered to browser behavior or the Web PKI. So while I agree that the CABF BRs are relevant, they probably ought not be treated as the sole authority. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Folks, Let’s keep the discussion here professional and on topic. It’s fine to disagree with one another, but please do so in a respectful manner per the IETF Code of Conduct. Thanks, Chris, for the chairs On Tue, Aug 9, 2022, at 6:47 PM, Rob Sayre wrote: > On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote: >> >> P.S. I don't think that this tone "...but go on" is particularly helpful in >> this discussion. > > Well, it's easy. You said "require", and I just give very little > credence to the CABF, because I think it is nonsense. > > That can be a point of disagreement, but you're also on tape heckling > me at an IETF meeting while saying "HTTP Digest" authentication was > "good enough". > > You were of course wrong, but it's a good enough point to leave > sleeping dogs lie as well. > > thanks, > Rob > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 9, 2022 at 3:47 PM Rob Sayre wrote: > On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote: > >> >> P.S. I don't think that this tone "...but go on" is particularly helpful >> in this discussion. >> > > Well, it's easy. You said "require", and I just give very little credence > to the CABF, because I think it is nonsense. > Be that as it may, the browsers generally require conformance to the BRs (see, for instance https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ S 2.3, https://www.chromium.org/Home/chromium-security/root-ca-policy/ S 1) so what the BRs say is relevant in this discussion. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 9, 2022 at 3:40 PM Eric Rescorla wrote: > > P.S. I don't think that this tone "...but go on" is particularly helpful > in this discussion. > Well, it's easy. You said "require", and I just give very little credence to the CABF, because I think it is nonsense. That can be a point of disagreement, but you're also on tape heckling me at an IETF meeting while saying "HTTP Digest" authentication was "good enough". You were of course wrong, but it's a good enough point to leave sleeping dogs lie as well. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 9, 2022 at 3:33 PM Rob Sayre wrote: > On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote: > >> >> >> On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann >> wrote: >> >>> Hal Murray writes: >>> >>> >Many security schemes get tangled up with time. TLS has time limits on >>> >certificates. That presents a chicken-egg problem for NTP when getting >>> >started. >>> > >>> >I'm looking for ideas, data, references, whatever? >>> >>> For commercial CAs, the expiry time is a billing mechanism, not a >>> security >>> mechanism. >> >> >> The CABF BRs only require that revocation entries be maintained during the >> lifetime of the certificate. >> > > I'm struggling to think of a reason the IETF should consider CABF a > legitimate standards organization, but go on. > It's not a matter of whether CABF is or is not a legitimate SDO but rather of what CA practices are, and those are governed by a combination of the BRs (incidentally Mozilla's policies [0] also specify "unexpired"). -Ekr P.S. I don't think that this tone "...but go on" is particularly helpful in this discussion. [0] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 9, 2022 at 3:15 PM Eric Rescorla wrote: > > > On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann > wrote: > >> Hal Murray writes: >> >> >Many security schemes get tangled up with time. TLS has time limits on >> >certificates. That presents a chicken-egg problem for NTP when getting >> >started. >> > >> >I'm looking for ideas, data, references, whatever? >> >> For commercial CAs, the expiry time is a billing mechanism, not a security >> mechanism. > > > The CABF BRs only require that revocation entries be maintained during the > lifetime of the certificate. > I'm struggling to think of a reason the IETF should consider CABF a legitimate standards organization, but go on. not that I know anything about the problem, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann wrote: > Hal Murray writes: > > >Many security schemes get tangled up with time. TLS has time limits on > >certificates. That presents a chicken-egg problem for NTP when getting > >started. > > > >I'm looking for ideas, data, references, whatever? > > For commercial CAs, the expiry time is a billing mechanism, not a security > mechanism. The CABF BRs only require that revocation entries be maintained during the lifetime of the certificate. I don't know what existing CA practice is, but it appears to me that a compliant CA could simply stop publishing revocation expiration after expiry, in which case a post-expired certificate is in an indeterminate state. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Tue, Aug 9, 2022 at 12:40 AM Hal Murray wrote: > I work on NTP software. NTS (Network Time Security) uses TLS. > > Many security schemes get tangled up with time. TLS has time limits on > certificates. That presents a chicken-egg problem for NTP when getting > started. > IIRC, this is one of the main arguments for advancing Roughtime: https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/ Assuming Roughtime is 'close enough', you can bootstrap NTP and then do whatever else requires an accurate notion of the current time. What Peter said isn't quite right, since (for example) you wouldn't want to be obliged to distribute revocations for compromised but long-expired certificates under the assumption that a properly-functioning client wouldn't accept them anyway, but relying on Roughtime as a bootstrapping mechanism limits the risk of trusting an expired cert. Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On Mon, Aug 8, 2022 at 10:04 PM Peter Gutmann wrote: > Hal Murray writes: > > >Many security schemes get tangled up with time. TLS has time limits on > >certificates. That presents a chicken-egg problem for NTP when getting > >started. > > > >I'm looking for ideas, data, references, whatever? > > For commercial CAs, the expiry time is a billing mechanism, not a security > mechanism. A certificate is no more, or less, valid at 23:59:59 than it > is at > 00:00:01 > On the other end of the spectrum from SCADA hardware, hosting companies now provide "managed"* LetsEncrypt certificates. That means you never worry about the certificate expiring at all, at the cost of paying somewhat high prices for bandwidth. They do have an expiration, but they tend to be replaced many months before it gets close, because that part is free. thanks, Rob * e.g https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
Hal Murray writes: >Many security schemes get tangled up with time. TLS has time limits on >certificates. That presents a chicken-egg problem for NTP when getting >started. > >I'm looking for ideas, data, references, whatever? For commercial CAs, the expiry time is a billing mechanism, not a security mechanism. A certificate is no more, or less, valid at 23:59:59 than it is at 00:00:01, no matter what the subscription renewal time in it says. It's fairly widespread practice in SCADA to completely ignore expiry times because equipment that takes itself offline at 4am at a site six hours' drive away because of an expired certificate is the last thing you want. So set up the TLS connection, ignore the expiry time, perform your NTP update, and then if necessary do the expiry check (unless it's SCADA gear, in which case don't). Nothing of value will be lost. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Getting started, clock not set yet
I work on NTP software. NTS (Network Time Security) uses TLS. Many security schemes get tangled up with time. TLS has time limits on certificates. That presents a chicken-egg problem for NTP when getting started. I'm looking for ideas, data, references, whatever? Is there other work in this area? Is there any sort of consensus on how close a clock needs to be when checking certificates? At this point, I divide the problem into 3 chunks. The first case is easy. I'll call it the RTC case. Most PCs, laptops, and servers have some sort of battery backed clock. As long as it is close enough, everything just works. But how close is close enough? You need a plan for when the battery dies and such. Set the clock from the BIOS. ssh in and set the clock. That requires setting up the ssh keys ahead of time. The second case is something like a Raspberry Pi. They don't have RTCs. Debian has a fake-hwclock module that writes the time to the disk every hour. I call this the one year case. What happens when you leave it on the shelf for a year? Certificates are generally available with only a 1 year lifetime. That's built into popular browsers so everybody else gets stuck with the decision. After a year, nothing works. After 6 months, half of your servers should still work. A vendor could setup 2 servers with their certificates 6 months out of phase so that 1 will last at least a year. Note that games and IoT gear sold through retail channels will hit this problem if they sit on a shelf for a year. The really hard case is the 10 year problem. Consider a spare board sitting on the shelf for 10 years. That's longer than batteries will last for RTCs. Phone companies used to work on this time frame. I think we need to provide them guidance. I've seen two ways. One is to manually set the clock somewhere in the replace-the-board process. I'm picturing a USB port where the technician can plug in his laptop. The laptop can set the time. The other is to use a certificate with a long lifetime. Are those available or does that turn into a self-signed certificate? There is also DNSSEC. I don't know anything about that yet. For the 1 year or 10 year cases, you could "cache" the data in /etc/hosts. Then you need a cron job to keep the cache up to date. Does this make sense? Am I on the right track? ... -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
