On 7/10/18 11:42, Andrej Ota wrote: >>> Since this makes secured transport a minimal necessary requirement >>> for any secure deployment, what benefit is there to try and find >>> further examples of what can be mandated if none of the mandates >>> would meaningfully change the end result? >> >> It's useful to explain *what* behaviours are insecure, and *why* >> they are insecure. > > 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.
I wholeheartedly agree we should point these out and offer suggestions to operators (and vendors) on how to best mitigate them. > > Though I'd flip this and put emphasis on what behaviours are secure and > declare others explicitly unsecure. That works for me. > >> >> 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. Agreed, and I was not suggesting this. > > 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. > Handling secrets, passwords seem like good targets for this. With the particular point of handling secrets and passwords, linking to specific suggestions of this would be a plus, too. > - 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? This sounds like the right approach to me. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
