----- Original Message ----- From: "Randall Gellens" <randy@xxxxxxxxxxxxxxxx> To: <l.wood@xxxxxxxxxxxx>; <stephen.farrell@xxxxxxxxx>; <ietf@xxxxxxxx> Sent: Friday, April 04, 2014 12:24 AM Subject: RE: Security for various IETF services > My reaction is also to ask "Why?" Security and privacy involve > trade-offs where various costs (including operational difficulty) are > weighed against the benefits, such as protecting information from > unauthorized disclosure or modification. So, I'd suggest that a > blanket statement isn't a good idea, but rather, a service-by-service > decision should be made. For example, XMPP and document submission > may justify requiring encryption while email and document retrieval > might not. Yes, it is a trade off, a more secure service, for some meaning of security, but a worse service for some users or usages. Setting up a TLS session takes time; I notice every time I access e-mail, ever since my ISP required the use of TLS. It is only a few seconds, but it means that I batch my usage rather than doing it promptly, and every so often forget and shut down without having sent a message in reply. And certainly with that e-mail access, it is forever tearing down the TLS session and creating a new one, e.g. between sending e-mail on an account and receiving it from the same account, so one (unmet) requirement is that having gone to the cost of setting up a session, it stays up and is reused. And then there is CRL checking. I would assume that that would be recommended as part of a secure system, yet with the IETF website, that hangs the session. The CRL is downloaded and ...... hours later, the web page has yet to display. There is something weird about the IETF's use of certificates which other websites do not share. Surmountable no doubt but it means that a secure service is a worse service than that obtainable via HTTP. And what threat is this trying to counter? a corrupted DNS directing me to a phishing website of a foreign power? Tom Petch > -- > Randall Gellens