> On 9 Jul 2018, at 22:11, Alan DeKok <[email protected]> wrote:
>
> On Jul 9, 2018, at 4:54 PM, Joe Clarke <[email protected]> wrote:
>> Below are some of my comments. They mainly revolve around the strength
>> of the normative language with respect to the fact that this draft is
>> supported to document the protocol as it is today. To me, the security
>> considerations should reflect best common practices without
>> over-enforcing things that would invalidate current implementations.
>
> I think that the security considerations section *should* invalidate
> insecure implementations.
I think that on a protocol level there isn't even a single implementation that
would make protocol even remotely secure as such and one cannot be made without
significantly altering the protocol. In my eyes, the problem is akin to asking
what can be done to make HTTP secure and the answer was unanimously to use
secure transport (i.e. SSL at first and now TLS), though, supposedly, DIGEST
HTTP authentication method would solve the problem of leaking passwords while
leaving CC numbers in the open.
Is it worth asking everyone or even expecting anyone to migrate to
new-improved-and-still-insecure revision of T+ that requires exactly same
amount of operational solutions to secure deployment?
Andrej.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
