Dear Alan, It would very nice if you stopped putting words in my mouth and stopped accusing me personally for IETF procedures, which I feel you do.
Alan DeKok <al...@deployingradius.com> wrote: >> But these are more implementation guidance/history then security >> >requirements. > > Do these issues affect security? If the answer is "no", then they can >be > ignored. If the answer is "yes", then they should be put in. [John] I have not stated that I don't think your text should be put in the document. I do. And your suggested text certainly affect security. I simply meant that this was not the kind of requirements I personally was discussing and expecting. In fact, your text make me questioning if implementations are even following the RFC 5216 MUST or if we need to update some text. [John] If EMU cannot agree on a a few high level sentences summarizing MUST requirements for secure server authentication, I have a hard time believing that current or future implementations are/will be secure. [John] My role as one of the authors is not to decide what goes into the document or to produce all the text. After adoption, my role is to add text that there is WG consensus on. Sometimes that includes trying to come up with text based on the consensus. > You've approached this specification as a theoretical exercise in >protocol > design. I've tried to explain that protocols are implemented in >the real > world, by real people. As such, it is important for the document >to give > implementation guidance. Further, it's very useful for >implementors to > understand *why* things are done a particular way. >Explaining the reasons > for a particular choice helps implementors >understand the higher level > picture, which makes implementation easier. [John] Except the first sentence, I agree with you. If you suggest guidance text and that text has WG consensus, me and Mohit will add it to the document (Given that the shepard and AD are ok with it). Most of your suggested resumption guidance text is e.g. in the document. Some of the *why* text you have requested has been about TLS 1.3, I think you need to ask people that took part in these specific discussions in the TLS WG for this. Futhermore, there was people recently suggesting that all TLS guidance was to be removed. Then it is hard to arguee that there is IETF consensus to add more. [John] Note also that at this late state of the document process it is harder to harder to justify new technical changes that are not related ot the IESG review. > There are any number of RFCs which take this approach. Experience shows > >that specifications which do *not* have implementation guidance. too often > >result in insecure implementations. [John] I know. There are also WGs that spearate the protocol specification and implementation guidance in different RFCs. I think we should have more of that, expecially for protocols where there is experiance on how implement. > There have been a number issues brought up by people who have *coded* >these > protocols, and *used* them in the real world. You're opposing the >requests > to update the document with guidance that the implementors say >they need. > The reasons you give are largely from inexperience: "I don't >understand why > this matters". > > Well, it does. If you don't understand why, then please step aside, and > >let the work be done by others. If you won't step aside, then please >stop > resisting guidance from people who have experience in this area. > > To be perfectly frank: if this specification does not meet the needs of > >implementors, then they will ignore it, and go do whatever they want. >This > particular specification will be ignored. And once implementors are >ready, > they will bring a specification to the IETF which says "ignore the >previous > spec, this is what we actually did". > >Implementors have a long established a set of practices which are NOT >written >down in any standard. These practices help to both secure the >network, and >make these systems easier to deploy. [John] I don’t know what you think I have opposed. So far I can recall two significant chucks of established practice text that you have suggested. Text regarding resumption, which is now in the document, and recent practice text regarding authentication that I have NOT resisted. [John] Note that guidance text is not always easy for the WG to reach consensus about. Your resumption guidance text for example got quite a lot of comments both before and after it was put in the document. >i.e.: Instead of fighting with standards bodies, implementors have gone >and >done their own thing, because the specifications are lacking. Worse, >the >processes used by standards bodies are lacking. -----Original Message----- From: Alan DeKok <al...@deployingradius.com> Date: Friday, 19 February 2021 at 12:31 To: John Mattsson <john.matts...@ericsson.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3 On Feb 19, 2021, at 2:12 AM, John Mattsson <john.matts...@ericsson.com> wrote: > But these are more implementation guidance/history then security requirements. Do these issues affect security? If the answer is "no", then they can be ignored. If the answer is "yes", then they should be put in. You've approached this specification as a theoretical exercise in protocol design. I've tried to explain that protocols are implemented in the real world, by real people. As such, it is important for the document to give implementation guidance. Further, it's very useful for implementors to understand *why* things are done a particular way. Explaining the reasons for a particular choice helps implementors understand the higher level picture, which makes implementation easier. There are any number of RFCs which take this approach. Experience shows that specifications which do *not* have implementation guidance. too often result in insecure implementations. There have been a number issues brought up by people who have *coded* these protocols, and *used* them in the real world. You're opposing the requests to update the document with guidance that the implementors say they need. The reasons you give are largely from inexperience: "I don't understand why this matters". Well, it does. If you don't understand why, then please step aside, and let the work be done by others. If you won't step aside, then please stop resisting guidance from people who have experience in this area. To be perfectly frank: if this specification does not meet the needs of implementors, then they will ignore it, and go do whatever they want. This particular specification will be ignored. And once implementors are ready, they will bring a specification to the IETF which says "ignore the previous spec, this is what we actually did". > Might also be that the text in quoted text in RFC 5216 is not how things are > implemented. There is code publicly available. I suggest looking at it. > An alternative approach would be to check that the certificates are issues by > a CA that is exclusively used for EAP-TLS in a specific network and ignore > the identities. This topic has been discussed before in EMU, including explanations of what people have been doing for a decade in production networks Implementors have a long established a set of practices which are NOT written down in any standard. These practices help to both secure the network, and make these systems easier to deploy. i.e.: Instead of fighting with standards bodies, implementors have gone and done their own thing, because the specifications are lacking. Worse, the processes used by standards bodies are lacking. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
