On Jul 10, 2018, at 11:42 AM, Andrej Ota <[email protected]> wrote: > Agreed. We (authors) were trying to put in more of the background as to what > are the threats for this reason - empowering those who need to deploy the > protocol to make the correct call. > > Though I'd flip this and put emphasis on what behaviours are secure and > declare others explicitly insecure.
Sure. It would be useful to explain why they're insecure. But that's largely a nit, not a serious disagreement. >> The alternative is to leave the reader to fend for himself. "Hmm... the >> authors didn't say this was bad, so let's do it!" > > No, that would be really bad outcome and I agree we must avoid it. > > Let us (authors) take this recent feedback on board and reword things along > the lines: > - Use MUST where we want programmers to do the right thing, but be careful > not to distort the actual protocol as currently implemented. I agree that we shouldn't *change* the protocol. But *deprecating* portions is entirely appropriate. Given the insecure nature of it, I would say it's *required* that we deprecate insecure portions of the protocol. > Handling secrets, passwords seem like good targets for this. > - Keep and improve verbiage documenting known risks. > - Give either MUST verbiage where there's only one thing to do (e.g. secured > transport is a MUST). > - Give SHOULD where there's multiple things (e.g. PAP vs. CHAP is closely > related to password management on the server side). > > Would this be the right way or not really? Yes. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
