> On 9 Jul 2018, at 22:02, Alan DeKok <[email protected]> wrote: > > On Jul 9, 2018, at 4:54 PM, Joe Clarke <[email protected]> wrote: >> Broadly, given that we want an informational draft that describes the >> protocol as it is implemented today, I feel there should be a balance >> struck with respect to normative language so that we don't make existing >> clients "out of spec." > > It's an informational draft, so from a bureaucratic point of view, it > doesn't really define a standard. > > That being said, the spec should require that implementations be as secure > as possible given the protocol limits. If this means forbidding things that > are widely used... well... that's progress.
I think that forbidding some parts with MUST would go against the original mandate for this draft which I understood to be documenting what's used and specifically not working to do a revision of protocol (which I would love to hide behind TLS). Would using SHOULD work or do you think that would make the language too weak ... induce lack of any kind of progress. > If the spec is as strong as possible, then implementors will still be free > to ignore it. Just as they ignore the specs for most other protocols. :( > But users of those implementations can ask pointed questions of "Why are you > shipping me something that is insecure by design?" The problem with the protocol as it's implemented today is that it's "unsafe at any speed". There is nothing that either servers or clients can do to change that on a protocol level. The only sensible normative text would be MUST NOT implement. This in my mind shifts the focus from implementation constraints to operational requirements. If we there isn't even one sensible implementation band aid (and I certainly don't see one), we can only apply deployment band aids. Net sum of both is that the document veered away from normative and into realm of "here are the facts about insecurity of the protocol, use your best judgement when deploying". We can certainly turn the draft back into more normative but I don't think that we can do anything to the protocol itself that would salvage it in any useful form whatsoever. Andrej Ota. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
