Re: [Anima] FYI: Self-Driving Networks without Self-Crashing Networks
> On Jul 8, 2021, at 10:52 PM, Brian E Carpenter > wrote: > > I've just come across Jeff Mogul's keynote speech about self-driving (i.e. > autonomic) networks from a couple of years ago. Well worth reading before > designing your own autonomic network: > https://conferences.sigcomm.org/sigcomm/2018/files/slides/selfdn/keynote.pdf A few things stood out for me. Both from what he said, and from personal experience. He says: * It's really hard to get detailed/accurate/up-to-date network "maps" today IMHO it's essentially impossible to know what a system is doing, or control it, if you have no idea how it's put together. The solution so far has been to add more protocols, more signalling, etc. Which brings us to the next bit. Networks are generally organized by configuration, not by state. i.e. the "state" of the network, such as it is, is buried inside a random grab-bag collection of configuration files and running data structures, on multiple systems, in multiple formats. There is no way to say "move to state X", or even to query what state the network is currently in. States are not composable, so if one state fails, networks cannot fall back to using a parent state. He alludes to this on slide 43: "if the centralized control plane fail-stops, local control continues to "fly straight and level"" Add to that security issues, bugs in implementations, etc. The combination of those factors means that we are likely to get cascading chains of failure. He mentions this on slide 39: "failures are the result of multiple faults". Our networks are getting more fragile over time. SDN simplified this somewhat for a bit, but is perhaps now approaching the peak of complexity, before there's yet another simplifying solution. Alan DeKokk. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] FYI: Self-Driving Networks without Self-Crashing Networks
On Jul 10, 2021, at 12:44 PM, Michael Richardson wrote: > Alan DeKok wrote: >> Networks are generally organized by configuration, not by state. >> i.e. the "state" of the network, such as it is, is buried inside a >> random grab-bag collection of configuration files and running data >> structures, on multiple systems, in multiple formats. There is no way >> to say "move to state X", or even to query what state the network is >> currently in. > > That's an interesting and rather profound observation, I think. Thanks. As background, most of the networking code I've written in the last 25 years is wrong. Not that it doesn't work, it does. But as time progresses, I find myself moving to a much more state oriented approach. The code is easier to understand, and easier to debug > 90% of debugging (of both programs and networks) is about getting the right > set of observations.A difficulty is that it's so hard to capture the > state. Especially when the state is embodied in a collection of variables, and if/then/else procedural code which checks those variables. As compared to "the current state handler is function X. So I know it's in state X". How did it get there? That's easy, instrument the state transitions, and print those out. Alan DeKok. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Registrar certificate EKU bits
On Jul 20, 2021, at 4:40 PM, Michael Richardson wrote: > > When debugging another issue, I found that my test Registrar had stopped > being able to connect to my MASA. Some upgrades to Openssl, Apache meant > that one of those two decided the Extended Key Usage for the client > certificates had better be right. > > What I found: > 1) If there is no EKU, then it's all okay. > 2) If there is an EKU, and it contains only cmcRA, then it is rejected. > 3) If I add "clientAuth" EKU, then it works. > > I don't know if this is enforced in Apache (via some callback), or within > OpenSSL. Having run into similar issues, I suspect a combination of both. OpenSSL does it's own validations, and the application using OpenSSL can add more. For EAP, we've added our own certificate validation callbacks, largely to shut off much of the automatic behavior of OpenSSL. i.e. the "heavy lifting" of checking ASN.1 formats and certificate chains is up to OpenSSL. But the validity of the contents of each cert is up to the application. > There are nothing logged in Apache, so I think it's autocratic actions by > a minor patch level of OpenSSL, and Apache probably needs to override the > behaviour. Or, it could be Apache's certificate verify callback. > The lack of logging on the server is a serious problem. That is a wide-spread issue. We've added voluminous debug logging, which is horrible for the average user, but allows anyone *reading* it to trivially debug fairly complex issues. > What does occur is that there is a TLS level response, an SSL Alert, saying > that the certificate was rejected. "Failed" Why? "Failed". > Perhaps someone else will find this email useful. > Mostly, it convinces me to never set any EKU bits. > I guess, I need to set serverAuth too, now that I think about it. Yes. Alan DeKok. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Re: Concern about draft-ietf-uta-require-tls13-10 with IoT protocols
(Not speaking as UTA chair) On Apr 8, 2025, at 12:05 PM, Toerless Eckert wrote: > Recommending, but not requiring the use of TLS 1.3 is unfortunately necessary > for > quite a while for the much larger space of IOT equipment and protocols written > for non-browser enviroments where IOT equipment is important to be supported. > Such IOT equipment often comes with SDK that can not be upgraded for long > periods of > time, sometimes as long as 10 years or longer, and/or solutions where upgrade > of SDK > (including OS) would require very expensive re-certification such as FIPS 140 > or > required regulatory requirements. i.e. these systems can be upgraded with new protocols, but not with updates to TLS? That seems unfortunate. > If you think this is not appropriate, then please stop flying planes, because > planes are one example of systems in which basic systems are not possible to > rewrite > from scratch because they can not for various, including financial reasons be > re-qualified at such a base level. I have personal knowledge of aviation systems running TLS 1.0 with RC4 and DES. So yes, these are real issues. It would be very nice to be able to say "too bad it's 2025, upgrade". However, there are financial / business implications. > Short of that, the above text is suggested re-write of the core applicability > point of the UTA draft. There may be other text to update. RFC 8446 is 7 years old. If we don't mandate the use of TLS 1.3 for new protocols now, when will we be able to mandate it? I will point to the above usage of TLS 1.0 to answer that question: "never". That doesn't seem acceptable for me, either. One reason to mandate TLS 1.3 is the recognition that a lot of implementations have no qualms about ignoring the "MUST" provisions of RFCs. If we published draft-ietf-uta-require-tls13 as-is, then I would fully expect legacy products to ignore it, and to use TLS 1.0 with RC4/DES for new protocols. Perhaps a different question is "Do we want to avoid mandating TLS 1.3 for everyone *else* in the world, simply because one use-case refuses to upgrade?" My answer to that would be "no". The benefit gained everywhere else by mandating TLS 1.3 likely outweighs the minor problems of one use-case who chooses to ignore that mandate. Alan DeKok. ___ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
[Anima] Re: [Uta] [Last-Call] Re: Concern about draft-ietf-uta-require-tls13-10 with IoT protocols
On Apr 10, 2025, at 10:21 AM, Salz, Rich wrote: > The document tries to be careful about trying to move vendors to TLS 1.3, > while still recognizing that deployment issues may force the addition of TLS > 1.2. If a vendor is on TLS 1.0/1.1 this document doesn’t apply. > I am concerned that if we water this down more, just so some vendors can > claim compliance with an RFC, it will be ineffective if not useless. That for me is the main issue. As Paul noted, vendors are already ignoring other RFC MUST requirements. They are likely to ignore this one, too. We should not be catering to people who violate the standards. My concern is that there are proposals to change the standard to match one use-case. There are many, many, other use-cases which will be affected by this change. There has been little acknowledgment of that by proponents of the change. I have some questions for the people who propose making TLS 1.3 a SHOULD for new protocols: * do we want one already non-compliant use-case to set the bar for security? * do we want to avoid mandating TLS 1.3 for every other use-case? * when will we be able to mandate TLS 1.3? I would suggest that the answers here are "no, no, and now". If the answers are "yes, yes, and never", then we might as well not publish this document. I would also suggest that there are no other combinations of answers. i.e. there is no intermediate position where we don't mandate TLS 1.3 now, but perhaps we will mandate it one day. I just don't see any of the current arguments against mandating TLS 1.3 changing in 10 or even 20 years. Alan DeKok. ___ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
[Anima] Re: [Last-Call] [Uta] Concern about draft-ietf-uta-require-tls13-10 with IoT protocols
(trimming things a bit) > On Apr 10, 2025, at 2:41 PM, Jared Mauch wrote: > > On Tue, Apr 08, 2025 at 11:23:44AM -0700, Eric Rescorla wrote: >> As Alan observes, we are talking about levies on new protocols, not >> existing protocols. These should be deployed with TLS 1.3 for the reasons >> indicated in this draft. > > I'm sorry, that just isn't the case no matter how much you wish > it would be. Please then answer the following questions: * do we want one already non-compliant use-case to set the bar for security? * do we want to avoid mandating TLS 1.3 for every other use-case? * when will we be able to mandate TLS 1.3? The argument for mandating TLS 1.3 explicitly acknowledges the "I don't want TLS 1.3" use-case. It also gives reasons why the mandate is believed to be acceptable for that use-case. The argument against mandating TLS 1.3 is essentially "I can't use TLS 1.3 for my use-case". What is missing from that argument is the acknowledgment that this request also changes other use-cases. I would like to see a stronger argument as to why not mandating TLS 1.3 everywhere _else_ is fine. And if that's true, what is the plan for mandating TLS 1.3, and when we will put that plan into effect. If those other issues can't be addressed, then by the same token, there's no need to address the "don't mandate TLS 1.3" argument. Alan DeKok. ___ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
