[Emu] Call for Agenda Items for IETF 110
The EMU meeting at IETF 110 will be on Monday, March 8, 2021, from 13:00-15:00 CET. Please send the chairs (emu-cha...@ietf.org) requests for presentation slots. Don't forget to include the title of your presentation, related drafts, and the approximate amount of time needed. Joe and Mohi ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
Here are my answers as a client implementor. You'll see our implementation has had more time to bake with the application data, but I don't think either is technically problematic. I do favor the application data because I believe it is better suited for the semantic purpose as a protected result indicator for EAP-TLS. When close_notify was floated in the group and put in draft-14, the group was very specifically discussing the semantic of "no more messages will be sent" - for which close_notify carries that intent very clearly. The group has now realized that a protected result indicator is needed instead, and this is very different from "no more messages will be sent." It's my opinion that close_notify is less suited for this new purpose. >1. Have you implemented the zero byte application record signa? If not, why >not?l Yes. >a. Is it sent after receiving the client finished? Observably in server implementations we are testing against, yes. >b. Do you anticipate problems if the application record comes before or after >a NewSessionTicket message? No. >c. did you run into any issues with this mechanism? No. >2. Have you implemented the close notify method? If not, why not? Yes, but testing isn't finished. >a. Is it sent after receiving the client finished? We're ironing out a few implementation issues. >b. Were you able to cause the message to be sent for the server or determine >that the message was received for the peer/supplicant? We're ironing out a few implementation issues. >c. Did you run into any issues with this mechanism? Yes, as above - but theoretically I don't see a technical issue once the kinks are ironed out. We believe the signal should be accessible to our client implementation. Jorge Vergara ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
> On 9 Feb 2021, at 09:53, John Mattsson > wrote: > > Michael Richardson wrote: >> is this really 3.5 round trips -> 4.5 round trips, or is it really more like >> that we are >going from perhaps 5.5 round trips to 6.5 round trips (for >> example). > > Another question is if EAP-Success should even be counted. A protected > success indication would make EAP-Success a dummy message. It has to be sent > according to EAP, but would not really be used…. Except to the authenticator, right? Eliot signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
On Feb 19, 2021, at 11:14 AM, Joseph Salowey wrote: > > On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok wrote: > On Feb 19, 2021, at 12:26 AM, Joseph Salowey wrote: > > I'd like to hear from implementers about their experience with this > > mechanism: > > > > Was this both Peer and server implementation? I've implemented the server side. Microsoft implemented the peer side. IIRC, the behaviours are largely similar. Both peer and server side have been implemented for hostap / wpa_supplicant. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key Derivation for EAP-TLS 1.3
On Feb 19, 2021, at 10:49 AM, John Mattsson wrote: > 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. You aren't responsible for IETF procedures. But IETF procedures involve people discussing topics. This discussion is with the goal of reaching consensus. You are responsible for pushing back against suggestions. Which is fine if the reasons help move the document forward. I'm not suggesting things because I'm being troublesome. I'm suggesting things because they're *useful*. I'm explaining *why* they're useful. But there's push-back because... you don't see why the suggestions are useful? That's concerning. > [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. No one suggested that implementations don't follow RFC 5216. And as I said, the code is publicly available. This isn't the first time I've addressed protocol issues by pointing people at code. The point I was making is that implementations do MORE than what RFC 5216 suggests. I think it is entirely reasonable to update the document to explain this. If the implementations find it useful to do something, then there must be reasons for it. We should either explain WHY it's necessary to do these things, OR explain why these implementations are wrong. > [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. Like pushing back on suggestions which I believe are important, for reasons *other* than "that is technically wrong". > [John] Except the first sentence, I agree with you. You have pushed back against feedback from implementors. You've pushed back against giving guidance to implementors. Which makes the document largely an academic exercise. > 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. EAP is an application which uses TLS. As such, it is entirely relevant to add text explaining how to use TLS (e.g. the number of session tickets, and what to do with them). This text would help guide implementors as to what to do. The only push-back on that text was you. So it's a little disingenuous to claim "there's no IETF consensus". > [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. This is *entirely* the wrong approach to take. The purpose of the IETF process is not to ram documents through come hell or high water. If a late review discovers major issues with the document, then the document can be fixed. This has happened before, and is part of the IETF process. I'll also note your earlier comment, which raised another major red flag: Basically the comment was that if we weren't sure what to say, we should just publish the document and figure it out later. This comes across STRONGLY that process is more important than content. I disagree completely. People will implement and deploy a specification. They don't care what process was used. They only see the end result. As such, it is critical to get the content correct. >> 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. So... should we, or shouldn't we update this document with implementation guidance? > [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 resi
Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok wrote: > On Feb 19, 2021, at 12:26 AM, Joseph Salowey wrote: > > I'd like to hear from implementers about their experience with this > mechanism: > > Was this both Peer and server implementation? > > > 1. Have you implemented the zero byte application record signa? If not, > why not?l > > Yes. > > > a. Is it sent after receiving the client finished? > > Originally no, but now yes. > > > b. Do you anticipate problems if the application record comes before or > after a NewSessionTicket message? > > No. > > > c. did you run into any issues with this mechanism? > > No. > > > 2. Have you implemented the close notify method? If not, why not? > > Yes. Right now, it's a secret configurable flag to switch between these > options. > > > a. Is it sent after receiving the client finished? > > Yes. > > > b. Were you able to cause the message to be sent for the server or > determine that the message was received for the peer/supplicant? > > Yes. > > > c. Did you run into any issues with this mechanism? > > No. > > Alan DeKok. > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key Derivation for EAP-TLS 1.3
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 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 Date: Friday, 19 February 2021 at 12:31 To: John Mattsson Cc: EMU WG Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3 On Feb 19, 2021, at 2:12 AM, John M
Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
On Feb 19, 2021, at 12:26 AM, Joseph Salowey wrote: > I'd like to hear from implementers about their experience with this mechanism: > > 1. Have you implemented the zero byte application record signa? If not, why > not?l Yes. > a. Is it sent after receiving the client finished? Originally no, but now yes. > b. Do you anticipate problems if the application record comes before or after > a NewSessionTicket message? No. > c. did you run into any issues with this mechanism? No. > 2. Have you implemented the close notify method? If not, why not? Yes. Right now, it's a secret configurable flag to switch between these options. > a. Is it sent after receiving the client finished? Yes. > b. Were you able to cause the message to be sent for the server or determine > that the message was received for the peer/supplicant? Yes. > c. Did you run into any issues with this mechanism? No. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Key Derivation for EAP-TLS 1.3
On Feb 19, 2021, at 2:12 AM, John Mattsson 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
