Re: [TLS] Security today

[Mike <mike-list@xxxxxxxxx>]

> (In a struggle to bring the thread back to tls-relevance...)

In my opinion, this is very relevant to TLS.  TLS is being
mis-used so badly, that security is unnecessarily horrible.
TLS itself is not bad, but if (when) something bad happens,
it will be blamed for being insecure.  You don't want that
to happen.

I think that it's become necessary for the TLS WG to put
together a document with hard numbers in it for key lengths,
relative strengths, expected lifetime for data protected by
those keys/lengths/algorithms.  Of course the IETF doesn't
want to take on the liability associated with recommending
any particular algorithms/key lengths, but they can easily
recommend against those that are believed to be weak.  There
is plenty of public information that can be referenced (from
multiple sources) to avoid taking on liability.

With this document out there, those who are afraid to do
anything better than what everybody else is doing (opening
themselves up to being fired if something goes wrong), will
be able to take some initiative to improve the situation.
And with this information out there, they won't be able to
simply say that they were just following the herd.

I don't consider myself expert enough to take on this task,
but I know that others on this list are expert enough.

> in theory you're supposed to look at the cert and it's cps
> (which is referenced in a field in the cert in the payload
> in the TLS protocol...) and the ciphersuite selection and
> refuse to connect.

In theory, yes.  But who ever looks at a CPS?  I don't even
know how to get Firefox to show it to me, and no ordinary
user even knows that CPS's exist.

> In other words, the protocol supports you deciding to
> not interact with the server.

If there was a local Amazon.com bookstore in my neighborhood,
you can bet I would follow this advice.

Mike
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls