On 06/04/2014 16:52, Stephen Farrell wrote:
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.
That is an assumption that is the thin end of a wedge.
A threat analysis is needed on a case by case basis.
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."
It would be better to say: "The specification of new service
will each be required to include a threat analysis.
In each case a decision will be made about which,
if any, security protocols are needed to match the needs
of the application in the light of the threats."
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.
... and we loose if we needlessly burn power, silicon, time,
bandwidth.... What I hope we are doing is best in class
engineering, and not simply reacting to the news of the
past few months.
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.
This is a very sweeping statement, which is surely application
specific?
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 question here concerns the degree to which the en clare
applications need to justify their case against an assumption
of encryption. Each application surely needs to be considered
on it's own merits. The text that you have is presumptive
of the outcome, which is surely not best engineering practice.
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.
I am not sure that last para is called for.
- Stewart