>> I think that if the WG punts on security, the security area directorate
will punt the document back to the WG. And say "fix it".
>>
>> This isn't about invalidating current implementations. It's about
telling people that *new* implementations, or new *releases*, have to be as
secure as possible.
>>
>> If the WG punts on security then we might as well add a note to the
document saying "using this protocol will ensure that hackers will pwn your
equipment". Because it will be absolutely true.
>>
>> And then *no one* will want to implement it.
>
> I hear and understand what you're saying. And if this were a net new
> protocol, I'd agree with you 100%. But the mandate for this document is
> to describe how T+ is implemented today[1]. Today, people are deploying
> it with all sorts of security issues because that's how the protocol
works.
I think Alan got it right. You are describing an existing protocol. Fine. It still is your responsibility to state what are the security properties it provides *according to the current understanding of what the security posture should be* (because you are documenting *now* what had been done back then), regardless of whether the original designers and/or implementers gave a hoot about them or not. And if the answer is "it has no security worth mentioning", tough luck - you still MUST state that. Since it is an existing protocol rather than a new design, IESG would probably let it slide.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
