Subject: [websec] WEBSEC and The Need for More Than DNSSEC

From: Sam Caldwell <[email-masked]>
Date: Tue, 26 Oct 2010 03:02:14 -0500

Problem Statement:
------------------
Thus far the WEBSEC discussion appears to be focussed on DNSSEC.  However,
the
more significant security issues surrounding the web are largely uncovered
by
this discussion.  DNSSEC will help ensure that host A is connected to server
B
and that server B is in fact server B, but to borrow from one member of the
mailing list, "Just because someone has registered a domain does not mean I
want my machine to connect to theirs."  For this reason, while DNSSEC is a
welcome advance in Internet security, DNSSEC is a separate topic, and it
should
not obstruct the need for web-specific security measures to protect the
public.

Proposed Scope of WEBSEC:
-------------------------
WEBSEC must be defined clearly as a scope separate from, though
complementary
to the DNSSEC sphere.  This in mind, it is hereby proposed that WEBSEC be
defined as follows:

WEBSEC is a collection of standards and specifications aimed at ensuring
the integrity of communications between two hosts over the HTTP and HTTP/S
protocols through robust trust relationships.

Given that most web clients (i.e. browsers) operate from behind a NAT link
or
otherwise appear to the web browser to have a dynamic IP identity, it is not
realistic to use DNSSEC to represent any trust relationship.  DNSSEC may
potentially ensure the identity of the web server, but this does nothing to
protect the integrity of the client-server relationship, as the identity and
integrity of the client-side is wholly ignored.

The Trust Relationship:
-----------------------
WEBSEC must treat the client-server relationship as a whole.  The integrity
of
the relationship is a direct function of the integrity of both the web
server
AND the web client.  To this extent, WEBSEC must require the use of digital
signatures to uniquely identify each web server and web browser, its many
extensions and add-ons.  However, WEBSEC must remain backward compatible in
order to survive.  To this end, WEBSEC compliance should be relative.

If WEBSEC compliance were assigned some value relative to the current status
quo, then today's existing web browsers and servers would be the baseline
WEBSEC level zero (0).  Some minimal standard of compliance, such as the use
of digital signatures for the core components of the browser or server
software
might represent WEBSEC level one (1) compliance.  Meanwhile where a browser
or
web server implements full digital signatures for core components as well as
add-on modules, the same would meet WEBSEC level two (2) compliance.
 Additional
features would likewise represent increased compliance.

Relative compliance standards would allow a slow but stable transition from
the status quo of today to the ideal security position of tomorrow.  As new
features of WEBSEC are implemented by the community, the average compliance
rating should increase.  Additionally, the use of such scores will allow
both
the end-user (through his/her browser preferences) and the web administrator
(through his/her server configuration) to determine both their own
individual
WEBSEC compliance level as well as the minimum WEBSEC compliance level
required
to establish a trust relationship with one another.  Thus, for example, a
web
browser with a WEBSEC level one (1) compliance, might reject any attempt to
connect to web servers that do not meet level one (1) complaince standards.
 A
web administrator might also configure his/her web servers to require no
less
than level two (2) complaince in order to connect to certain sensitive
functions
of the web server (i.e. e-commerce) so as to protect the organization from
fraud.

The use of digital signatures in establishing the integrity of the two sides
of
the client-server relationship can also be used to secure their
communications.
Where the client has a digital signature unique to its particular build, it
has
a public key shared by all other instances of the same software.  This is
not
sufficient.  Instead, each build of a particular software module must be
signed
by an instance-specific certificate which is itself signed by a
build-specific
certificate that belongs to a certificate chain whose root is the WEBSEC
root
certificate authority.  The instance-specific certificate will allow each
individual web client or server to be identified from all others uniquely
(and
also allow for secure communications), while the build-specific certificate
will
certify the particular software has a valid heritage.  For example, a
particular
build of Mozilla Firefox for x86_64 packaged for Debian 5.04 would have a
build-
specific certificate.  This certificate ensures that all parties to a
client-
server relationship involving the particular build of Firefox can verify its
origins.  However, the same browser must also be signed uniquely (using
some
host- and time-specific GUID).  This is the instance-specific certificate,
and
it uniquely identifies the particular browser as a part of its host as well
as
a member of its browser family.  Using the instance-specific certificate,
WEBSEC may facilitate secure communications between client and server.

Levels of Trust and Security
----------------------------
Given the above specifications for a WEBSEC using build-specific and
instance-
specific certificates, WEBSEC may establish levels of trust.  Each level of
trust represents a new level of assurance that client-server interactions
are
both legitimate and secure.  The initial trust level ensures backward
compatibility with the existing world.  This state, or "trust level
zero(0),"
has no means of securing communications or ensuring the integrity of the
players.  However, trust level one (1) must provide at least build-specific
certificates, as described earlier, which ensure the integrity of the
players.
It remains possible at trust level one (1) for a man-in-the-middle attack
to
commit some fraud.  But this also requires a minimum initial investment on
the
part of web browser developers and web servers, and represents a significant
step in the right direction.  As trust level one (1) is adopted, trust
level
two (2) can begin to emerge.  Under level two (2), the instance-specific
certificates on both client (browser) and server sides are implemented.
 This
trust level secures communication between client and server, boosting
security
further.  When two WEBSEC-compliant parties connect, they may detect
through
the certificates each offers to the other, the highest level of trust
possible
and thereby make a determination as to whether or not they will continue
their
interactions.

Instance-specific certificates to secure communication go further than
DNSSEC
to protect the integrity of the web.  While DNSSEC can help to prevent
spoofing
of some domain by some third-party, WEBSEC as contemplated here, would help
to
secure the transmission of information betwen client and server, giving both
the
web administrator and the end user the power to better control these
relationships and defeat would-be prying eyes.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 26 Oct 2010 12:55:06 -0500

On 10/26/2010 03:02 AM, Sam Caldwell wrote:
> DNSSEC will help ensure that host A is connected to
> server B and that server B is in fact server B, but to borrow from
> one member of the mailing list, "Just because someone has registered
> a domain does not mean I want my machine to connect to theirs."

Seeing as how DNS is the 'domain name service' for the internet, and to 
'register a domain' is (by definition) to have the right to define DNS 
records for that domain, what does that statement actually mean?

Presuming you actually want to use the internet, you will need to 
connect to other machines at some point. By what name will you identify 
the machine you actually do intend to connect to which does not involve 
a registered domain?

Maybe you don't want to connect to evil-attack-site.com, but how does 
DNSSEC prevent that if you ask for it?

> WEBSEC must treat the
> client-server relationship as a whole.  The integrity of the
> relationship is a direct function of the integrity of both the web
> server AND the web client.

And is explicitly not dependent the network in between, which is 
presumed to be hostile.

> To this extent, WEBSEC must require the
> use of digital signatures to uniquely identify each web server and
> web browser, its many extensions and add-ons.   However, WEBSEC must
> remain backward compatible in order to survive.  To this end, WEBSEC
> compliance should be relative.

I don't like where this is going.

What's a "web server"?   What's a "web browser"?

Seriously, if you are going to talk about requiring certificates for 
every specific set of hardware or software used for "the web", you'd 
better have a near-perfect definition of these terms.

I don't think it can be done.

> Some minimal standard of
> compliance, such as the use of digital signatures for the core
> components of the browser or server software might represent WEBSEC
> level one (1) compliance.

There have been innumerable code-signing schemes proposed and deployed 
over the years and I doubt any of them have increased security one bit.

Instead, they are only useful for locking down computing hardware to 
prevent the hardware's owner from using it to perform computations not 
approved by the vendor. Of course, this has eventually failed every time 
it has been tried so only serves to delay the inevitable.

>  Meanwhile where a browser or web server
> implements full digital signatures for core components as well as
>  Additional features would likewise represent increased compliance.

How would a digital signature for "core components" improve security?

You might find some examples of trojaned installers somewhere, but 
realistically, of all the vulnerabilities and actual incidents involving 
web security, how many were due to users running nonstandard web browsers?

> Relative compliance standards would allow a slow but stable
> transition from the status quo of today to the ideal security
> position of tomorrow.  As new features of WEBSEC are implemented by
> the community, the average compliance rating should increase.
> Additionally, the use of such scores will allow both the end-user
> (through his/her browser preferences) and the web administrator
> individual WEBSEC compliance level as well as the minimum WEBSEC
> compliance level required to establish a trust relationship with one
> another.  Thus, for example, a web browser with a WEBSEC level one
> (1) compliance, might reject any attempt to connect to web servers
> that do not meet level one (1) complaince standards.  A web
> administrator might also configure his/her web servers to require no
>  less than level two (2) complaince in order to connect to certain
> sensitive functions of the web server (i.e. e-commerce) so as to
> protect the organization from fraud.
>
> The use of digital signatures in establishing the integrity of the
> two sides of the client-server relationship can also be used to
> secure their communications. Where the client has a digital signature
> unique to its particular build, it has a public key shared by all
> other instances of the same software.  This is not sufficient.
> Instead, each build of a particular software module must be signed by
> an instance-specific certificate which is itself signed by a
> build-specific certificate that belongs to a certificate chain whose
> root is the WEBSEC root certificate authority.

You seem to place a lot in using digital signatures to enforce 
"compliance", but haven't said yet how it will actually improve security.

Yeah, it's actually really easy (and strangely appealing to some people) 
to design a top-down control system and imagine that it will solve all 
our problems. People have tried this kind of thing over and over again 
and it always either sucks so bad that it doesn't get deployed, or it 
gets deployed at huge expense and sucks for everyone who has to use it 
until it can be thrown out.

In reality, people don't trust top-down. People trust in complex 
networks for subtle reasons that are often wrong. But for some reason, 
it's the top-down trust models that turn out to have the most 
catastrophic failure modes every time.

> The instance-specific
> certificate will allow each individual web client or server to be
> identified from all others uniquely (and also allow for secure
> communications), while the build-specific certificate will certify
> the particular software has a valid heritage.  For example, a
> particular build of Mozilla Firefox for x86_64 packaged for Debian
> 5.04 would have a build- specific certificate.

Last time I used Debian as a client, they weren't permitted to build 
"Firefox" due to trademark issues. The thing they packaged was called 
"Iceweasel". Who is going to decide that "Debian Iceweasel" is or is not 
a "compliant web client" with a "valid heritage"?

Stuxnet had free usage of not one, but two, valid code-signing 
certificates for a year or more.

> This certificate
> ensures that all parties to a client- server relationship involving
> the particular build of Firefox can verify its origins.

No, it doesn't actually work that way.

In practice, any other piece of code running with that user's 
permissions, root permissions, outer virtual machine, or even write 
access to any number of filesystem locations has the ability to inject 
code into the iceweasel process. Signing some build package does 
absolutely nothing to prevent malicious code from running in the browser.

> However, the
> same browser must also be signed uniquely (using some host- and
> time-specific GUID).  This is the instance-specific certificate, and
> it uniquely identifies the particular browser as a part of its host
> as well as a member of its browser family.  Using the
> instance-specific certificate, WEBSEC may facilitate secure
> communications between client and server.

Oh I see now. Here we come down to it.

In your vision of the secure web, everyone will be required to be 
running an approved, "compliant" browser and register their computer 
with some central authority.

There were lots of networks run by telephone companies and such which 
implemented that kind of model. We using the internet that we have today 
precisely because every single one of those other models died out! They 
sucked, didn't scale, and were unequivocally rejected by the market.

> Levels of Trust and Security ---------------------------- Given the
> above specifications for a WEBSEC using build-specific and instance-
> specific certificates, WEBSEC may establish levels of trust.  Each
> level of trust represents a new level of assurance that client-server
>  interactions are both legitimate and secure.  The initial trust
> level ensures backward compatibility with the existing world.  This
> state, or "trust level zero(0)," has no means of securing
> communications or ensuring the integrity of the players.  However,
> trust level one (1) must provide at least build-specific
>  players. It remains possible at trust level one (1) for a
> man-in-the-middle attack to commit some fraud.  But this also
> requires a minimum initial investment on the part of web browser
> developers and web servers, and represents a significant step in the
> right direction.  As trust level one (1) is adopted, trust level two
> (2) can begin to emerge.  Under level two (2), the instance-specific
> certificates on both client (browser) and server sides are
> implemented. This trust level secures communication between client
> and server, boosting security further.  When two WEBSEC-compliant
> parties connect, they may detect through the certificates each offers
> to the other, the highest level of trust possible and thereby make a
> determination as to whether or not they will continue their
> interactions.
>
> Instance-specific certificates to secure communication go further
> than DNSSEC to protect the integrity of the web.  While DNSSEC can
> help to prevent spoofing of some domain by some third-party, WEBSEC
> as contemplated here, would help to secure the transmission of
> information betwen client and server, giving both the web
> administrator and the end user the power to better control these

Giving some central ministry of information the authority to "approve" 
"compliant" softare and even require "licensed users" of some future 
supposedly-secure web. We've been down this road in the past. (The next 
shoe that drops is key escrow.)

But you didn't explain how this grand scheme of "compliance" is going to 
prevent any of the current real-world security holes:

Q: What will it do about the 10-100Ms of MS Windows client PCs (web 
clients) pwned with malware?
Q: What will it do about Adobe PDF and Flash plugins that come 
preinstalled with dozens of exploitable security holes?
Q: What will it do to prevent client systems from an innumerable number 
of root and intermediate CAs?
Q: What will it do to prevent phishing?
Q: What will it do about SQL, XSS, or other script injection?
Q: What will it do about Debian signing a "compliant" server with no 
entropy in its cryptographic RNG?
Q: What will it do to prevent users from using the same weak password 
everywhere?

A: Nothing.

And lest we forget:
Q: What will it do to support individual privacy, anonymity, and control 
the leakage of their personal data and prevent
marketers/credit bureaus/insurers/governments/attackers from tracking 
their every movement online?

- Marsh