Subject: Security for various IETF services

From: Stephen Farrell <[email-masked]>
Date: Thu, 03 Apr 2014 17:21:36 +0100

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

---

From: <[email-masked]>
Date: Thu, 3 Apr 2014 22:18:06 +0100

"nonetheless access to that data
should use best practices for security and privacy."

why?

" New services will however generally only be made
available in ways that use security protocols such as
TLS."

again, why?

secured access is limited access, which is counter
to the goal of an open Internet.

thanks

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 03 April 2014 17:21
To: IETF-Discussion
Subject: Security for various IETF services

Hi all,

Thanks,
S

---

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Apr 2014 16:24:29 -0700

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
!!!!!CP MBI na ni deppart m'I  !pleH

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 3 Apr 2014 23:40:00 +0000

In view of recent issues in TurkTelecom and Indosat, it seems like the simplest reason would be to ensure that data putatively obtained from the IETF would in fact be obtained from the IETF.

From my perspective, I would support a statement to the effect that IETF technology should be obtainable using https or whatever else we are recommending as "secure.” I’d also be in favor of asking IETF contributors to obtain and use PGP keys and/or DKIM encodings to sign messages. And of asking that IETF tools not reformat email in ways that corrupt data that has been signed.

To that end, I could imagine a requirement for some kind of roadmap. “The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z, and traffic originated by the IETF sites shall use such protocols."

On Apr 3, 2014, at 4:24 PM, Randall Gellens <[email-masked]> wrote:

> 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.
> 
> -- 
> Randall Gellens

---

From: [email-masked]
Date: Thu, 03 Apr 2014 16:35:41 -0700 (PDT)

> may justify requiring encryption while email and document retrieval

Bingo. There's a perfectly reasonable case to be made for protecting any sort
of authorization/authentication exchange and not allowing alternatives.

But in the case of document distribution, our primary goal should be to insure
maximum availability and access to the information we provide, including
to those who are unable to whatever reason to use protected services.

And yes, I'm aware of the argument that access to certain standards, especially
ones themselves having to do with security, might be problematic to folks
living under some repressive regime or other. I don't buy it, mostly
because that level of paranoia is going to regard any sort of access to
IETF materials whatsoever as a red flag, especially it was conducted over
TLS/SSL.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Apr 2014 16:50:01 -0700

On 4/3/2014 4:40 PM, Fred Baker (fred) wrote:
> DKIM encodings to sign messages. And of asking that IETF tools not reformat email in ways that corrupt data that has been signed.

Yes, but...

DKIM does not authenticate message contents, and the dkim signing name 
(d=) is not require to correlate with any other identifier in the 
message.  In particular, it can be unrelated to the domain name in the 
From: field.

This independence is essential for some scenarios, such as having a 
mailing list provide its own DKIM signature, using it's own domain name, 
while preserving the author's original From address.

In other words, I like the goal you have in mind, but fear it is 
considerably more challenging to achieve than any of us would like.

d/

ps. The other reason for using https is privacy to reduce traffic 
analysis and other meta-data review.  This is quite separate from 
keeping IETF data 'confidential'.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Apr 2014 16:55:04 -0700

At 11:40 PM +0000 4/3/14, Fred Baker (fred) wrote:

>  In view of recent issues in TurkTelecom and Indosat, it seems like 
> the simplest reason would be to ensure that data putatively 
> obtained from the IETF would in fact be obtained from the IETF.

Would this be met by allowing access using protocols where server 
certificates are sent, rather than requiring it?  You can't force 
anyone to verify a server certificate or to do a good job if they 
try, so why force them to take a certificate?

-------------- Randomly selected tag: ---------------
If the employees come first, then they are happy. A motivated
employee treats the customer well. The customer is happy so they
keep coming back, which pleases the shareholders.  It's not one of
the enduring Green mysteries of all time, it is just the way it
works.       --Herb Kelleher, Southwest Airlines CEO, 1994

---

From: Pranesh Prakash <[email-masked]>
Date: Thu, 03 Apr 2014 19:56:30 -0400

Stephen Farrell <[email-masked]> [2014-04-003 17:21:36 +0100]:
> breaking old tools etc.

> built that require access via cleartext

Could you please expand on this?  What kinds of legacy tools is that 
statement talking about?

Thanks.

~ Pranesh

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 4 Apr 2014 00:01:15 +0000

On Apr 3, 2014, at 4:50 PM, Dave Crocker <[email-masked]> wrote:

> ps. The other reason for using https is privacy to reduce traffic analysis and other meta-data review.  This is quite separate from keeping IETF data 'confidential'.

I’m actually not in the least interested in IETF data “confidentiality”. It’s not confidential.

If someone can hijack 8.8.8.8 and send it to a DNS server in their favorite country, they can hijack ietf.org or 2001:1900:3001:11::2c and send it to a web server of their choice. I’d like for information from the IETF to be verifiably authentic. That includes, of course, a signature on the file and at least a signature in flight. If the way to get something equivalent to a signature is encryption in the IETF’s private key, whatever. But not a key that can be copied and reused to sign/encrypt corrupted data.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Apr 2014 17:13:49 -0700

> To that end, I could imagine a requirement for some kind of roadmap. “The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After <date>, we require them to use Secure X, Se…

Dear Fred,

XMPP provides an interesting feature called server federation.  It would be good to see the excellent work of Dukhovni and Parsons extended to include authentication of sending servers (clients) to support federation.  This is something TLS supports but is rarely used.  Such a feature could significantly improve overall security especially in the wake of RTF messages exposing users to remote code execution.  

DKIM only covers message fragments and is unrelated to the actual sender by design.  A malicious link might be found in the Subject line that can be followed with user clicks which may not have been signed or users might see prepended From header fields which don't impact DKIM signature validity.

Regards,
Douglas Otis

---

From: <[email-masked]>
Date: Fri, 4 Apr 2014 01:21:55 +0100

"It would be good to see the excellent work of Dukhovni and Parsons extended
to include authentication of sending servers (clients) to support federation. "

Why?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Douglas Otis [[email-masked]]
Sent: 04 April 2014 01:13
To: Fred Baker (fred)
Cc: Randall Gellens; [email-masked]
Subject: Re: Security for various IETF services

Dear Fred,

Regards,
Douglas Otis

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 4 Apr 2014 00:23:49 +0000

> to include authentication of sending servers (clients) to support federation. "

In order to support data authentication.

> http://about.me/lloydwood

	• Make things as simple as possible, but not simpler.
Albert Einstein

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Apr 2014 13:26:55 +1300

> IETF materials whatsoever as a red flag, especially it was conducted over

That may be, but that doesn't mean we shouldn't offer privacy of
access to those who want it. I think we need to distinguish various
quite separate issues. Off the top of my head, I can see:

* authenticity and integrity of data coming from the IETF site;
* privacy of the fact of access, if the user wants it;
* preventing access to the IETF site being used as an attack
  vector for either the site itself or the remote user
  (which indirectly includes protecting the privacy of
  personal information held at either end);

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Apr 2014 09:29:22 +0900

> to include authentication of sending servers (clients) to support federation. "

because we blew it way back when, by designing a completely insecure
and un-private internet.  as supposedly responsible and occasionally
competent engineers, we should rectify our mistakes.

the internet is not an experimental plaything.

randy

---

From: Scott Brim <[email-masked]>
Date: Thu, 3 Apr 2014 20:35:17 -0400

It looks like a statement of direction that's blanket
mandatory-to-implement is too much, since so many services need to be able
to run in an open mode. If there are any services that are only useful when
secured, we can trust the deployers to know that.

---

From: <[email-masked]>
Date: Fri, 4 Apr 2014 01:47:03 +0100

"because we blew it way back when, by designing a completely insecure
and un-private internet"

That was not a mistake. That is what made adoption possible.

DTN started with security from the get-go, and DTN has gone nowhere.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Randy Bush [[email-masked]]
Sent: 04 April 2014 01:29
To: Wood L  Dr (Electronic Eng)
Cc: IETF Disgust
Subject: Re: Security for various IETF services

randy

---

From: [email-masked]
Date: Thu, 03 Apr 2014 17:44:49 -0700 (PDT)

> access to those who want it.

I never said we shouldn't offer it. The previous discussion was largley
about requiring it.

> I think we need to distinguish various

> * authenticity and integrity of data coming from the IETF site;

Your problem here is people get IETF data from many sources besides the
IETF site. Indeed, alternative data stores may provide access alternatives
for those concerned about being seen accessing IETF data in the obvious way.

As a result I don't see how transport security offers a meaningful solution
here. We should instead be looking at various signature mechanisms.

> * privacy of the fact of access, if the user wants it;

Again, there's nothing wrong with offering secure access as an option.
Wikipedia is the obvious example of a site that does this.

>   personal information held at either end);

Certain aspects of this are easy, others are hard, and some are probably
research problems.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Apr 2014 19:02:39 -0700

> quite separate issues. Off the top of my head, I can see:

What I like most about Brian's list is that it seeks to gain some 
discipline an clarity about what might be done and why.  As Ned's 
responses shows, this requires even more clarity and -- depending on 
what answers we give -- different difficulty.

 > competent engineers, we should rectify our mistakes.

This promotes a collection of popular myths which both give a false 
history and a false (and counter-productively distracting) present.

The presumption that 'security' was ignored "way back" is simply wrong. 
  Both in the 70s and again in the 90s, security issues were given 
attention.  In the 70s, the primary answer was encryption boxes, for 
those special cases deem to need them.  In terms of the technology of 
the day, when combined with the nature of the scale and use of the 
Arpanet and eventually Internet, that was a reasonable choice.

In the 90s, we got PEM, PGP, S/MIME and the beginnings of DNSSec.

The experience of the 90s nicely highlights the problem with the second 
myth, that we merely needed to 'decide' to do 'security'.  As the 
increasing list of problematic security-related efforts over the last 25 
years demonstrate, doing 'security' for Internet scale and diversity is 
a challenge, often appearing to be beyond the state of the art.

Note how little DNSSec we still have.  Note how little PGP and S/MIME 
use we still have.  All three of those were diligent, reasonable design 
efforts.  Yet their deployment and use remains problematic.

Added to this is that the word 'security' is almost completely 
meaningless in technical terms.  For most technical discussions, it's so 
vague there's no way to know what specific problems are of concern or 
what functions are intended.

So please, let's focus on the kind of disciplined, targeted effort that 
Brian is promoting to consider needs and solutions, and move away from 
mythology.

d/

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Apr 2014 11:07:00 +0900

> That was not a mistake. That is what made adoption possible.

this is not clear.  though, certainly, crypto would have had serious
performance impact in the ealy '80s.  then again, if at 9600 baud, you
can afford a bit of processing on the ends. :)

> DTN started with security from the get-go, and DTN has gone nowhere.

i was not aware that security was a major cause of the lack of success
of the dtn.

randy

---

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Apr 2014 19:00:18 -0700

At 7:56 PM -0400 4/3/14, Pranesh Prakash wrote:

>  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.

-------------- Randomly selected tag: ---------------
f u cn rd ths, itn tyg h myxbl cd.

---

From: <[email-masked]>
Date: Fri, 4 Apr 2014 03:46:34 +0100

Randy,

Security was encouraged to be the primary focus of the
DTNRG research group, above and beyond application
scenarios, or anything else. Examining years of list
discussion will confirm that. It's what happens when
you let security people run things as they see fit,
with their natural bias towards security above all
else.

Focus on security, you can get security. You won't get
users, or anything useful for the scenario,
but you can get security.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: Randy Bush [[email-masked]]
Sent: 04 April 2014 03:07
To: Wood L  Dr (Electronic Eng)
Cc: IETF Disgust
Subject: Re: Security for various IETF services

randy

---

From: t.p. <[email-masked]>
Date: Fri, 4 Apr 2014 09:48:32 +0100

----- Original Message -----
From: "Randall Gellens" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 04, 2014 12:24 AM
Subject: RE: Security for various IETF services

> may justify requiring encryption while email and document retrieval

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Apr 2014 09:03:58 -0400

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

>>  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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Apr 2014 09:15:29 -0400

On Apr 4, 2014, at 4:48 AM, t.p. <[email-masked]> wrote:
> seconds,

Whaaat?   It takes a few SECONDS for your MUA to set up a TLS connection?   Something is broken.   This is not a TLS problem.  It's probably either a load problem on your IMAP store, or bufferbloat on your network causing unreasonable round trip times—if your RTT to the IMAP store is 1000ms, then sure, it could take a couple of seconds to set up a TLS connection.

Similarly, if there's a bug in IETF's CRL support, that should be fixed regardless of the ultimate outcome of this discussion.

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Apr 2014 09:25:30 -0400

--On Thursday, April 03, 2014 17:44 -0700
[email-masked] wrote:

>...
> Your problem here is people get IETF data from many sources
> besides the IETF site. Indeed, alternative data stores may
> provide access alternatives for those concerned about being
> seen accessing IETF data in the obvious way.
> 
> As a result I don't see how transport security offers a
> meaningful solution here. We should instead be looking at
> various signature mechanisms.

Concur.  

If we think there is a real threat and problem that needs to be
solved in this area, we should see documents signed at the time
of posting and those signatures either made part of them or made
readily, easily, and obviously accessible along with any tools
needed to apply them.  We should also be sure that careful
questions are asked the relationship between signatures (or
other integrity-assurance) methods and the current IPR policies
allowing duplicates (should we require that the signatures be
preserved or explicit pointers to the authoritative, signed,
copies be provided?) and the RFC Editor's plans about multiple
output formats (e.g., is an integrity check over the XML file
adequate if there is no guarantee the that file recipient can
generate the user-accessible version?) and that answers
evaluated by experts.  Those are mostly technical issues --the
stuff we supposedly do well-- and need not be carried out on
this list, just competently reported to it.

More generally, I think the conclusion from Brian's remarks and
those of several others is that what is really needed here is a
serious analysis of what threats actually exist and whether we
care about them.   In the absence of a clear statement and
understanding of a problem and explanation of how a particular
technique will significantly mitigate it, these "we have a
technique, should we apply it" questions are, IMO, fairly
meaningless and a very bad example of the kind of engineering
the IETF should be advocating and demonstrating.

Back to trying to get substantive work done.
 
   john

---

From: Dick Franks <[email-masked]>
Date: Fri, 4 Apr 2014 17:55:51 +0100

entia non sunt multiplicanda modulo p praeter necessitatem

---

From: Hector Santos <[email-masked]>
Date: Fri, 04 Apr 2014 13:43:17 -0400

I would add and be specific with the last sentence, for example, the 
IETF site
"new services" might need to be PCI/DSS compliant. This is especially 
the case if the IETF site is collecting credit card information for 
IETF meeting registrations or other purposes.  For logging in 
purposes, it may also need to be PCI/DSS compliant depending on the 
AUTH method. For DIGEST AUTH, it may require SSL and NONCE support. 
BASIC AUTH requires SSL, and it may not be sufficient for PCI/DSS 
unless there is other methods wrapping the BASIC AUTH process, i.e. a 
cookie method method. A form-based cookie login methods, where there 
is no standard protocol method, may require other conditions. 
Overall, there are areas at the IETF site that require updated, modern 
security-aware connection client access software to be used as 
required by industry standards such as PCI/DSS.  (I note, that this is 
probably USA, not sure how that applies in Europe, Asia, etc)

If fact, the IETF may not be running proper software that complies 
with PCI/DSS.

Maybe visiting one of the PCI/DSS resource/compliance sites can tell 
you what compliancy level the IETF site may fit.  Depending on what 
software is used, it may suffice or it may not, thus perhaps even 
adding new functional requirements to the IETF Web Site revamping project.

Hope this helps

--
HLS

-- 
HLS

---

From: Dick Franks <[email-masked]>
Date: Fri, 4 Apr 2014 19:53:59 +0100

Tinkering with the text of a 90 word statement full of PR claptrap is not
going to achieve anything.

The starting point for any sensible discussion on this topic is a threat
model, for each service,  against which the effectiveness of proposed
mitigation strategies can be assessed.

Until that is forthcoming, reasoned discussion taken place, and (rough)
consensus reached, this proposal MUST go nowhere.

Dick
________________________

On 4 April 2014 18:43, Hector Santos <[email-masked]> wrote:

> I would add and be specific with the last sentence, for example, the IETF
> site
> "new services" might need to be PCI/DSS compliant. This is especially the
> case if the IETF site is collecting credit card information for IETF
> meeting registrations or other purposes.  For logging in purposes, it may
> also need to be PCI/DSS compliant depending on the AUTH method. For DIGEST
> AUTH, it may require SSL and NONCE support. BASIC AUTH requires SSL, and it
> may not be sufficient for PCI/DSS unless there is other methods wrapping
> the BASIC AUTH process, i.e. a cookie method method. A form-based cookie
> login methods, where there is no standard protocol method, may require
> other conditions. Overall, there are areas at the IETF site that require
> updated, modern security-aware connection client access software to be used
> as required by industry standards such as PCI/DSS.  (I note, that this is
> If fact, the IETF may not be running proper software that complies with
> PCI/DSS.
>
> Maybe visiting one of the PCI/DSS resource/compliance sites can tell you
> what compliancy level the IETF site may fit.  Depending on what software is
> used, it may suffice or it may not, thus perhaps even adding new functional
> requirements to the IETF Web Site revamping project.
>
> Hope this helps
>
> --
> HLS
>
>

---

From: Hector Santos <[email-masked]>
Date: Fri, 04 Apr 2014 15:48:11 -0400

Hi Dick,

Everyone else has already touch based with the same issues. I'm 
pointing out there are legal, business related regulations to be 
followed making it well understood, it (modern security methods) may 
be mandatory in certain "new service" areas.   If not, then never 
mind. If so, Stephen asked about the last sentence:

   New services will however generally only be made
   available in ways that use security protocols such as
   TLS.

If it is not already implied, I thought it may help with some specific 
admonition as to why it will only be made available in a secured way. 
It says TLS.  Anything else?  A draft suggestion only, additional 
sentence:

   There are areas at the IETF site that may require updated, modern
   security-aware connection client access software to be used
   as required for industry compliance standards, e.g.; PCI/DSS.

Nothing to do with PR, but it doesn't hurt either.

Thanks

-- 
HLS

On 4/4/2014 2:53 PM, Dick Franks wrote:
> Tinkering with the text of a 90 word statement full of PR claptrap is
> not going to achieve anything.
>
> The starting point for any sensible discussion on this topic is a
> threat model, for each service,  against which the effectiveness of
> proposed mitigation strategies can be assessed.
>
> Until that is forthcoming, reasoned discussion taken place, and
> (rough) consensus reached, this proposal MUST go nowhere.
>
>
> Dick
> ________________________
>
>
>
> On 4 April 2014 18:43, Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I would add and be specific with the last sentence, for example,
>     the IETF site
>     "new services" might need to be PCI/DSS compliant. This is
>     especially the case if the IETF site is collecting credit card
>     information for IETF meeting registrations or other purposes.  For
>     logging in purposes, it may also need to be PCI/DSS compliant
>     depending on the AUTH method. For DIGEST AUTH, it may require SSL
>     and NONCE support. BASIC AUTH requires SSL, and it may not be
>     sufficient for PCI/DSS unless there is other methods wrapping the
>     BASIC AUTH process, i.e. a cookie method method. A form-based
>     cookie login methods, where there is no standard protocol method,
>     may require other conditions. Overall, there are areas at the IETF
>     site that require updated, modern security-aware connection client
>     access software to be used as required by industry standards such
>     as PCI/DSS.  (I note, that this is probably USA, not sure how that
>     applies in Europe, Asia, etc)
>
>     Maybe visiting one of the PCI/DSS resource/compliance sites can
>     tell you what compliancy level the IETF site may fit.  Depending
>     on what software is used, it may suffice or it may not, thus
>     perhaps even adding new functional requirements to the IETF Web
>     Site revamping project.
>
>     Hope this helps
>
>     --
>     HLS
>
>
>         [1] https://tools.ietf.org/html/__rfc6797
>         <https://tools.ietf.org/html/rfc6797>
>
>
>
>
>
>     --
>     HLS
>
>
>

---

From: Dick Franks <[email-masked]>
Date: Fri, 4 Apr 2014 21:12:26 +0100

On 4 April 2014 20:48, Hector Santos <[email-masked]> wrote:

>
> Everyone else has already touch based with the same issues.

>  Silence could easily be misconstrued as acceptance.

[snip]

>   Stephen asked about the last sentence:
>
> Which to my eye looks like a conclusion;  without shred of justification
and before any meaningful discussion has taken place.

26 messages on and the consensus thus far is that an answer to Lloyd Wood's
one-liner is very much required.

---

From: <[email-masked]>
Date: Fri, 4 Apr 2014 23:58:46 +0100

I haven't had an answer to my questions from Stephen.

why?

again, why?

"Because... SECURITY!" would not be a good answer.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Dick Franks [[email-masked]]
Sent: 04 April 2014 21:12
To: Hector Santos
Cc: IETF-Discussion
Subject: Re: Security for various IETF services

On 4 April 2014 20:48, Hector Santos <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

Which to my eye looks like a conclusion;  without shred of justification and before any meaningful discussion has taken place.

26 messages on and the consensus thus far is that an answer to Lloyd Wood's one-liner is very much required.

---

From: Pranesh Prakash <[email-masked]>
Date: Fri, 04 Apr 2014 19:05:57 -0400

> documents and information using HTTP and FTP.

And these tools and scripts will stop working if HTTPS or FTPS are used? 
   Can these tools and scripts not be made to work/compile with NSS / 
GnuTLS / OpenSSL?  Or is it just that it is easier not to deal with 
encryption?

Curl, wget, and even the perl-based Twitter client I use (ttytter) all 
work just fine with SSL, so I'm curious what tools and scripts have 
trouble using encryption.

-- 
Pranesh Prakash
Policy Director, Centre for Internet and Society
T: +91 80 40926283 | W: http://cis-india.org
-------------------
Access to Knowledge Fellow, Information Society Project, Yale Law School
M: +1 520 314 7147 | W: http://yaleisp.org
PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Apr 2014 17:02:46 -0700

> I haven't had an answer to my questions from Stephen.

I think that the question has been answered adequately, if not
directly in this thread by Stephen himself.  By Fred, Dave, and by
others.

I found the answers sufficiently compelling, even if it seems like you did not.

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Apr 2014 01:12:35 -0400

--On Friday, April 04, 2014 19:05 -0400 Pranesh Prakash
<[email-masked]> wrote:

>>>  Could you please expand on this?  What kinds of legacy
>>>  tools is that statement talking about?
>> 
> And these tools and scripts will stop working if HTTPS or FTPS
> are used?    Can these tools and scripts not be made to
> work/compile with NSS / GnuTLS / OpenSSL?  Or is it just that
> it is easier not to deal with encryption?

I can't speak for Randy's, but, for the ones I use, yes, they
will stop working.  And, no, I don't have access to source or
other arrangements that would permit me to recode and recompile
them.

> Curl, wget, and even the perl-based Twitter client I use
> (ttytter) all work just fine with SSL, so I'm curious what
> tools and scripts have trouble using encryption.

See my earlier message.
    john

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sat, 5 Apr 2014 08:50:21 +0000

>> and other services.

Please confirm that "friendly" implies that the user gets to
choose the degree of security privacy that they consider 
appropriate, and that their applications and devices are not 
encumbered  with the overheads unless they choose to invoke
the privacy and security mechanisms.

>> While most (but not all) data on IETF

I agree, but please can you clarify your interpretation
of "best practise" so that we can understand how
liberal or prescriptive this is?

>> available in ways that use security protocols such as

That is worrying, because it seems that you are intent on
encumbering transactions, without requiring a case by 
case study of the threat model, and applying a security
and privacy model that is appropriate to the specific 
transaction.

Stewart.

---

From: <[email-masked]>
Date: Sat, 5 Apr 2014 10:38:51 +0100

"That is worrying, because it seems that you are intent on
encumbering transactions, without requiring a case by
case study of the threat model, and applying a security
and privacy model that is appropriate to the specific
transaction."

yes. not coincidentally, that's EXACTLY what Stephen
encouraged in DTNRG, starting with MD5-is-ALWAYS-bad
and working up to the-security-model-is-everything. As
opposed to the needs of the networking scenario.

we had the perpass debate, and here we go again.
Well, you've been warned.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: ietf [[email-masked]] On Behalf Of Stewart Bryant (stbryant) [[email-masked]]
Sent: 05 April 2014 09:50
To: Stephen Farrell
Cc: IETF-Discussion; The IESG
Subject: Re: Security for various IETF services

Stewart.

---

From: Hector Santos <[email-masked]>
Date: Sat, 05 Apr 2014 09:21:25 -0400

On 4/4/2014 4:12 PM, Dick Franks wrote:
> Which to my eye looks like a conclusion;  without shred of
> justification and before any meaningful discussion has taken place.

I don't see anything odd about the statement. My input, once again and 
I'll leave it at this, there might be 'new services' where the IETF 
has no "legal" OR "Security Audit" choice but to provide it in secured 
only mode and thus, for those who need to get access MUST be updated 
with modern software client access tools that support such security, 
not just TLS.   The IETF lawyer should determine if they must comply 
with PCI/DSS security audits.  Thats all. It wasn't difficult.

Of course, where it isn't needed, its common sense to keep legacy 
access for the old timers to access it via their own means or tools. 
  That includes me with various simple access tools, in particular, a 
non-SSL FTP scripting tool for quick command line download of RFC 
files from the IETF ftp site.  If that was made SSL only, we would 
have to update the script. I don't have time for that so it would 
"break something" for me.

> Wood's one-liner is very much required.

I didn't see anything that stood out. Are you referring to his why 
question?  Really?  It seems others answered why.

Thanks for your comments.

-- 
HLS

---

From: <[email-masked]>
Date: Sat, 5 Apr 2014 14:40:17 +0100

"I didn't see anything that stood out. Are you referring to his why
question?  Really?  It seems others answered why."

they did not.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Hector Santos [[email-masked]]
Sent: 05 April 2014 14:21
To: Dick Franks
Cc: IETF-Discussion
Subject: Re: Security for various IETF services

--
HLS

---

From: [email-masked]
Date: Sat, 05 Apr 2014 10:19:30 -0700 (PDT)

Agreed on all points. This is rapidly turning into the IETF's own version
of "if we can, we must" thinking.

				Ned

---

From: Tim Bray <[email-masked]>
Date: Sat, 5 Apr 2014 10:29:15 -0700

> the privacy and security mechanisms.

Here, I think, is a key issue.  I disagree with Stewart.  WHAT?!  How can I
possibly disagree with
​user choice?  Because, a huge majority of people

(a) aren’t aware that there is a choice to be made, and shouldn’t need to be
(b) do not understand the technical issues surrounding the choice, and
shouldn’t have to
(c) do not understand the legal/policy issues surrounding the choice, and
shouldn’t have to

This includes both the people who use online services and the people who
offer them.  Thus, the only sane ethical position is to operate in a mode
that is private by default, because the consequences of a negative failure
(the user really didn’t need privacy but got it anyhow) are immensely less
damaging than the consequences of a positive failure (the user really
needed privacy but didn’t get it).

​Yes, it is certainly desirable that for those who are in the unusual
position of being confident that they understand the technical and policy
issues, they be given the option of choosing to operate in plain-text
anyone-can-MITM anyone-can-eavesdrop mode.  But saying that the needs of
that very small and specialized group of people should trump the interests
of the vast majority who shouldn’t have to understand or worry about where
privacy is appropriate and how to provide it; that seems bizarre to me.

So yeah, please turn the IETF’s public-facing offerings over into
private-by-default mode. It’s the only ethical course of action.  -T

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Apr 2014 16:52:18 +0100

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

---

From: Dick Franks <[email-masked]>
Date: Sun, 6 Apr 2014 20:27:52 +0100

On 5 April 2014 14:40, <[email-masked]> wrote:

> Other noises off-stage are rrelevant

The author(s) of the proposal MUST provide the threat model for each
service and a reasoned argument why the proposed action mitigates the
identified threat or threats.

Engineering best practice demands no less.

Transparent decision process demands no less.

Ignoring Lloyd Wood's question is not an option.

Dick Franks

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Apr 2014 23:11:46 +0100

> Engineering best practice demands no less.

I disagree. Asking for a threat model seems odd, since the
proposed IESG statement isn't specific to a particular service
and absent that you can't sensibly construct a threat model I
think.

> Transparent decision process demands no less.

I have no idea what's apparently opaque.

> Ignoring Lloyd Wood's question is not an option.

LLoyd's questions were answered IMO.

S..

---

From: <[email-masked]>
Date: Sun, 6 Apr 2014 23:49:59 +0100

> LLoyd's questions were answered IMO.

they weren't.

Lloyd Wood
Sent: 06 April 2014 23:11
Cc: IETF Discussion

S..

---

From: David Morris <[email-masked]>
Date: Sun, 6 Apr 2014 16:08:06 -0700 (PDT)

> that doing so isn't a good plan.

Um, it is not difficult to protect the login credentials will leaving
the remainder of the interaction in the clear. Then it won't matter
what is the the email.

I don't object to making TLS/et al access available when it can be
done at a moderate cost. But that is different than the implied
statement that the intent is to require TLS for future service
access.

I agree with those who've said a threat analysis is needed before
deciding access is limited to TLS or other secure alternative.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Apr 2014 23:30:11 +0000

> deciding access is limited to TLS or other secure alternative.

But we have that threat analysis, and the recommended mitigation is precisely "encrypt everything." The "pervasive monitoring" threat is analyzed by a number of perpass drafts, and Stephen has merely followed the conclusions of that analysis. There is no need to repeat that analysis for each and every tool that the IETF produces, and there is indeed a need for the IETF as a whole to "lead by example."

-- Christian Huitema

---

From: <[email-masked]>
Date: Mon, 7 Apr 2014 01:35:38 +0100

https://datatracker.ietf.org/wg/perpass/
that's a lot of drafts.

and yet perpass is still not a WG with formal process and charter? Odd, that.

Knee-jerk reactions are not good things.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Christian Huitema [[email-masked]]
Sent: 07 April 2014 00:30
To: [email-masked]
Subject: RE: Security for various IETF services

-- Christian Huitema

---

From: mohammed serrhini <[email-masked]>
Date: Mon, 07 Apr 2014 04:40:15 +0400

I agree, The Security and Risk Analysis  is major looks at how to redesign systems that are secure, how to measure risk, and how ensure that proper levels of privacy are maintained for individual  users.  Remember that security is a process, not a
product. not all security and privacy are resolved technically,  without forgeting that User is Weak node of chain. 
HSTS ,  TLS ,HTTPS  FTPS  or NSS / GnuTLS / OpenSSL  .   can  break  the IETF web site old tools.  but provide  levels of privacy and security . 
The delivery and maintenance team is responsible for on-going updating and monitoring, including security measures for access control and information confidentiality.  when there are mechanisms in place to establish
privacy and trust  .

Serrhini Mohammed

>But we have that threat analysis, and the recommended mitigation is precisely "encrypt everything." The "pervasive monitoring" threat is analyzed by a number of perpass drafts, and Stephen has merel…

С уважением,
mohammed serrhini
[email-masked]

---

From: <[email-masked]>
Date: Mon, 7 Apr 2014 02:05:43 +0100

to enlarge on that:
http://www.ietf.org/proceedings/88/perpass.html
no charter

http://tools.ietf.org/wg/perpass
not found

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: 07 April 2014 01:35
To: [email-masked]; [email-masked]
Subject: RE: Security for various IETF services

Lloyd Wood

-- Christian Huitema

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Apr 2014 16:42:16 +1000

> Knee-jerk reactions are not good things.

QED

---

From: <[email-masked]>
Date: Mon, 7 Apr 2014 08:37:40 +0100

> 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.

> "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.

> 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

Lack of past performance is no guarantee of future failure.
________________________________________
From: ietf [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 06 April 2014 16:52
To: IETF-Discussion
Subject: Re: Security for various IETF services

S.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 07 Apr 2014 01:08:00 -0700

>statement that the intent is to require TLS for future service

I read the statement as being about not having recurring discussions 
about whether access to a future service will require secure 
access.  That's worthwhile.

https://datatracker.ietf.org has links to http://tools.ietf.org/  and 
http://www.ietf.org.  The "Search" link is to 
"www.google.com".  jabber.ietf.org is listed as having the following issues:

   - Certificate is not trusted
   - Server allows SSLv2, which is obsolete and insecure.
   - Server does not support the newest version, TLS 1.2.

The mail service does not support STARTTLS.

The current guideline for services is "server security based on 
best-practices and data sensitivity level".  There isn't any 
information about the best-practices for information which will be 
publicly available.  Some people have been accessing (IETF) publicly 
available information using clear-text protocols for many years.  The 
people do not consider "X is spying on you" as a reason to stop using 
those protocols.

A few months ago, a person (not in the IETF) posted the following comment:

   "I'd really like to know how secure this offer is before considering it...."

Regards,
S. Moonesamy

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 10:40:07 +0100

On 05/04/2014 18:29, Tim Bray wrote:
> On Sat, Apr 5, 2014 at 1:50 AM, Stewart Bryant (stbryant) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Here, I think, is a key issue.  I disagree with Stewart.  WHAT?!  How 
> can I possibly disagree with
> (c) do not understand the legal/policy issues surrounding the choice, 
> and shouldn’t have to
>
> This includes both the people who use online services and the people 
> who offer them.  Thus, the only sane ethical position is to operate in 
> a mode that is private by default, because the consequences of a 
> negative failure (the user really didn’t need privacy but got it 
> anyhow) are immensely less damaging than the consequences of a 
> positive failure (the user really needed privacy but didn’t get it).
I could be persuaded towards "crypto by default", but I hear in these 
discussions "crypto as an exclusive mode", and I do not think that is an 
acceptable constraint on implementations.

Privacy and authentication always ends up taking CPU, memory and 
bandwidth, which in turn costs money, silicon, power, weight and 
complexity. If a specific application requires privacy and or 
authentication, then fine, but each case needs to be examined on its own 
merits. Now you may say "ah but we are getting so much better at the 
engineering that who cares about such things", to which I would point 
out that such thinking stunts our ability to build things that are 
orders of magnitude smaller, lighter, cheaper and more power efficient 
than we can conceive of oday.

So please, let's not react to the recent news on spying, by creating a 
security religion that in the end hurts us even more that the problem we 
are reacting to.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 10:51:29 +0100

> can afford a bit of processing on the ends. :)
Randy

It is incorrect to assume that those considerations no longer apply. The
engineering and economics still apply, but to much smaller, cheaper,
lower power, and potentially far more ubiquitous, devices.

Stewart

---

From: Brian Trammell <[email-masked]>
Date: Mon, 7 Apr 2014 12:09:18 +0200

On 07 Apr 2014, at 11:40, Stewart Bryant <[email-masked]> wrote:

>> On Sat, Apr 5, 2014 at 1:50 AM, Stewart Bryant (stbryant) <[email-masked]> wrote:
>> 
>> Here, I think, is a key issue.  I disagree with Stewart.  WHAT?!  How can I possibly disagree with  ​user choice?  Because, a huge majority of people
>> 
>> (b) do not understand the technical issues surrounding the choice, and shouldn’t have to
>> (c) do not understand the legal/policy issues surrounding the choice, and shouldn’t have to
>> 
>> This includes both the people who use online services and the people who offer them.  Thus, the only sane ethical position is to operate in a mode that is private by default, because the consequences of a negative failure (the user really didn’t need privacy but got it anyhow) are immensely less damaging than the consequences of a positive failure (the user really needed privacy but didn’t get it).
> I could be persuaded towards "crypto by default", but I hear in these discussions "crypto as an exclusive mode", and I do not think that is an acceptable constraint on implementations.

Then let's talk about crypto by default, which I think is a useful position in the case of IETF services, which is of course the subject of the thread. Here the specific threats posed by an adversary are:

(1) Leakage of browsing history. It may be tempting to presume that there is no value to the information that person X was interested in IETF documents w, y, and z, at time t, but that is indeed a presumption. We don't know X, and we can't presume to know why X might think their interest in the work of the IETF (or their presence at a particular point in time when they were accessing our services) is private, so we should make it as easy as possible to use TLS to at least limit the passively-observable information to that about the flow. And it doesn't get any easier than on-by-default. :)

(One could say that post-Snowden there is no reasonable practical presumption of privacy over HTTP, and that people using HTTP are knowingly serving up their browsing history to all observers. I have to agree with Tim on this point, though. As far as I am concerned this threat is justification enough to provide TLS by default for IETF web services. The details of how to do this to best "upgrade" initial landings without breaking access for deep-links and/or automated processes are just that, details of implementation.)

(2) Credential theft and subsequent impersonation: unencrypted access to the datatracker could allow eavesdroppers to impersonate anyone who logs in over HTTP. Yes, there are non-TLS ways to deal with this, though I'm not sure how universally reliable they are. (We also send mailing list credentials in plaintext at incredibly predictable times, so it would be relatively easy for someone to bulk-unsubscribe most of the IETF from most of our mailing lists, but that's unrelated to web services.)

I think the practical risk here is only of vandalism, creating a mess in the datatracker that it would take a fair amount of work to clean up. Any impersonation materially impacting the process would presumably (hopefully) be detected by the impersonated themselves. And the possibility of someone actually doing this certainly seems far-fetched, but so do so many of the things one reads in the press these days on this subject.

Protecting credential exchange by default via TLS for IETF web services requiring a login is a nice side-benefit to addressing (1) above, but if we think we have really good reasons for addressing (2) without addressing (1), there are ways to do so that are slightly computationally less expensive. It would take some effort to convince me that this is the correct tradeoff though.

(3) Injection/deletion/modification of RFC or draft content inline. There are already lots and lots and lots of places that mirror our documents anyway, so TLS won't help much here. The appropriate way to handle this is to sign the documents, not to provide protection on the wire. As I understand it this is an ongoing project anyway. Ignoring issues with the web PKI, TLS provides a practical bootstrap to this process by ensuring authenticity and integrity of public keys for verification retrieved from a known source.

There are probably a few others, but I think I've used all my Narten points for the week.

So there are specific reasons to do this, beyond simply increasing the cost of bulk collection by adding a few drops to the growing ocean of traffic encrypted on the wire.

> Privacy and authentication always ends up taking CPU, memory and bandwidth, which in turn costs money, silicon, power, weight and complexity. If a specific application requires privacy and or authentication, then fine, but each case needs to be examined on its own merits.

Yep. And I think in the case of the IETF services the real question comes down to "is the impact on 'restricted execution environments' worth the benefit (especially wrt threat 1) to default-on TLS for *.ietf.org?"

> Now you may say "ah but we are getting so much better at the engineering that who cares about such things", to which I would point out that such thinking stunts our ability to build things that are orders of magnitude smaller, lighter, cheaper and more power efficient than we can conceive of oday.

Agree completely.

Cheers,

Brian

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 11:14:19 +0100

On 06/04/2014 16:52, Stephen Farrell wrote:
>     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
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."
> 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.
> that doing so isn't a good plan.
This is a very sweeping statement, which is surely application
specific?
> 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.
> just have to try again tomorrow.
I am not sure that last para is called for.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 11:17:17 +0100

> and absent that you can't sensibly construct a threat model I
The request is surely that the specification of the application
include the threat model, which seems a very reasonable
requirement.
> LLoyd's questions were answered IMO.
I regret that I am not convinced they were.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 11:20:58 +0100

On 07/04/2014 00:30, Christian Huitema wrote:
> But we have that threat analysis, and the recommended mitigation is precisely "encrypt everything." The "pervasive monitoring" threat is analyzed by a number of perpass drafts, and Stephen has merely followed the conclusions of that analysis. There is no need to repeat that analysis for each and every tool that the IETF produces,
A (justified) reference to a base RFC is surely allowed, and the degree 
of commonality will surely determine whether it passes on the nod, or 
the covers get taken off for a closer investigation.

> and there is indeed a need for the IETF as a whole to "lead by example."
I am concerned that statement makes too broad an assumption about what 
an application is let alone what a threat mitigation is.

Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Apr 2014 12:01:39 +0100

Brian's response covers the issues very well I think. (Thanks.)

Just one thing to add...

On 04/07/2014 11:09 AM, Brian Trammell wrote:
> I think the practical risk here is only of vandalism, creating a
> mess in the datatracker that it would take a fair amount of work to
> clean up. Any impersonation materially impacting the process would 
> presumably (hopefully) be detected by the impersonated themselves. 
> And the possibility of someone actually doing this certainly seems 
> far-fetched, but so do so many of the things one reads in the
> press these days on this subject.

Given that password re-use over many services is common, there is
also the not at all insignificant risk that any credentials captured
could be abused elsewhere with more impact.

Yes, we ought move away from passwords if/when we ever find an
acceptably better solution, and yes, people ought manage their
passwords well, but neither are today's reality more's the pity.

S.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Apr 2014 09:03:06 -0400

> passwords well, but neither are today's reality more's the pity.

Perhaps it would be worth setting up support for client certs as a way to log in to IETF services.   If we won't start, why would someone else?

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Apr 2014 10:02:22 -0400

--On Monday, April 07, 2014 09:03 -0400 Ted Lemon
<[email-masked]> wrote:

> Perhaps it would be worth setting up support for client certs
> as a way to log in to IETF services.   If we won't start, why
> would someone else?

If we are really serious about promoting/ encouraging security,
I'd really like to see this as an option.  Not only would it be
responsive to Ted's question, but, if we made it available and
almost no one used it, it would give us a lot of information
about the course we are on.

As to the core proposal, unlike SM, I would like to see each new
application that someone proposes to be accessible through
"secure" means only discussed one at a time.  My fear of the
whole Prepass effort was that it would be used in "we approved
that, therefore we can and should do this without further
discussion" arguments.  I just thought it would take a few years
to get to that point.

Finally, if the IETF effectively declares HTTP obsolete for
anything but legacy applications, I think it is logically
necessary that we create an applicability statement deprecating
HTTP and approve it.  Anyone really, seriously, want to go there
or think that would could without losing all credibility in the
vendor and user communities?

   john

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 07 Apr 2014 09:12:59 -0500

> Perhaps it would be worth setting up support for client certs as a way to log in to IETF services.   If we won't start, why would someone else?

(Speaking as 1/15th, but only 1/15th, of the IESG that's asking for 
community input on this topic)

For me, "If we won't start, why would someone else?" was a significant 
consideration. I'm not locked in on any particular path, but I thought 
it was useful to ask about this was that if the IETF can't make an 
improved security environment work, that's not a good sign 
(http://en.wikipedia.org/wiki/Eating_your_own_dog_food).

We can spin up new working groups to address problems we encounter. Most 
communities seeking to improve their security environment can't do that.

So, from my own perspective, on-by-default would be sufficient to find 
out what I'd like to find out ... but I'd love to find out at least part 
of what we'd like to know, in a post-Snowdon world.

We could find out something, without making Stewart run a 
state-of-the-art secure environment on his IoT device to FTP Internet 
Drafts.

Spencer

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2014 15:24:57 +0100

On 07/04/2014 15:02, John C Klensin wrote:
> application that someone proposes to be accessible through "secure" 
> means only discussed one at a time.
I concur with John.
> My fear of the whole Prepass effort was that it would be used in "we 
> approved that, therefore we can and should do this without further 
> discussion" arguments. I just thought it would take a few years to get 
> to that point.
That was the root of my object to the publication of the Attack RFC.

- Stewart

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Apr 2014 10:55:57 -0400

On Apr 7, 2014, at 10:12 AM, Spencer Dawkins <[email-masked]> wrote:
> We could find out something, without making Stewart run a state-of-the-art secure environment on his IoT device to FTP Internet Drafts.

Well, e.g. allowing client certs for authentication without requiring them would certainly be interesting.   And we certainly should make sure that authentication credentials are never accidentally sent in the clear—the web server shouldn't even propose authentication other than over a secure link.   Not sure we can do that with FTP.

---

From: <[email-masked]>
Date: Mon, 7 Apr 2014 16:04:55 +0100

once you hand security the keys to your organisation, it's no longer your organisation.

I am unsurprised by the increasing speed of security moves here (really, security
policy matters; policy is easy to push. governments do it all the time) and
the increasing slowness of everything else. (it's been twenty years since
RFC1323bis kicked off. Don't hold your breath.)

Lloyd Wood

I was right in warning about DTN. Seems I''m right in warning about this. right?
________________________________________
From: ietf [[email-masked]] On Behalf Of Stewart Bryant [[email-masked]]
Sent: 07 April 2014 15:24
To: John C Klensin; Ted Lemon; Stephen Farrell
Cc: Tim Bray; IETF-Discussion; The IESG
Subject: Re: Security for various IETF services

I concur with John.

- Stewart

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 7 Apr 2014 19:50:34 +0000

From: ietf [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Sunday, April 6, 2014 4:30 PM
> To: [email-masked]
> But we have that threat analysis, and the recommended mitigation is
> precisely "encrypt everything." The "pervasive monitoring" threat is analyzed
> by a number of perpass drafts, and Stephen has merely followed the
> conclusions of that analysis. There is no need to repeat that analysis for each
> and every tool that the IETF produces, and there is indeed a need for the
> IETF as a whole to "lead by example."

I've been following this thread with some amusement, as it was clear that when the perpass draft took its unusual journey from personal draft submission to BCP the fallout would include things like an immediate call for all IETF services to be encrypted. At the same time, there are an equally well known number of attacks against TCP itself that make TCP the wrong substrate upon which to build "secure" communication channels. (Just a couple of well-known examples: the ease of session hijacking of established connection and SYN flood attacks against well-known servers, both of which lead to denial of service and potentially forcing the user to downgrade to an alternative channel for obtaining the information).

If the same level of urgency were shown towards a viable, and secure, replacement for TCP itself, then the calls for secure-only access to IETF services might make sense. Instead, it feels a lot like requiring stronger deadbolts on glass doors.

Matthew Kaufman

---

From: [email-masked] (Martin Rex)
Date: Mon, 7 Apr 2014 23:17:18 +0200 (CEST)

John C Klensin wrote:
> 
> Ted Lemon <[email-masked]> wrote:
>>
>> Stephen Farrell <[email-masked]> wrote:
>>>

TLS _client_ certificates are typically used in closed groups,
where a single CA is issuing all these certs.

TLS client cert authentication has a few small issues.  The TLS server
needs to explicitly request the client cert (unsolicited client certs
are not possible/not allowed), and when the server asks for them
in the initial handshake, the client certificates will travel the
network _in_the_clear_.  Requesting client certificates only in the
renegotiation handshake has it own set of problems, besides twice
the full handshake crypto overhead.  For TLS renego problems and fixes
see rfc5746 and https://secure-resumption.com/

I also think that discontinuing the _public_ services of the IETF
over traditional, insecure channels (HTTP, anon-FTP, plain SMTP, whatever)
should require a threat analysis.

Different to what a lot of folks believe, TLS is neither a panacea nor
magic pixie dust.  In order to determine whether doing X-over-TLS really
provides the desired security characteristics, it is necessary to know
what security properties one is looking for.

The reason why there was an issue with TLS renegotiation is that applications
boldly assumed properties which never existed in the first place -- and
that problem would have been obvious if anyone of those abusing
TLS renegotiation for delayed authentication would have actually cared
to check for _the_real_TLS_protocol_characteristics_ instead of
believing in TLS magic pixie dust.

-Martin

---

From: Eric Gray <[email-masked]>
Date: Tue, 8 Apr 2014 09:20:48 +0000

Martin,

	You say "_the_real_TLS_protocol_characteristics_" like they are written down
somewhere.

	Would you care to provide a pointer?

--
Eric

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, April 07, 2014 5:17 PM
To: John C Klensin
Cc: IETF-Discussion; Tim Bray; The IESG; Stewart Bryant
Subject: Re: Security for various IETF services

-Martin

---

From: t.p. <[email-masked]>
Date: Tue, 8 Apr 2014 09:32:00 +0100

----- Original Message -----
From: "Spencer Dawkins" <[email-masked]>
To: "Ted Lemon" <[email-masked]>; "Stephen Farrell"
<[email-masked]>
Sent: Monday, April 07, 2014 3:12 PM
> > Perhaps it would be worth setting up support for client certs as a
way to log in to IETF services.   If we won't start, why would someone
else?
> (http://en.wikipedia.org/wiki/Eating_your_own_dog_food).

The path that I have seen several Security ADs steer Working Groups down
is to start with a threat analysis before deciding what counter measures
are appropriate.

Here, we seem to be following a path of 'We have got TLS with server
certs (which is pretty useless against most threats) so we will impose
that on everyone and call it an improved security environment'.

Solution first, requirements ignored.  This is not what I think of as
engineering.

Tom Petch

---

From: Scott Brim <[email-masked]>
Date: Tue, 8 Apr 2014 10:06:18 -0400

On Mon, Apr 7, 2014 at 3:50 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> If the same level of urgency were shown towards a viable, and secure,
> replacement for TCP itself, then the calls for secure-only access to IETF
> services might make sense. Instead, it feels a lot like requiring stronger
> deadbolts on glass doors.

FYI http://trac.tools.ietf.org/group/ppm-legacy-review/ticket/9

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Apr 2014 13:58:08 -0400

> Solution first, requirements ignored.  This is not what I think of as

Um, can you cite an example where someone in a position to do something about this has ignored the arguments that have been made on this thread?   Maybe you're talking about some other discussion?

---

From: Dick Franks <[email-masked]>
Date: Wed, 9 Apr 2014 01:02:56 +0100

> is to start with a threat analysis before deciding what counter measures
Several contributors have been saying exactly that for almost a week.

These suggestions have been answered by dismissive emails and a relentless
bombardment of magic pixie dust.

---

From: <[email-masked]>
Date: Wed, 9 Apr 2014 03:12:07 +0100

Gee, you don't need a threat analysis when you're going to protect against EVERYTHING!

That's SECURITY!

Lloyd Wood
Sent: 09 April 2014 01:02
To: t.p.

On 8 April 2014 09:32, t.p. <[email-masked]<mailto:[email-masked]>> wrote:

These suggestions have been answered by dismissive emails and a relentless bombardment of magic pixie dust.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Apr 2014 11:38:12 +0300

> These suggestions have been answered by dismissive emails and a relentless bombardment of magic pixie dust.

The thing is, the IETF websites are not that special. There’s a bunch of information, most of it public. The sites accept payments by credit card thrice a year. There’s a wiki. There’s some mailing lists with archives and registration pages, There’s content that can be edited by privileged users, and there’s other content that can be uploaded by anyone and viewed by anyone. Pretty much any corporate website has these parts.

The point of having best practices is that we don’t need to think about a threat model for each website. It’s a set of practices that someone has called “best practices” because they protect against several common types of attack at a low enough cost, that many web sites can implement them without actually proving to management that each part is strictly necessary.

Sure, we can have a debate here about the security needs of each service provided and have some of the most knowledgeable experts debate whether the www.ietf.org should have HTTP access, while datatracker.ietf.org should have only HTTPS, and tools. should have both and HSTS and HPKP to boot. But that is not eating our own dog food, because the next “store that sells soap making supplies on the ‘net” will not have access to such expertise. Our dogfood should be implementable by people who don’t read these mailing lists - the web site developer that said store hires. Hence the need for “best practices” shortcuts, which are very much a part of all branches of engineering.

That said, if there are security implications that are not common to regular websites, these should be considered and discussed. For example, if reading drafts and RFCs from the office might betray your company’s future plans, that is a good reason to allow encrypted access to RFCs. Or if reading certain articles on Wikipedia can get you in trouble in some countries, then encrypted access to those may be in order. And if having both encrypted and non-encrypted access results in encrypted access being red-flagged as subversive, that may be a good argument for encrypted access by default or even exclusively. 

But before diving into such a discussion we need to have a good argument for what makes us so special.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Apr 2014 09:43:06 +0100

I love how folks who it seems would rather we do nothing
are asking for more security process in this case.

IMO, the tools folks haven't gone terribly wrong on this in
the past and are not likely to do so in future. We are also
not developing new protocols for broad Internet use here
but rather talking about an IESG statement that those who
develop tooling and who deploy services should find useful
when considering new IETF services such as some new web
tool or remote participation tool. The statement also
reminds them to not go OTT and break stuff just in order
to improve security.

So no, we do not need a common criteria evaluation for
this and we will not suddenly forget how to do sound
engineering and no we do not need to do all that
engineering right now for every possible future service
and nor do we need to include "don't forget to do
engineering" in this IESG statement.

Regards,
S.

---

From: <[email-masked]>
Date: Wed, 9 Apr 2014 09:54:42 +0100

Yoav,

the problem here is that the perpass work (also spearheaded by Stephen) has redefined what 'best practice' is.

perpass gives the security contingent of the IETF no limit in mitigation of pervasive monitoring -
which means making everything as secure and private as possible, even when common sense,
threat analysis and conventional 'best practice' would say otherwise.

perpass makes the IETF special.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Yoav Nir [[email-masked]]
Sent: 09 April 2014 09:38
To: Dick Franks
Cc: IETF-Discussion
Subject: Re: Security for various IETF services

On Apr 9, 2014, at 3:02 AM, Dick Franks <[email-masked]<mailto:[email-masked]>> wrote:

Sure, we can have a debate here about the security needs of each service provided and have some of the most knowledgeable experts debate whether the www.ietf.org<http://www.ietf.org> should have HTTP access, while datatracker.ietf.org<http://datatracker.ietf.org> should have only HTTPS, and tools. should have both and HSTS and HPKP to boot. But that is not eating our own dog food, because the next “store that sells soap making supplies on the ‘net” will not have access to such expertise. Our dogfood should be implementable by people who don’t read these mailing lists - the web site developer that said store hires. Hence the need for “best practices” shortcuts, which are very much a part of all branches of engineering.

Yoav

---

From: <[email-masked]>
Date: Wed, 9 Apr 2014 10:05:12 +0100

Stephen,

once again I refer you to
http://www.ietf.org/mail-archive/web/ietf/current/msg81787.html

> we will not suddenly forget how to do sound engineering 

oddly enough, that happens. DTNRG forgot checksums, the
end-to-end-principle, designing for embedded systems...

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: 09 April 2014 09:43
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Security for various IETF services

Regards,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Apr 2014 10:06:37 +0100

Just in the highly improbable case that its not entirely
obvious: Lloyd is talking utter nonsense. (As usual on
this topic, sadly.)

S

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Apr 2014 12:12:06 +0300

I disagree that this is not conventional best practice.

Since I brought up soap making supplies, I typed that in google and the first result was http://www.brambleberry.com That’s a very conventional web store. It has instructional videos, forums for exchanging advice and recipes, and of course, the supplies themselves (with user-generated comments on each of them). 

As soon as you log in (necessary for posting on the forums and commenting on the supplies), you’re at HTTPS. You can use HTTP for browsing the videos, forums and comments, but if you’ve logged in, you do that over HTTPS as well. I’m pretty sure the people behind that store aren’t following perpass.

How is the IETF different enough that it needs *less* encryption than this store? As long as we provide HTTP access to the I-D and RFC repository (our “supplies”), why doesn’t it make sense to use HTTPS for other things?

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Apr 2014 09:12:14 -0400

On Thu, Apr 3, 2014 at 7:40 PM, Fred Baker (fred) <[email-masked]> wrote:
> From my perspective, I would support a statement to the effect that IETF technology should be obtainable using https or whatever else we are recommending as "secure." I'd also be in favor of asking IETF contributors to obtain and use PGP keys and/or DKIM encodings to sign messages. And of asking that IETF tools not reformat email in ways that corrupt data that has been signed.
>
> To that end, I could imagine a requirement for some kind of roadmap. "The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z, and traffic originated by the IETF sites shall use such protocols."

This sounds like a good idea. But we currently have a big problem in
that the IETF has two email security standards, not one. And the two
sides don't talk and this has created a stalemate that has blocked
ubiquitous use of either.

Today PGP has all the mindshare for encrypted messages and S/MIME has
all the deployment. Neither is a success at anything approaching
Internet scale. And neither is going to succeed in its current form.

The only way forward is going to be to develop a new specification
that is a worthy successor to both. Fortunately this is more a matter
of optics than technical work. 95% of the work is already done.

Any solution needs to comprise a message format, a trust model and a
configuration model. And all need to be just as easy to use as regular
mail is. 'Quite easy' does not cut it any more, today a security
standard must have no impact at all or it won't be used.

If we use the deployed infrastructure as a starting point and agree
that any new scheme must support the trust models of both PGP and
S/MIME, the way forward is pretty straightforward: Take the S/MIME
message format and graft the PGP web of trust and fingerprint trust
models onto it. What I have found is that this model is actually
demonstrably more secure than either model on its own when measured
against a time based work factor model.

The reason to take the S/MIME message format is twofold. First it is
the one that is already supported in billions of email clients. This
means that if we build on the S/MIME model those clients can read
encrypted messages without changing the client at all. That is a big
plus since I have to be able to read any message I receive on my
iPhone, iPad, and either of my two laptops and three desktops (total 7
machines). But I only need to be able to respond securely on two
(though all is better of course). The other advantage to the S/MIME
format is that it is a lot more mature than PGP/MIME and has been
completely and thoroughly tested in the deployed mail infrastructure.

I won't justify my trust model argument here since everyone who is
approaching the problem in good faith should be willing to accept that
the other side has good reasons for wanting their model. But in my
podcast I show that a hybrid of both is superior. I explain why both
is better here:

http://www.youtube.com/watch?v=PBFnBpWkK8M

(if people are interested I have put the whole design rationale onto YouTube).

I do have code as well as specs. Right now I am working on a part of
the design to make it easy to move keys from one client to another.
This is necessary because if I am trying to read an encrypted message
I need to be able to read it on any of my 7 machines. Right now that
is a hand cranked operation but there is no reason that it can't be
automatic. So I have a model that makes it easy to transfer the
private decryption key to other machines.

-- 
Website: http://hallambaker.com/

---

From: Randall Gellens <[email-masked]>
Date: Wed, 9 Apr 2014 19:01:16 -0700

At 9:12 AM -0400 4/9/14, Phillip Hallam-Baker wrote:

>>  To that end, I could imagine a requirement for some kind of 
>> roadmap. "The tools that access the IETF SMTP and HTTP sites use 
>> protocols X, Y, and Z. After <date>, we require them to use Secure 
>> X, Secure Y, and Secure Z, and traffic originated by the IETF 
>> sites shall use such protocols."
>
>  This sounds like a good idea.

To me it sounds like a knee-jerk reaction rather than an assessment 
of what we need to protect and what the costs are of various 
mechanisms.

>  But we currently have a big problem in

We actually have a few more email security standards, but regardless, 
I don't think the major barrier to deployment is that there is not a 
single standard.  There are a number of reasons why email end-to-end 
encryption is rarely used, which include the difficulty of managing 
keys, but it's also worth pointing out that end-to-end encrypted 
email breaks a lot of the anti-spam, unless users share their private 
keys with their mail provider (which kind of defeats the point).

-------------- Randomly selected tag: ---------------
Frequently, people can tell you they've read a book and
liked it, but they can't tell you why.  We don't want the
reader to have to do the hard work of figuring that out.
                    --Duncan Smith, creator of NoveList.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Apr 2014 07:51:50 -0400

On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens <[email-masked]> wrote:
>>>  To that end, I could imagine a requirement for some kind of roadmap.
>>> "The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and
>>> Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z,
>>> and traffic originated by the IETF sites shall use such protocols."
>>
>>
> To me it sounds like a knee-jerk reaction rather than an assessment of what
> we need to protect and what the costs are of various mechanisms.
>
>
> We actually have a few more email security standards, but regardless, I
> don't think the major barrier to deployment is that there is not a single
> standard.  There are a number of reasons why email end-to-end encryption is
> rarely used, which include the difficulty of managing keys, but it's also
> worth pointing out that end-to-end encrypted email breaks a lot of the
> anti-spam, unless users share their private keys with their mail provider
> (which kind of defeats the point).

As a meta-point, people can disagree with me over whether I have
solved all the problems but I am pretty sure that I already know most
if not all the problems that people come up with after thinking about
the problem for a few minutes. I have been discussing this for quite a
while now and I used to sell S/MIME as a main product for about ten
years. I have discussed the problem with Callas and Zimmerman.

Too much security is a really easy problem to solve: allow people to use less.

There are many reasons why end-to-end is not the only model that a
message layer encryption system should provide. It actually doesn't
break as much anti-spam as is imagined. Content-analysis is not a
powerful anti-spam technique. But there are some situations in which
archiving is required for regulatory reasons.

The end-to-end model should be an option, not a requirement.

I am very comfortable with a model in which 95% of my mail is
encrypted to a key held by my mail provider and the 5% that I consider
to be sensitive is secured under an end-to-end key only I hold and
mail is only accepted under that key from pre-approved senders.

I go into a very full requirements analysis for making secure email work here:

http://www.youtube.com/watch?v=06KyOCtjxLs

The end-to-end model is really not a useful one for security
discussions because the ends of the IP channel are not the same as the
ends of the conversation. The important part is being able to know
where the end-points are so that senders can make a decision on that
basis.

S/MIME and PGP don't actually enforce an end-to-end model. But because
they assume that is all that is wanted they make end-to-end an all or
nothing proposition.

Since my security concerns are a little different to most I would
probably end up with a three tier model in which mail from people I
don't know goes to the Gmail/Postini decryption key, most mail from
most people I have whitelisted goes to a decryption key that is on all
my machines I configure for mail and I also have a key for sensitive
stuff that is only on one or two machines or is in a smart token.

I can make the two tier scheme transparent from a usability point of
view but when we get into three or more tiers it starts to demand more
of users which is why I would not make it default.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Apr 2014 12:57:40 +0100

Just to note that this has wandered off topic, but is a
fine separate topic. Could be better on saag maybe but
please change the subject if continuing here.

Reason this is a different topic: this is about a new
protocol and is not something that'd be covered by the
proposed iesg statement until much later after it'd
worked out well.

Thanks,
S.