> There is a value in not making cleartext versions of services > available though - I've personally seen a number of cases where > http:// URLs were sent via mail with instructions to login at > that URL using e.g. a datatracker or tools login. Yes, that ought > not happen (https:// URLs should be sent), but it does happen > and will so long as the http:// URLs work, and it'd be naive of > us to assume that everyone sending out such mails would be aware > that doing so isn't a good plan. Your problem is with the servers, not the users. that can be addressed by server-side redirection from http:// to https:// whever a login is required. Either a 301 permanent redirect, or a 401 unauthorised. A number of other services already do this. Indeed, as an example http://datatracker.ietf.org/accounts/login/?next=/ autoredirects to https://datatracker.ietf.org/accounts/login/?next=/ lynx will report 'access without authorisation denied, retrying' ie 401 So the http urls still 'work' but the considered-necessary level of security is imposed without requiring the users to know the difference in the URL. Transparent 'upgrade', if you like. What is sent in mail - http or https - does not matter. Whether you can trust DNS (whatever happened to the trailing dot, anyone? You'd think that would be widespread) is another matter... I'm not convinced that https is required to all material throughout once past login. Certainly not to public drafts or published rfcs/minutes. > A couple of people expressed concern that this was a bit of a > "blanket statement," well, yes. That's perpass in a nutshell. "OMG never again, this was fine after 9/11 for foreigners, but not to Americans!" etc. > Lastly, I'm heartbroken that Lloyd has sussed out my formerly > secret plan to try to take over the world;-) In retrospect, your plans have always failed on their own merits. In retrospect. But why take chances? Lloyd Wood http://about.me/lloydwood Lack of past performance is no guarantee of future failure. ________________________________________ From: ietf [ietf-bounces@xxxxxxxx] On Behalf Of Stephen Farrell [stephen.farrell@xxxxxxxxx] Sent: 06 April 2014 16:52 To: IETF-Discussion Subject: Re: Security for various IETF services As others have said, I think the questions posed have been answered pretty much. I also got some good offlist wording suggestions, the result of which is: "The IETF is committed to providing secure and private access to information via the web, mail, jabber and other services. While most data on IETF services is public, individual accesses to that data should be kept private to the extent possible. However, as there are numerous existing tools that have been built that require access via cleartext, the IETF will continue to allow such access so as not to break such tooling. New services will however generally only be made available in ways that use security protocols such as TLS." And just adding some stuff that's not been said before... I agree that IETF services aren't the most sensitive in the world, but think we all nonetheless win if we up the ante for attackers of whatever kind when we reasonably can. There is a value in not making cleartext versions of services available though - I've personally seen a number of cases where http:// URLs were sent via mail with instructions to login at that URL using e.g. a datatracker or tools login. Yes, that ought not happen (https:// URLs should be sent), but it does happen and will so long as the http:// URLs work, and it'd be naive of us to assume that everyone sending out such mails would be aware that doing so isn't a good plan. Using e.g. TLS for confidentiality also helps counter attacks where cleartext HTTP cookies etc. are being used for monitoring which has been shown to be the case. [1] IMO that's already a good enough reason to turn on TLS or equivalent as much as possible since most services will expose some similar fingerprint when run in clear. For those who expressed a wish for data origin authentication over and above TLS server auth, that is already in place for I-Ds. [2] A couple of people expressed concern that this was a bit of a "blanket statement," while that is true, the statement is not absolutist, e.g. it says "generally" in the last sentence which I think is about right. A number of people made mechanism-specific points which were mostly reasonable but of course we shouldn't put those in this proposed iesg statement. One person said that e.g. this statement should not be used to require client authentication which is of course correct. Someone mentioned having an IETF privacy policy for services which sounds like a fine thing to me, and which is something that I think Alissa has done a bit of work on in the past and the IESG has chatted about resurrecting that. That is trickier to get right though, and more work to get agreed, so not sure if it'll happen. Lastly, I'm heartbroken that Lloyd has sussed out my formerly secret plan to try to take over the world;-) Ah well, I'll just have to try again tomorrow. S. [1] http://www.bbc.co.uk/news/technology-25333663 [2] https://www.ietf.org/id-info/idsignatures.html On 04/03/2014 05:21 PM, Stephen Farrell wrote: > > Hi all, > >>From time to time the issue of how to secure IETF services > comes up e.g. whether to turn on TLS for some IETF web server > or jabber or mail etc. > > The most recent such was a request to turn on HSTS [1] for > the IETF web site, which I don't think we can do without > breaking old tools etc. Nonetheless we would like to turn > on things like TLS more often going forward as seemed to > me to be the outcome of a long thread on here late last > year. > > So, the IESG are considering the following as an IESG > statement to offer some guidance about this: > > "The IETF are committed to providing secure and privacy > friendly access to information via the web, mail, jabber > and other services. While most (but not all) data on IETF > services is public, nonetheless access to that data > should use best practices for security and privacy. > However, as there are numerous legacy tools that have been > built that require access via cleartext, the IETF will > continue to allow such access so as not to break such > tooling. New services will however generally only be made > available in ways that use security protocols such as > TLS." > > If you have wordsmithing changes to suggest please just send > those to me or the iesg. More substantive comments should go > here I guess. I hope the only bit worth discussing (except > for the few folks who would rather we do none of this;-) > might be the last sentence. > > A few weeks after any discussion here dies down I'll put the > resulting text on an IESG telechat for approval if that seems > like the right thing to do. > > Thanks, > S > > [1] https://tools.ietf.org/html/rfc6797 > > > >