Re: Security for various IETF services

[John C Klensin <[e-mail]>]

--On Thursday, April 03, 2014 19:00 -0700 Randall Gellens
<[e-mail]> wrote:

> At 7:56 PM -0400 4/3/14, Pranesh Prakash wrote:
> 
>>>  However, as there are numerous legacy tools that have been
>>>  built that require access via cleartext
>> 
>>  Could you please expand on this?  What kinds of legacy tools
>>  is  that statement talking about?
> 
> I have a number of tools and scripts that access IETF and RFC
> Editor documents and information using HTTP and FTP.

I do too and more with FTP than HTTP.  This is not just being
old and set in my ways (age being both the tools and about me).
Many of the tools that use HTTP can't make up their minds (or
need special handling) to deliver an XML file to me rather that
deciding they "really" know what I intend and trying to
render/interpret it, while FTP always does what it is told and
retrieves the d**m file.  My preferred reading tools for I-Ds
and RFCs and my preferred editing tools for I-Ds involve an
emacs clone text editor.  It provides a very satisfactory
solution, a range of paging and text tools, a satisfactory XML
editing experience, and a largely platform-independent
consistent interface.  Given that, I'm loathe to seek out and
learn something new and shiny and, having looked around, I'm not
convinced that doing so would bring any real benefit.

More important from the security front, although, in this case,
it more a matter of principle than a serious concern, it is none
of the IETF's, or anyone else's, business what files I retrieve
and when.  I don't want to be authenticated unless there is a
demonstrated and persuasive need that gets community consensus;
I don't want logs kept at all; and, by the way, I don't want web
beacons in my mail from IETF lists because some future genius
decides that better service could be provided by analyzing what
is read and when.  

In addition, if I want to set up caches for documents (or even
shadows of directories) or trick routing, whether to protect my
privacy, improve performance, or because I'm perverse. I don't
think the IETF should be "helping" me and someone else's
perception of what security issues I think (or should think) are
important by getting in the way (with SSL/TLS or anything else).

IMO, the IESG needs to carefully consider whether better privacy
and security, especially for access to public documents, lies in
more anonymity and openness rather than in more restrictive and
powerful tools whose side-effects may be to compromise that
anonymity.  The answer will inevitably be different for
different cases, but these knee-jerk "need more security"
reactions are just bad systems engineering.

Finally, like (I assume) many others here, I don't have a lot of
spare time on my hands [1].  Time that goes into following one
of these procedural threads, questions from the IAOC, etc., is
time that doesn't get spent on substantive work for the IETF.
So I really wish that the IESG and IAOC would keep their
responsibility for facilitating getting technical/ standards
work around here in the front of their minds and ask themselves
(and maybe each other) hard questions about relative importance
of each of their trial balloons and inquiries.

    john

p.s. I also agree with most of Dave Crocker's recent analyses
and comments.  That is becoming a scary trend :-)


Any time someone needs to think about or discuss data retention
policies, security of logs, or the like, I think we first need
to have a discussion of why we need to collect the data in the
first place.

[1] Sorry, I type rapidly enough that it doesn't predict to
messages that are so short and pointed as to seem cryptic.  But
I am sending a lot fewer of them.