Subject: [saag] Important open-source activities...

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Dec 2014 02:24:13 +0000

Hiya,

The IESG have recently been discussing how the IETF would
work better with or for open-source communities. As part of
that it'd be good to get some appreciation of which open
source activities folks consider important (and why). And
of course there are multiple directions here - e.g. where an
IETF activity has fed directly into an open-source activity
and the opposite where the IETF end up documenting something
already done by some open-source community.

As part of that analysis, an utterly reasonable question
was asked: yeah, but which open-source things are important
to IETF participants?

So, which bits of open-source do we in the security area
of the IETF consider important and why? And what could
we do better? (For any sensible definition of "we":-)

BTW, those are deliberately open questions - answer in any
way you like, (but pithily please:-) to the list or to
Kathleen and I off-list if need be. (If we see a bunch of
offlist answers, we'll summarise those back to the list.)

And since this is really information-gathering, there's
no need for us to disagree with one another on the list
(but I expect we won't resist that specific temptation, as
usual:-)

Thanks,
S.

---

From: Edward Lopez <[email-masked]>
Date: Sat, 20 Dec 2014 05:56:19 +0000

Whenever I speak on network security, I always point out that my principal axiom is the "security is not required to create productivity".  Creating productivity is easy, we do it continuously within the IETF.  Securing productivity is really hard.  In the end, we end up relying on trust rather than security, and hope for the best.  At the end of the day, we end up trusting implementations of our efforts.

A big part of the problem is that we in the IETF generally represent the interests of the closed-source community, in many cases developing protocols which represent a lowest common denominator of interoperability, which the commercial interests that fund us work to out compete each other within closed and costly implementations.

Now the open-source community is organizing, such as the case with Linux Foundation projects and ONF, and is seeking open networking and management solutions.  They've stepped beyond 'working consensus and running code' to include implementation frameworks.

You asked for how we might correctly engage the open-source community.  Part of that discussion has to include why a rift is forming in the first place.  IMHO, the IETF doesn't do a good job in evolving implementation frameworks, and since the majority of security issues evolve from implementation, we're not currently in a good position to collaborate effectively. 

Ed Lopez - Fortinet

> On Dec 19, 2014, at 6:24 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Alan DeKok <[email-masked]>
Date: Sat, 20 Dec 2014 09:13:52 -0500

> A big part of the problem is that we in the IETF generally represent the interests of the closed-source community, in many cases developing protocols which represent a lowest common denominator of…

  The IETF has involvement from a sub-set of the closed-source community.   In my experience, many operational people need changes to protocols, but they’re not involved in the IETF.  They may not have time, of course.  But a larger reason seems to be that there’s no organization interest in having them participate.  Their jobs are limited to fighting fires, not researching new ways of preventing fires.

  That lack means that work in the IETF is often driven by research or marketing goals.

> Now the open-source community is organizing, such as the case with Linux Foundation projects and ONF, and is seeking open networking and management solutions.  They've stepped beyond 'working conse…

  Those communities are largely funded by commercial interests.  Companies have discovered that they need open source, but they can’t afford to own the people / technology involved.  Instead of paying license fees and support to commercial organizations, they fund open source projects.  This is all about risk mitigation for the purchaser.  If they want to stop paying for open source, they just stop.  In contrast, when they license software from a commercial entity, they’re held hostage.  The seller can (nearly) arbitrarily raise prices, end of life products, etc.

> You asked for how we might correctly engage the open-source community.  Part of that discussion has to include why a rift is forming in the first place.  IMHO, the IETF doesn't do a good job in evo…

  Engaging the open source community means funding people.  They can be funded to write implementations, be given existing implements, or funded to participate in the IETF.  Without funding, your only choice is to wait for someone to make the technology his hobby.  You may be waiting a long time.

  I’m not sure any rift has “formed” between the IETF and the open source community.  I’m not sure there was ever any coordinated efforts between the two.  What I have seen is that protocols often get pushed to add features for marketing reasons.  In contrast, the push from open source participants tends to be for for simplicity, ease of implementation, etc.  Because they have a limited budget, and they want to get things done.

  That being said, I’ve been running an open source project for 15+ years.  My opinions are naturally positive towards my own experiences. 

  And I’m involved in the IETF out of personal interest.  I’m self funded, but I think it would be a good idea to investigate how to get more open source people involved in the IETF.

  Alan DeKok.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Dec 2014 15:54:18 +0000

> we do better? (For any sensible definition of "we":-)

Security protocols with at least one reasonably solid and flexibly
licensed open source implementation include:

    * SSH
    * Kerberos V5 and GSSAPI
    * DNSSEC
    * SASL

Note however, that BIND 10 seems to have run out of steam and could
use support!  MIT has managed to build a consortium for funding
ongoing Kerberos development, Heimdal is on the other hand currently
cycle starved.

I don't know how Cyrus SASL development is supported.

The MIT model works when there is strong corporate user interest,
and the project gets funding from large enterprise users their
enterprise vendors that would not otherwise be able to market the
toolkit (nobody buys Kerberos, they buy systems in which it is
simply there).

The Kerberos situation is of a somewhat general nature.  Foundational
security software rarely makes a useful product, and only thrives
when open source development gets broad support from vendors who
bundle it and perhaps larger users who depend on it.

Things are much less pretty in the TLS space, but OpenSSL is now
getting some funding to attempt to dig itself out of its miserable
state.  It'll be interesting to see how this model evolves.

If DTLS is important, it is far from obvious.  Where are the working
implementations?

In the DANE space there are many "toy" implementations, and it is
not always easy for users to distinguish these from trustworthy
code.  There is at present little vendor interest, deployment is
for now far too limited.

Much security at the network layer was for a time driven by projects
like NetBSD.  Is Linux picking up enough of the slack now that it
is soaking up most of the mind-share and the vast majority of the
corporate backing?

So it looks "the computer industry" is not always well positioned
to deliver those technologies that are core building blocks, but
don't provide a clear competitive advantage.  How to avoid starving
implementations of core security protocols remains an open problem
I think.

-- 
	Viktor.

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 20 Dec 2014 14:25:23 -0500

Hi Stephen,

Sorry to go offlist even after you said something about it. This is
related to your questions below, and not an answer to them.

It would also be helpful to know who the adversaries are, and what
threats they pose. So security goals and threat models should be
standard fair.

I'm still befuddled at the position taken on interception in standards
like TLS and Public Key Pinning. I don't understand how an active
attacker is not considered a threat (or maybe, more correctly, only a
part-time threat).

When the next Google Summer of Code (GSoC) arrives, I'm going to
suggest the IETF get a few interns and document and produce a document
on security goals and a threat model. I understand high caliber folks
like you, Sean Turner, EKR, etc are busy - hence the reason to make
interns available to you. So don't look it as an insult when it
happens.

Jeff

---

From: ianG <[email-masked]>
Date: Sun, 21 Dec 2014 16:25:23 +0000

On 20/12/2014 19:25 pm, Jeffrey Walton wrote:
> Hi Stephen,
>
> Sorry to go offlist even after you said something about it.

(I'm not sure you're offlist, but nothing shocking to me in your comments.)

> This is

It's interesting to propose that IETF get into threat modelling.

But I am cautious.  I guess I'm infamously on record for opposing such a 
thing, at least in one instance [0].  This relates to the SSL protocol 
assuming a thing called the "Internet Threat Model [1]" which was 
suggested to be some form of standard.  I argue it was not only not 
standard, it was the opposite of reality in terms of the threats we face 
or faced at the time.

Although, arguably, we could say that with the advent of the NSA attacks 
on core router nodes (passively collecting everything) and the upsurge 
in ISP datamining, SSL and ITM has finally come of age...

Also, if the IETF wanted to get into that area, isn't is just a matter 
of starting a WG and preparing an RFC?

iang

[0] http://iang.org/ssl/wytm.html
[1] http://www.iang.org/ssl/rescorla_1.html

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 Dec 2014 13:08:08 -0500

> It's interesting to propose that IETF get into threat modelling.

rfc 7132 for example

randy

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Dec 2014 14:10:38 -0500

> attacker is not considered a threat (or maybe, more correctly, only a

It's a threat, but active attackers can kill all communication if they want.
It's not that it's not a problem, it is that we can only deal with so many
problems at the same time, and attempts to authenticate all end points tend
to look like attempts to boil the ocean. Further, if done in naive ways, it
can completely lock down innovation, and/or provide governments with even
MORE ways to oppressive citizens.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Dec 2014 14:27:16 -0500

> already done by some open-source community.

I've read the thread. Alan's response is astute, but I don't think it answers
your question.

    > was asked: yeah, but which open-source things are important

I don't really understand this question.
What's an IETF participant?

The problem is that both "IETF participant" and "open source contributor" are
self-selected groups of people.   Open source works best when the people
involved have an internally driven need to do something ("scratch an itch").
They are then not driven by market or consulting revenue needs.

IETF participation works best when the participants need to cooperate with
others to get something done;  either one entity can control a bit of both
ends, or some business interaction naturally involves both ends.
(Microsoft IIS/IE in the early days of "XMLHttpRequest" and Adobe Flash
are good historic examples of what happens when entities fail to engage in
either standards or open source)

So I think that the community around HTTP: apache/nginx/rails/django/etc,
plus the chrome/firefox/android/libcurl is now a really place.

The tragedy of openssl is mostly one of tragedy of the commons: no place I've
worked on SSL things has ever been willing to do other than "take" from that
space.  (We could have some discussions about how BSD vs GPL licenses may
contribute to this neglect)

webrtc would, I think, have been impossible without the ability of
experimenters to hack on both sides of the fence, and then bring their
results to the IETF.

    > we do better? (For any sensible definition of "we":-)

We collectively continue to regularly neglect IPsec.

It's been relegated to site to site, and yet, it is easily applied
conceptually to many application to application scenarios, but there is no
"libipsec", so most are afraid to specify it.
We have significant chicken and egg situations with a number of security
protocols.

If I had my druthers, there would be a golden egg to fund three or four open
source implementations of everything that went through the security area.
And not just "research" projects either.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Dec 2014 15:42:05 -0500

> plus the chrome/firefox/android/libcurl is now a really place.

s/now a really place/is now in a REALLY GOOD place/

---

From: Watson Ladd <[email-masked]>
Date: Mon, 22 Dec 2014 07:55:02 -0500

On Sun, Dec 21, 2014 at 11:27 AM, Michael Richardson
<[email-masked]> wrote:
<snip>
> contribute to this neglect)

There are multiple alternate implementations of SSL, and were before
the Heartbleed brought attention onto the sorry state of OpenSSL. Some
of them, like PolarSSL, are quite good. Many of the authors of these
implementations are involved in the TLS WG. The reason no one has
switched is that OpenSSL exposes large, poorly specified API, which
tends to intertwine the application with the underlying library.

(Some clients, like curl, have multiple TLS implementations they can use)
> experimenters to hack on both sides of the fence, and then bring their

This should not be unusual: it's how TCP was made, etc, etc. 7000 RFCs
later, and not one of them has had anything close to the impact of the
early ones. (Yes, it's also how FTP was made: hacking a solution does
not mean that things worked in a sane manner) But what is the benefit
of bringing things to the IETF, if you can write an implementation and
describes how it works, and that implementation is portable to almost
every OS people run out of the box?

> We have significant chicken and egg situations with a number of security

Which application scenarios/protocol would those be?

IPsec is supported on every operating system I can think of, including
the *BSDs, with high quality, free implementations. The problem is
that IPsec naturally maps onto VPN or related kinds of networks:
applications typically want something closer to the semantics TLS
provides. One could design a system that negotiated an SA before
sending a packet to a system, but why not use TLS instead, especially
given the need for OS-level changes?

(If you think protocol XYZ is neglected, does it do something protocol
ZYX does not? Are the implementations better quality? etc)

The fact that there are now two kinds of OS in the world: *nix and
Windows. This makes writing portable code, as opposed to
reimplementation, a viable strategy for becoming ubiquitous. As a
result, standards become less important. At the same time we've made
it much harder and expensive to get drafts published.

Something like Pond doesn't need to become a standard to become widely
adopted. See also Tor, Napster, Bittorrent, etc. It's not actually a
problem that people don't use the IETF. It is a problem when we don't
solve problems that they face with the results. We've known NTP
security was undeployable, and DNSSEC had administrative issues, for
quite some time. This hasn't lead to any sort of work on a fix.

Unless we start from looking at the benefits and costs of working with
the IETF, we won't understand why people act the way they do. The
question should be "what does the IETF do for open source, and what
should it do"?

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Dec 2014 08:54:17 -0500

On Dec 22, 2014, at 7:55 AM, Watson Ladd <[email-masked]> wrote:
> There are multiple alternate implementations of SSL,

  13 years ago (when I started using it), the only open source one of any functionality was OpenSSL.

> and were before

  Open source programs didn't have an alternative to OpenSSL.  Now they do.  But migrating from one library to another is a major effort… which isn’t funded.

  RedHat has submitted patches for many pieces of software to move from OpenSSL to NSS.  But they’re a commercial company, and have funding.

> But what is the benefit

  Many reasons.  A documented standard is often better than no standard.  Open source people recognize that companies exist, and one way to get wider adoption in a corporate environment is to have a standard.  And getting peer review is usually beneficial.

> it much harder and expensive to get drafts published.

  Napster, bitttorent, etc. showed you can get wide-spread adoption if there’s sufficient customer interest.  But that’s in the consumer space.

  For software to be used in the enterprise or telco space, there is a higher tendency towards standards, and off the shelf commercial solutions.  So the IETF still has a place.

  In my favorite protocol (RADIUS), I’ve been running the main open source project (FreeRADIUS) for over 15 years.  As best I can tell, everyone outside of the top 5 switch vendors uses it.  Vendors, telcos, ISPs, enterprises, etc.  Yet if I wanted to extend the protocol myself, I would get *no* traction.  Creating standards in the IETF is the only way to solve real-world needs.

> quite some time. This hasn't lead to any sort of work on a fix.

  Are there any commercial reasons to fix those protocols?  I can’t think of any.  That means there will be no funding to fix them.

  There is an open source alternative (DJB’s DNScurve).  If it solves a real-world need, why hasn’t it become ubiquitous?

> question should be "what does the IETF do for open source, and what

  The IETF doesn’t do a lot for open source that I’ve seen.  As Michael said, most open source projects are about someone scratching an itch.  Studies show that most open source projects are written and/or run by one person.

  If the IETF wants more involvement in a particular are, the best option, then, is to find the one critical person, and get them to participate.

  Alan DeKok.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Dec 2014 11:21:42 -0600

> already done by some open-source community.

The IETF's main open-source activity is producing open-source standards,
which is why it's relatively easy to find open-source implementations of
them (compare to other SDOs).  The IETF's secondary open-source activity
is producing tools for its own consumption.

IETF participants often produce/maintain or help to produce/maintain
open-source implementations of Internet protocols, but this is not an
IETF activity.

> was asked: yeah, but which open-source things are important

First and foremost: continue producing open-source Internet Standards.

Second: continue producing open-source tooling for the IETF's own needs.

Third: continue to liase with other SDOs, and *perhaps* liase with
highly visible and important (by deployment) open source projects.  Let
ISOC get involved with open-source projects if it wants to.

Fourth: encourage IPR holders (in so far as the IETF possibly can) to
provide meaningfully-free access for use in open-source implementations,
and preferably not just limited to infectious licensing.

As an aside, security is generally seen as a cost center, and a fairly
high cost center at that.  Intangible costs/benefits generally don't get
accounted for.  We've seen how failure to account for opporutinity and
other intangible costs can cause highly visible failures.  Open-source
projects provide a way to share some of these costs, but a risk is that
insufficient attention will be paid, leading to low-quality open-source
implementations -- there is no easy fix; TANSTAAFL.

> we do better? (For any sensible definition of "we":-)

If the value of "we" is "the IETF"...  I fear that getting the IETF to
be involved with open-source projects not directly related to the IETF's
needs... would be a distraction.  We, the IETF's participants, are still
volunteers; herding us is like herding cats.

If the value of "we" is "IETF usual suspects that can influence
funding", then in general I'd say: we need high-quality open-source
reference implementations of critical infrastructure pieces all over the
stack and across areas, not just security (e.g., if we want some new
congestion control protocol to get deployed, we'll need it implemented).
Security-area standards probably deserve more attention than the others,
for the reasons given in the aside above.

That said, if "we" (the IETF in general) are going to go down this road,
I'd say that high-quality security protocol implementations (with good,
usable APIs) are that which we need the most, mainly: a) PK
authentication (PKIX and DANE), b) TLS.

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: Wed, 24 Dec 2014 14:50:32 -0500

> licensed open source implementation include:

I would also add OpenPGP to the list, although I suppose GPL (the
license of GnuPG) is probably not considered a "flexible license."  But
there is also BouncyCastle's implementation, which is definitely more
flexible and I would consider "solid".

There are also multiple open source implementations of IPsec and IKEv1
that qualify by your definitions.

As for the question of "what can we do better", how about listing places
where we actually see problems?

In my experience the problems are getting more involvement from members
of Open Source Projects, in particular ones that aren't as well funded.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: ianG <[email-masked]>
Date: Mon, 29 Dec 2014 18:41:19 +0000

I have two observations speaking to the issue of the open source 
community and use of IETF standards.  I don't have solutions, just problems.

First of two:

1.  The never ending saga of secure browsing and website authentication: 
  It became obvious around about 2005 that phishing was rising and 
pillaging.  Browser vendors then could have done something about it, but 
did not.  This inaction requires answers.  One thing that they claimed 
stopped them doing anything was that they followed standards, and the 
standards weren't telling them anything different.

This brings up a whole host of issues for IETF as a standards org in the 
security area.

On investigation this claim appeared to have some merit.  Certainly, 
certain aspects appear true:  Vendors do follow standards and they won't 
for example listen to external agents on just anything [0].  Vendors 
have not typically employed what we might call security architects to 
actually work in this area (as opposed to security implementors) [1] 
thus confirming their intent to follow security standards and not do 
original security work [2].

Meanwhile, in contrast, some aspects are not true:  standards 
organisations do not believe that they tell vendors what to do. 
Standards would have not solved the phishing crisis because there wasn't 
in existence any standard that addressed the basic secure browsing 
flaw(s) which was the failure to identify a website not being secure, as 
it was an application failure not a TLS failure.

In short, I believe that in the case of phishing the vendors looked 
away, and standards gave them a convenient excuse to do that.

What could be done?  I think a minimum could have been for standards 
organisations to investigate such issues and state that it isn't their 
bailiwick.  Such a claim might have led to some valuable 
finger-pointing, and also some valuable rethinking.

In the latter vein, it is still not clear where the buck stops for 
secure browsing.  Who carries the liability for the user's losses, who's 
going to fix it, who's to blame?

Get any group of experts together and we can be sure of one thing:  "it 
isn't my problem."

This "whining & whinging" needs to be seen in the context of phishing 
rising up in the mid 2000s and industrialising the process to server 
hacking and so forth.  Billion dollar losses.  You only get to wear the 
badge of security if you're actually securing the users.

As I say, it's a problem to which I have no solution...

iang

[0]  In practice, no security vendor likes to listen to outsiders, as is 
seen with bug disclosures.  An oft-assumed mistake is to think that an 
open source vendor will listen to outsiders, but unfortunately this is 
not really true.
[1]  There is some evidence that one vendor is working at the security 
architecture level, but this is not the norm.
[2]  An unfortunate practice known as "best practices".

---

From: ianG <[email-masked]>
Date: Mon, 29 Dec 2014 18:41:46 +0000

I have two observations speaking to the issue of the open source 
community and use of IETF standards.  I don't have answers, just 
problems.  Second:

2.  The second issue which is more squarely in IETF's domain is the 
issue of standards & versions deprecation.  In short, things like SSL v2 
should have been rolled over a long time ago.

Now, it is very easy to say it's someone else's problem.  But if it is 
SEPs, then it is hard for IETF to claim it delivers secure protocols in 
the first place.

In any WG there are vicious and protracted arguments about getting a 
protocol secure and state of the art right now.  So there is certainly a 
consensus that a security area WG delivers a secure protocol.

But once complete, the thing is thrown over the wall.  Then the 
inevitable happens:  that protocol goes through a security rotting 
process, whereby what we thought was secure one day becomes clumsy the 
next, bad the following, and inevitably a joke.  For example, SSL v2, 
v3, old short cipher suites, MD5, RC4, etc.

If it is the WG's responsibility to deliver a secure protocol today, 
who's responsibility is it to change things when time rots the security 
statement?

iang

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Dec 2014 20:57:53 +0200

> On Dec 29, 2014, at 8:41 PM, ianG <[email-masked]> wrote:
> 
> 1.  The never ending saga of secure browsing and website authentication:  It became obvious around about 2005 that phishing was rising and pillaging.  Browser vendors then could have done something about it, but did not.  

Really? What could they do?

People get an email. It says, "click this link, and enter your Paypal credentials in the browser window.” So they click the link ( https://l33t-hax0rz-R-us.com/phish.html&site=paypal ) and see a PayPal logo. They proceed to fill in their credentials. 

What can the browser vendors do against that?

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Dec 2014 21:06:49 +0200

> I have two observations speaking to the issue of the open source community and use of IETF standards.  I don't have answers, just problems.  Second:
> 
> 
> 
> 2.  The second issue which is more squarely in IETF's domain is the issue of standards & versions deprecation.  In short, things like SSL v2 should have been rolled over a long time ago.
> 
> Now, it is very easy to say it's someone else's problem.  But if it is SEPs, then it is hard for IETF to claim it delivers secure protocols in the first place.
> 
> In any WG there are vicious and protracted arguments about getting a protocol secure and state of the art right now.  So there is certainly a consensus that a security area WG delivers a secure protocol.
> 
> But once complete, the thing is thrown over the wall.  Then the inevitable happens:  that protocol goes through a security rotting process, whereby what we thought was secure one day becomes clumsy the next, bad the following, and inevitably a joke.  For example, SSL v2, v3, old short cipher suites, MD5, RC4, etc.
> 
> If it is the WG's responsibility to deliver a secure protocol today, who's responsibility is it to change things when time rots the security statement?

Hi, Ian

To me this is similar to the Y2K problem. In the 1970s nobody believed that the software they were writing was going to still be used at the turn of the century. Turns out they were writing some pretty good stuff. The same is true today. Older OpenSSL versions, ancient Windows versions, they’re all around. In the 90s people replaced computers every 2-3 years. These days a 5 or 7 year old computer, even a server is quite usable, and it’s probably running the software that it shipped with. 

So it you’re providing a service for such computers, you have to keep compatibility with them. You can’t deploy today a server than won’t work with 7-year-old computers. So if seven years ago it made sense to ship a client that offered SSLv2, it’s problematic to ship a server today that will balk at an SSLv2 ClientHello.  It was easier in the 90s. By about 1997 you could ignore Windows 3.1 machines. By 2000 you could ignore Windows 95. That’s not true anymore. And this is an issue that the IETF can’t fix. The vendors could fix it if they could guarantee free and trouble-free software upgrades. They can’t.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Dec 2014 13:28:22 -0600

On Mon, Dec 29, 2014 at 06:41:19PM +0000, ianG wrote:
> 1.  The never ending saga of secure browsing and website
> authentication:  It became obvious around about 2005 that phishing
> was rising and pillaging.  Browser vendors then could have done
> something about it, but did not.  This inaction requires answers.

An assertion like this requires backup.  There have certainly been
attempts to address phishing.  I've attended one W3C workshop on the
matter (IDBROWSER); I presented there.  I recall many presentations were
made over several days.  I believe there have been other workshops I've
not attended.  There was some activity here in the IETF as well (look up
Sam Hartman's I-Ds, for example; Sam also presented at IDBROWSER).

Perhaps there is an underlying problem that we can't really solve
technologically: humans are easy prey for con artists.  We can only make
some attacks harder (e.g., confusables), but we can't really prevent
them.

There are other reasons for apparent slow movement.  But you're hot on
the trail here, so let's let you investigate them.

> One thing that they claimed stopped them doing anything was that
> they followed standards, and the standards weren't telling them
> anything different.

Got a link for this "they claimed" thing?  I'd like to read that.

> This brings up a whole host of issues for IETF as a standards org in
> the security area.

It probably would, yes.

> On investigation this claim appeared to have some merit.  Certainly,

You've investigated!  Great!  Please let us see your work.

> certain aspects appear true:  Vendors do follow standards and they
> won't for example listen to external agents on just anything [0].
> Vendors have not typically employed what we might call security
> architects to actually work in this area (as opposed to security
> implementors) [1] thus confirming their intent to follow security
> standards and not do original security work [2].

Footnotes!  Excellent!1!!  I'm looking forward to seeing some references
there for your investigation.

> [...skipping to the references...]
> 
> [0]  In practice, no security vendor likes to listen to outsiders,
> as is seen with bug disclosures.  An oft-assumed mistake is to think
> that an open source vendor will listen to outsiders, but
> unfortunately this is not really true.
> [1]  There is some evidence that one vendor is working at the
> security architecture level, but this is not the norm.

Oh, wait, no.  There's no actual references here.  That's a bit of a
let-down, eh.

Nico
--

---

From: ianG <[email-masked]>
Date: Wed, 31 Dec 2014 17:14:13 +0000

On 29/12/2014 19:28 pm, Nico Williams wrote:
> An assertion like this requires backup.

This is an area where every technical person worth his salt will leap 
forth and say "Naye, for it just ain't so."

I fought through all this for a multi-year era and got nowhere.  I've 
little incentive to try and battle through the excuses that get thrown 
in any more.  Right now I'm only looking at the big picture.

OP asked whether we could do more and better to work the open source 
security field.  I see phishing as an issue that regardless of the 
micro-events, at the macro level the industry failed to deal with.

Why was that?  What went wrong?

> There have certainly been

Did any of that effort make its way into browsers?  Did that change make 
a difference to phishing?

> some attacks harder (e.g., confusables), but we can't really prevent

Yep, that's excuse #1 in security geek forums.  It's social engineering, 
the user is responsible.

Sorry, it just doesn't fly in this case.

> Got a link for this "they claimed" thing?  I'd like to read that.

Personal conversations.  No "link" and you are entirely right that if 
you could get the vendors to comment on this at all they would deny it.

So you can write it off as just another crazy iang claim if you like.

> You've investigated!  Great!  Please let us see your work.

Cites!  Another lousy excuse to shut it all down.  Look, we all know 
that you can knock down a claim by demanding cites, research, et al. 
I've seen that played over and over by the browser vendors.  Whenever 
someone comes up with an idea, the vendor can say "show me the research, 
show me the evidence."  Idea, contribution, forward movement all stops.

So your best bet here is to do what the browser vendors do:  ignore the 
crazy fringe element on some base or another, and not worry about it. 
The vendors have allowed phishing to grow rampant without change since 
it arose, so the strategy worked for them.  An entire decade in which 
their liability has not been questioned.

Meanwhile, those people with a longitudinal view can look at the record 
of the different institutions in Internet security and ask how it's going.

What did we do over that decade, with all the info available to us?

I don't care if you don't like my story.  What's your version of what 
was done over a decade?  What went wrong?

iang