Subject: [perpass] Security delivery model

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jan 2014 12:11:10 -0500

If we are going to secure the net we need more than specifications, we need
running code and configurations to match.

Right now the problems caused by us using SHA1 are vastly less than the
problems caused by systems that are just terribly configured or don't make
the right security checks.

I have an exploit that lets me dump out usernames and passwords enclair
from certain applications despite the apparent use of 'security' because
most of the clients and many of the servers out there are not configured
right. But it does not currently even merit a CERT advisory because it
isn't a bug in the code or the specification, it is a configuration failure.

So here is the proposal, IETF and W3C develop a series of profiles for how
to lock down a service (Web, mail, chat) that provide specific security
protections against specified attacks. The suite would also include
profiles for backbone, datacenter providers etc.

These profiles can then form the basis for a range of security services
that can be fulfilled by providers as appropriate to the needs of the
clients.

So for example, Comodo and the other CAs and some of the DNS registrars can
pitch in on the retail end and provide 'off the shelf' services that are
locked down to a calibrated security profile. Then at the other end of the
scale very large enterprises with a designated CISO would call in the likes
of big consulting companies to deploy.

There would also be business opportunities for independent consultants. In
fact I am not sure that the retail model is going to be viable unless I can
tell an unprofitable customer that their needs are beyond what the flat
service fee model can support and they need to contact an independent
contractor.

This is of course something the industry has traditionally looked to NIST
to provide. But lets face it, that model is dead. It might be five years
before we can get people in a room together. Meanwhile we face real threats.

I see a number of questions here, one of which is what the appropriate
venue is. Another is what community should be involved. While this probably
needs to be an IETF or W3C activity it need not necessarily take place at
IETF meetings. A technical session lumped onto the front of Blackhat while
the admin type folk are in the training sessions might well be a better
venue. We probably want to follow up on Jim Getty's advice to connect to
the Linux Plumbers.

Security protocol designers are not the best folk for finding holes because
most of the holes are created by people doing stuff that is just so stupid
most of us would never think to do it.

But the work does need to be done somewhere and it needs to be an open,
unencumbered specification that draws on open standards.

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

---

From: Walter Pienciak <[email-masked]>
Date: Thu, 30 Jan 2014 09:49:11 -0700

"Best practices" implementation guides have real value.  We've seen them
developed for specific application/platform deployment, and other
organizations such as USENIX and SANS have shown there is a demand for them
by the folks in the trenches.  I agree that standards/protocols guides are
much more uncommon; to what extent that is due to "out of scope"
determination by the employers of
standards developers is an open question.

But to reiterate:  "best practices" guides with a security focus would be a
valuable addition to the many efforts underway already.  Inexpertly
administrated resources will always be an issue, no matter the efforts
ranging from random number generation through hardening of transport and
data exchange.

Walter

Walter Pienciak
Senior Manager, Technology Community, IEEE Standards Association

[email-masked]
+1 303 527 0934

On Wed, Jan 29, 2014 at 10:11 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> If we are going to secure the net we need more than specifications, we
> need running code and configurations to match.
>
> So for example, Comodo and the other CAs and some of the DNS registrars
> can pitch in on the retail end and provide 'off the shelf' services that
> are locked down to a calibrated security profile. Then at the other end of
> the scale very large enterprises with a designated CISO would call in the
> likes of big consulting companies to deploy.
>
> Security protocol designers are not the best folk for finding holes
> because most of the holes are created by people doing stuff that is just so
> stupid most of us would never think to do it.
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>
>

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Thu, 30 Jan 2014 17:04:09 +0000

Good points.
In the meanwhile, we invite you to join the effort at UTA http://datatracker.ietf.org/wg/uta/charter/ .
Orit.

From: perpass [mailto:[email-masked]] On Behalf Of Walter Pienciak
Sent: Thursday, January 30, 2014 8:49 AM
To: Phillip Hallam-Baker
Cc: perpass
Subject: Re: [perpass] Security delivery model

"Best practices" implementation guides have real value.  We've seen them developed for specific application/platform deployment, and other organizations such as USENIX and SANS have shown there is a demand for them by the folks in the trenches.  I agree that standards/protocols guides are much more uncommon; to what extent that is due to "out of scope" determination by the employers of
standards developers is an open question.

But to reiterate:  "best practices" guides with a security focus would be a valuable addition to the many efforts underway already.  Inexpertly administrated resources will always be an issue, no matter the efforts ranging from random number generation through hardening of transport and data exchange.

Walter

Walter Pienciak

[email-masked]
+1 303 527 0934

On Wed, Jan 29, 2014 at 10:11 AM, Phillip Hallam-Baker <[email-masked]> wrote:
If we are going to secure the net we need more than specifications, we need running code and configurations to match.

Right now the problems caused by us using SHA1 are vastly less than the problems caused by systems that are just terribly configured or don't make the right security checks.

I have an exploit that lets me dump out usernames and passwords enclair from certain applications despite the apparent use of 'security' because most of the clients and many of the servers out there are not configured right. But it does not currently even merit a CERT advisory because it isn't a bug in the code or the specification, it is a configuration failure.

So here is the proposal, IETF and W3C develop a series of profiles for how to lock down a service (Web, mail, chat) that provide specific security protections against specified attacks. The suite would also include profiles for backbone, datacenter providers etc.

These profiles can then form the basis for a range of security services that can be fulfilled by providers as appropriate to the needs of the clients.

So for example, Comodo and the other CAs and some of the DNS registrars can pitch in on the retail end and provide 'off the shelf' services that are locked down to a calibrated security profile. Then at the other end of the scale very large enterprises with a designated CISO would call in the likes of big consulting companies to deploy.

There would also be business opportunities for independent consultants. In fact I am not sure that the retail model is going to be viable unless I can tell an unprofitable customer that their needs are beyond what the flat service fee model can support and they need to contact an independent contractor. 

This is of course something the industry has traditionally looked to NIST to provide. But lets face it, that model is dead. It might be five years before we can get people in a room together. Meanwhile we face real threats.

I see a number of questions here, one of which is what the appropriate venue is. Another is what community should be involved. While this probably needs to be an IETF or W3C activity it need not necessarily take place at IETF meetings. A technical session lumped onto the front of Blackhat while the admin type folk are in the training sessions might well be a better venue. We probably want to follow up on Jim Getty's advice to connect to the Linux Plumbers. 

Security protocol designers are not the best folk for finding holes because most of the holes are created by people doing stuff that is just so stupid most of us would never think to do it. 

But the work does need to be done somewhere and it needs to be an open, unencumbered specification that draws on open standards.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 Jan 2014 12:28:39 -0500

On Thu, Jan 30, 2014 at 12:04 PM, Orit Levin (LCA) <[email-masked]>wrote:

> Good points.
> In the meanwhile, we invite you to join the effort at UTA
> http://datatracker.ietf.org/wg/uta/charter/ .
> Orit.
>

Using TLS in Applications is useful work but not quite what I was
suggesting.

I think the security profiles need to be more than 'best practices'. They
need to be a set of specific practices that meet specific security
requirements.

There are some areas where a security profile activity might lead to
standards work. For example I am pretty sure that some of our application
protocols cannot be deployed securely and standards compliant.

There is also a question of audience participation. The audience for these
specs would be security practitioners, not protocol designers. Most of the
application security holes being created right now involve tools that I
would simply never consider using because they are a security nightmare. It
took quite a lot of us quite some time to understand the significance of
HTTP injection attacks because we would never consider hooking up a
scripting language in that way in the first place.

So the community that needs to buy in here is the OWASP/BlackHat community
rather the protocol design community.

I don't really want to set up yet another standards organization and these
may not be standards in the usual sense. It certainly seems useful to
re-use IETF or W3C to publish the profiles.

But there may be an advantage to some sort of political separation. I can
point to quite a few IETF specs that have been broken as far as practical
deployment goes and efforts to fix the problem have been thwarted through
committee inertia. What looks good to a standards committee can be
absolutely cretinous in actual deployment.

To take a non IETF example, can anyone fill in the blank here?

if (x != x)  { <what code goes here?> }

We can thank an IEEE committee for that particular facepalm. Some idiots
worrying about mathematical models and laws developed a standard that
creates ugly holes in the laws of every programming language built on that
spec.

The laws of occam originally included IF (x = x) <proc> |= <proc> and IF (x
!= x) <proc> |= SKIP. But those aren't true and someone with their pants in
a bunch on a standards group is to blame.

So if we have a group look at mail security profiles I would really like
the political setup to allow that group to publish a report stating that X,
Y and Z are defects in the SMTP, TLS or whatever protocols and for that to
publish without someone on the IESG being able to veto it because they want
to protect their baby.

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Thu, 30 Jan 2014 19:32:06 +0000

>Using TLS in Applications is useful work but not quite what I was suggesting.
These are complementary approaches, indeed.

>...I am pretty sure that some of our application protocols cannot be deployed securely and standards compliant.
Please, submit these cases to UTA if related to usage of TLS. This will be very helpful and open to the broad community review.

>There is also a question of audience participation. The audience for these specs would be security practitioners, not protocol designers. 
One of the important UTA's (and of IETF at large) goals is broadening the "security practitioners" circle to include "application protocols" designers and developers. I believe that this cross-pollination of ideas and needs will make a practical difference.

Orit.