On Feb 19, 2021, at 10:49 AM, John Mattsson <[email protected]> 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 resisted. I had comments on session tickets. You opposed that, because "RFC 8446 doesn't provide guidance" on this issue. The TLS RFCs have historically been silent on choosing encryption methods, digests, etc. Yet there are any number of RFCs which describe an application using TLS, and which give guidance as to which encryption methods are mandatory to support. I can think of 3 just for RADIUS. > [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. Do you think that's news to me? Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
