On Feb 7, 2021, at 6:11 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > Alan DeKok wrote: > >> The document should explain this in detail, and suggest which message flows >> are preferred, and which >ones MUST be supported. It should explain what >> happens when resumption is negotiated, and 20 >> tickets are received by the peer. What does that mean? What does the peer >> do with them? Why does >the server send them? Which (if any) ticket is >> preferred? > >> It is not helpful if a specification says "anything can happen". The >> purpose of the specification is >to provide a guide for implementors and >> deployments. This includes not just saying what *can* >happen. But what >> *should* happen. Why one thing is preferred over another. Why certain >> protocol >choices were made. So that readers of the document are informed >> as to what to do, and why they need >to do it. > > This seem very much like TLS 1.3 details.
Does EAP-TLS interact with TLS? (a) yes, in which case this spec should explain how TLS implementation choices affect EAP implementations. Or (b) no, in which case it doesn't matter. As an implementor, some questions are absolutely critical. e.g. "what do I do when I get 20 session tickets?". These questions MUST be answered in the draft. The alternative is an under-specified standard, and implementors doing random things, because the draft is silent. I'm quite frankly surprised that this suggestion would be controversial. > I am not sure that EAP-TLS should answer these question, or that the EMU WG > even has the competence. What you want is basically a description of the > design choices in TLS 1.3 and guidance that TLS 1.3 itself decided to not > give. No. EAP-TLS is describing a specific application TLS. As such, it MUST document how it works, how it's implemented, and ideally also deployment considerations. If this isn't clear to to you, I have to ask why you're authoring the document. These issues are completely fundamental to protocol implementations. > Have you a conrete example of something this is more important to give > guidance about in EAP-TLS 1.3 than in TLS 1.3 in genereal? See above. > Several reviewers the last month suggested the opposite, to completely remove > all TLS 1.3 details and only describe the interactions between TLS 1.3 and > EAP-TLS 1.3..... Does that mean the EAP-TLS spec *won't* discuss how EAP-TLS works? Because that's what you're saying. You're approaching this as a theoretical exercise in getting an RFC number. I'm approaching it as an implementor who wants to write code that works, is interoperable, and gets users authenticated. Having the document be silent on critical issues will be an unmitigated disaster. Experience with implementing and deploying other protocols shows that where the docs are silent, people make random implementation choices. These choices lead to confusion, problems with inter-operability, and security vulnerabilities. > All sentences talking about the message flow figures have been rewritten in a > similar way, i.e., "shows an example message flow". TLS 1.3 allows quite a > lot of flexibility already now with NewSessionTicket, HelloRetryRequest, > KeyUpdate, option errors, optional to accept resumption, etc. Future > extensions might allow or restrict the flexibility. So we're documenting a protocol which can do anything. Wonderful. What should an implementor do? Anything. What should an implementor accept? Anything. Why write documents at all, then? As a neutral example of *why* narrow specs are useful, I refer you to ISO 8601, where times can be represented in nearly any format. To fix this (and make it USEFUL), we have RFC 3339, which specifies ONE format which is easy to implement, and easy to understand. > I am hesitant to add any recommendations for TLS 1.3 not specifically related > to EAP-TLS. These are also things RFC 8446 leaves completely to the > implementation. Then I suggest following the guidance of implementors who say that these issues are critical for protocol adoption, implementation, inter-operability, and security. >> Perhaps simply recommend that if possible, only one session ticket be sent >> by the EAP server. And >that if the EAP peer receives multiple session >> tickets, it should only save one, and discard the >rest. Which one doesn't >> matter. If the EAP server sends multiple session tickets, it's the >> >responsibility of the EAP server to ensure that all are valid. > > These are all things that should be handled by the TLS layer. Not sure > EAP-TLS should or need to say anything about this. I disagree so strongly that I have to ask why you're authoring this document. The TLS layer often does not cache session tickets. Some applications (e.g. FreeRADIUS) can cache session tickets in a database, in order to address real-world issues like server failure. i.e. in high load environments, TLS session tickets can be cached in a clustered database, so that any RADIUS server can resume an EAP-TLS session which was initially authenticated elsewhere. Giving guidance to implementors is *critical*. The contents of the document have real-world implications for cost, ease of deployment, etc. Simply saying "anything can happen" is just not an option. > Resticting things would make EAP-TLS incompatible with a lot of TLS > implementation unless the default behaivior can be changed. Both of the > following > > - I suggest limiting this to one. > - I suggest also saying that session tickets SHOULD NOT be sent >BEFORE the > client cert is validated. > > would not be aligned with OpenSSL default behavior as you described it. And the problem with that is.... what, exactly? When a specification says SHOULD, it means SHOULD. Implementations can (and will) ignore that, and behave differently. You're essentially saying here that you don't want a SHOULD in the document, because one implementation will ignore it. That is very far from a convincing argument. > I would be fine with updating the examples to that the ticket is always send > with the same flight as server finished. But this contradics what you said > before "session tickets SHOULD NOT be sent >BEFORE the client cert is > validated"... Change that to "the session ticket should be sent with the altSuccess indicator" Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
