Subject: [therightkey] Basically, it's about keeping the CAs honest

From: Nico Williams <[email-masked]>
Date: Sun, 12 Feb 2012 19:39:30 -0600

Whether we pursue auditable CAs / notaries, Convergence, HSTS, user
authentication that can do channel binding -- all these options are
about keeping the CAs honest by making it too likely that MITMing CAs
(whether compromised or by business plan) will get detected.  Someone
made a comment about elegance.  I'm not sure that anything other than
making CAs auditable is elegant, but I don't think elegance is really
what we're after (though elegance is always nice).  I think we're
after a PKI where MITMing is not likely to pay off except in
relatively rare circumstances (e.g., when a new device is
bootstrapping itself), so rare that it isn't worth trying to MITM even
in those very few cases.

That would make me like PKI.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Feb 2012 17:36:41 +0100 (MET)

> bootstrapping itself), so rare that it isn't worth trying to MITM even

The fact that there are products (client-side HTTPS proxies that
perform MITM and inspect content) actively sold and used,
which are vitally dependent on being able to exploit weaknesses
of the existing TLS X.509 PKI security&trust model, is a sure proof
that something is wrong with the existing security model.

I do not think there is value in maintaining backward compatible
weaknesses, and personally, I do not mind the slightest about breaking 
those protocol subverting middle boxes, be it by the use of TLS channel
bindings, or the checking of DANE TLSA records.

-Martin

---

From: David Conrad <[email-masked]>
Date: Mon, 13 Feb 2012 10:21:35 -0800

> that something is wrong with the existing security model.

Well, it is proof that the theoretical model in which authorized MITM was disallowed was seen as too limiting. 

> bindings, or the checking of DANE TLSA records.

Pragmatically speaking, if you come up with an architecture that disallows people from doing what they want/need to do, they'll either figure out ways around it or not use that architecture. 

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Feb 2012 13:32:48 -0500

+1

It is also worth pointing out that the MITM certs stopped being
offered commercially as soon as it became public knowledge that they
had been.

Presumably the next step the companies providing this facility will
take is to offer their own browser with the capability built in. It is
no good jumping up and down saying people should not make such
devices. The choice we have is whether to do the job right or let them
do it without any input.

What I find wrong with the MITM proxies is that they offer a
completely transparent mechanism. The user is not notified that they
are being logged. I think that is a broken approach because the whole
point of accountability controls is that people behave differently
when they know they are being watched.

I don't mean just changing the color of the address bar either. I
would want to see something like the following:

0) The intercept capability is turned on in the browser, this would be
done using a separate tool and lock the browser to a specific
intercept cert root.

1) User attempts to connect to https://www.example.com
2) Browser throws up splash screen for 5secs stating 'Your connection
has been intercepted'
3) Business as usual.

The splash screen would appear once per session with a new host and
reset periodically.

It should show the interception cert being used as well.

On Mon, Feb 13, 2012 at 1:21 PM, David Conrad <[email-masked]> wrote:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Feb 2012 12:42:04 -0600

> when they know they are being watched.

I'm confused: if this is wrong, and if preventing MITMing CAs leads to
an MITM model that is right (because the users are informed), then why
does it no good to jump up and down saying that people should not make
MITM devices?  It seems to me that it will have done plenty of good.

The object for me is not to prevent MITMing when the user knows.  I
really don't care about corporate MITM devices because I assume users
(employees, contractors) are informed.  Like you I care about MITM
devices that users *don't* know about.

Not all spy-on-your-employees solutions are bad, thus the fact that
alternatives will arise does not necessarily bother me.  Only those
that can be used against users who are not informed or have no way to
avoid the MITM (employees can always... not use employer networks for
personal use).  Think of people in Iran, Syria, ...

Nico
--

---

From: David Conrad <[email-masked]>
Date: Mon, 13 Feb 2012 11:03:01 -0800

On Feb 13, 2012, at 10:42 AM, Nico Williams wrote:
> alternatives will arise does not necessarily bother me.

And they aren't all 'spy-on-your-employees'.  For example, companies such as CloudFlare (for whom I work), Incapsula, Torbit, etc., provide various web security and performance-related services by acting as a reverse proxy and scrubbing HTTP/HTTPS connections.  These services tend to be targeted at SMEs who are often less-than-technically-knowledable web site operators and those website owners will reject any solution that isn't transparent to their customers. While I can't speak for the others, CloudFlare's service is not in any way a "spy-on-your-employees" solution, rather it is a service in which website owners intentionally insert a MITM that helps them deal with various attacks (DDoS, blog spam, screen scrapers, etc).

Regards,
-drc

---

From: Martin Millnert <[email-masked]>
Date: Mon, 13 Feb 2012 20:08:01 +0100

> personal use).  Think of people in Iran, Syria, ...

With an ability to define how to interpret various security / trust
sources/inputs at the host operating system level, this is an already
solved issue.
  The managed corporate computer environment need only have a policy
activated which trusts the MITM-CA, and modulo application
implementations (including browsers), it is a matter of GUI/HMI how to
display the SSL-connection to the MITM device versus other input
sources, should they be active in the policy.

If users can see they are using a more trusted environment at home then
at their MITM:ing work place, all the better?

/M

---

From: Martin Millnert <[email-masked]>
Date: Mon, 13 Feb 2012 20:15:39 +0100

> And they aren't all 'spy-on-your-employees'.  For example, companies such as CloudFlare (for whom I work), Incapsula, Torbit, etc., provide various web security and performance-related services by…

Conrad, this seems slightly different than the spy-on-your-employees
case though (close to server rather than client), in that the MITM
web-frontend would just be able to publish the original web site's cert,
or, another cert.  To some degree client's can just consider the MITM
machine to be the actual web server, and the actual web server to be the
web-server backend, right?

All the same the client-facing cert would be the cert observed by the
notaries, for instance.

/M

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Feb 2012 20:21:03 +0100 (MET)

> when they know they are being watched.

MITM proxies are bad in several ways.   Not only that they're trying
to hide (by faking server certs), they also breaking client-cert
authentication, interfere with TLS channel bindings and will
break other approaches that intend to fix the shortcomings of the
Browser's TLS X.509 PKI trust model.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Feb 2012 14:26:37 -0500

> MITM devices?  It seems to me that it will have done plenty of good.

Bluecoat has been selling the boxes for years, they will continue to
sell them. The only difference is that now the enterprise has to
install its own root into all the browsers.

But that means those corporate users are not being informed that the
MITM is taking place. Which means their security expectations are
still being violated.

> devices that users *don't* know about.

I assume that being informed means no more than being told that water
contains chamicals known to the state of California to cause cancer.
So no, I do not consider that an 'informed user'.

> personal use).  Think of people in Iran, Syria, ...

Iran peddles backdoored versions of Word, Windows and such. They are
ahead of you there.

---

From: Benjamin Kreuter <[email-masked]>
Date: Mon, 13 Feb 2012 14:34:16 -0500

On Mon, 13 Feb 2012 13:32:48 -0500

> offered commercially as soon as it became public knowledge that they

Which speaks volumes about the motivation behind those certificates.

> take is to offer their own browser with the capability built in.  It
> is no good jumping up and down saying people should not make such

What we need to do is a build a system that does not make compromises
when it comes to security.  Jumping up and down is not necessary; build
a system where MITM attacks are either infeasible or easily detected.

> done using a separate tool and lock the browser to a specific

We can already do this; just import the MITM root into the target
browser, and if you want to prevent evasion, disable all other CAs.  We
do not currently see such things being done, probably because the
people who want to perform MITM attacks do not want to have to do
anything to the target system that might alert people to the
eavesdropping. Why would they cooperate with a system that informs
users about the eavesdropping, when they already have such an option
available but choose not to use it?

-- Ben

> > Well, it is proof that the theoretical model in which authorized
> > MITM was disallowed was seen as too limiting.
> >
> >> weaknesses, and personally, I do not mind the slightest about
> >> breaking those protocol subverting middle boxes, be it by the use
> >> of TLS channel bindings, or the checking of DANE TLSA records.
> >
> > Pragmatically speaking, if you come up with an architecture that
> > disallows people from doing what they want/need to do, they'll
> > either figure out ways around it or not use that architecture.
> >
> > Regards,
> > -drc
> >

-- 
Benjamin R Kreuter
UVA Computer Science
[email-masked]
KK4FJZ

--

"If large numbers of people are interested in freedom of speech, there
will be freedom of speech, even if the law forbids it; if public
opinion is sluggish, inconvenient minorities will be persecuted, even
if laws exist to protect them." - George Orwell

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Feb 2012 22:20:36 +0200

> available but choose not to use it?

I work for a vendor of such systems. The way our customers use it, is that they generate a CA certificate for their gateway and install the MITM cert in the target browsers.

I believe many of them use Microsoft's tools to automatically install on all Windows machines in the domain, but Mac users, Firefox users, Linux users and smartphone users get the scary screens. That is how our product works, and AFAIK the same is true for products with similar functionality from the likes of Blue Coat and Cisco.

You might want to look at (the now expired) draft-mcgrew-tls-proxy-server-00, which attempts to find a solutions that informs the client and identifies the proxy.

Country-wide surveillence needs other means, and need to get legitimate looking certificates.

Yoav

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 13 Feb 2012 15:08:59 -0800 (Pacific Standard Time)

> that something is wrong with the existing security model.

I completely agree.  The existing security model does not take into account the fact that owners of networks get to impose their own security policies, and aims to do everything it can to prevent useful deployment of interoperable low-security routine key-continuity verification that isn't "pay to play".

> bindings, or the checking of DANE TLSA records.

There are environments in which the data sent off of the network MUST NOT be unknown to the network owner/operator.  This is not by any protocol standards body action, but rather by law or regulation.  It's just like the original order from DARPA Command, that TCP/IP would be used on ARPAnet -- once it comes down, it's too late to argue.  I think law rather trumps our desire to deprive everyone of the capacity to perform MITM.

We can continue to outlaw it, in which case it will continue to exist outside of our sight.  We can continue to do the things we've tried to do before, to break what currently exists and to try to prevent technological subversion in an arms race.  That will only ensure that other standards bodies will step up to fill the void of workable standards for authentication, and ensure that companies will still do anything they can to make a buck and find ways to subvert our in-loco-parentis "you can't do that, it's for your own good" security model.  It's time for us to get over ourselves.

There might be a useful compromise: the built-in/vendor-supplied roots show a blue or a green address bar, and non-vendor-supplied roots show a yellow address bar.  Eventually, this might lead to the partitioning of "vendor-supplied state identity service provider" from "these CAs are known to issue to businesses which must ensure complete knowledge of all incoming and outgoing data, but nevertheless provide a useful service to the browser user", with the latter provided by the vendor but also being shown in yellow within the application.

Or, you know, any certificate that's issued to * or *.tld could just as easily be displayed in yellow.  Nobody considers that it's ultimately the application developers who decide whether to allow and how to present anything we come up with.

I think the existing mandate that everything be authenticated and tunneled end-to-end only hurts the IETF.  We need to develop systems within models that actually work.  I am here as the voice of the user and of the network administrator, the one who needs to be able to trust his hardware and software to do precisely what he expects them to, the one who needs to actually use the services we specify.

-Kyle H

---

From: Chris Palmer <[email-masked]>
Date: Mon, 13 Feb 2012 15:16:11 -0800

On Mon, Feb 13, 2012 at 3:08 PM, Kyle Hamilton <[email-masked]> wrote:

> We can continue to outlaw it, in which case it will continue to exist
> outside of our sight.  We can continue to do the things we've tried to do
> before, to break what currently exists and to try to prevent technological
> subversion in an arms race.  That will only ensure that other standards
> bodies will step up to fill the void of workable standards for
> authentication, and ensure that companies will still do anything they can to
> make a buck and find ways to subvert our in-loco-parentis "you can't do
> that, it's for your own good" security model.  It's time for us to get over
> ourselves.

For network operators wanting to MITM their own client devices, the
solution is simple: install the MITM certificate as a trusted root
certificate at the time the device is provisioned (and/or in later
updates). Windows GPOs, for example.

There is no need for such operators to get or use a *public* authority
for this purpose. Everybody wins; what's the problem?

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 13 Feb 2012 15:18:14 -0800 (Pacific Standard Time)

> Browser's TLS X.509 PKI trust model.

Continuing to do the same thing and expecting different results is one of the definitions of insanity, you know?  Our prohibitions have led to our unenforceable prohibitions being broken.  We MUST stop prohibiting things, and recognize that there are valid use-cases which our narrow-minded interpretations of "Absolute Correctness Or It's Crap" have failed to take into account.

There are more things in Heaven and Earth than are dreamt of in your philosophy, Horatio.  They exist regardless of whether we agree with them.  The least we can do is permit them.

(And, there's another aspect: if we intentionally break all of the software that currently exists, we will have committed the largest technical attack on the international financial and communications infrastructure in history, and we would rightly be branded terrorists.)

-Kyle H

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 13 Feb 2012 15:22:23 -0800 (Pacific Standard Time)

> for this purpose. Everybody wins; what's the problem?

Do you have any idea how hard some software (*cough*Firefox*cough*) currently makes it to provision trust anchors for anything, much less anything resembling this purpose?  Do you have any idea how much it costs to indoctrinate someone into the peculiar worldview where X.509 actually makes sense?

We MUST NOT force network and systems administrators and image builders to fight us and our well-meaning yet ultimately misguided attempts to make the world a better place.

-Kyle H

---

From: Chris Palmer <[email-masked]>
Date: Mon, 13 Feb 2012 15:23:47 -0800

On Mon, Feb 13, 2012 at 3:22 PM, Kyle Hamilton <[email-masked]> wrote:

> Do you have any idea how hard some software (*cough*Firefox*cough*)
> currently makes it to provision trust anchors for anything, much less
> anything resembling this purpose?  Do you have any idea how much it costs to
> indoctrinate someone into the peculiar worldview where X.509 actually makes
> sense?
>
> We MUST NOT force network and systems administrators and image builders to
> fight us and our well-meaning yet ultimately misguided attempts to make the
> world a better place.

Wow. Ok then.

---

From: Martin Millnert <[email-masked]>
Date: Tue, 14 Feb 2012 00:49:55 +0100

> Do you have any idea how hard some software (*cough*Firefox*cough*) currently makes it to provision trust anchors for anything, much less anything resembling this purpose?  Do you have any idea how…

Solutions be plentiful, according to my <5 min evaluation of some search
results.*

/M
* https://duckduckgo.com/?q=firefox+windows+group+policy&kp=-1

---

From: Paul Lambert <[email-masked]>
Date: Mon, 13 Feb 2012 16:06:31 -0800

Kyle,

It's ironic that you're email includes a root certificate 
for "Startcom Class 2" that is not the same as the one 
currently in my browser.  

>There might be a useful compromise: the built-in/vendor-supplied roots
>show a blue or a green address bar, and non-vendor-supplied roots show a
>yellow address bar.  

Bandages on a gushing artery.  More irrelevant information for users to ignore.

>I think the existing mandate that everything be authenticated and
>tunneled end-to-end only hurts the IETF.  We need to develop systems
>within models that actually work.  I am here as the voice of the user
>and of the network administrator, the one who needs to be able to trust
>his hardware and software to do precisely what he expects them to, the
>one who needs to actually use the services we specify.

No. It helps.  Allowing undetectable MiTM is an enormous compromise.  
If corporations or Governments want to monitor traffic - they simply 
need to be the "end" from the user and security perspective.

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Feb 2012 18:28:58 -0600

On Mon, Feb 13, 2012 at 5:08 PM, Kyle Hamilton <[email-masked]> wrote:
> I think the existing mandate that everything be authenticated and tunneled
> end-to-end only hurts the IETF.  We need to develop systems within models

If it's not end-to-end it's hop-by-hop or worse: no security.  So you
think hop-by-hop is better than end-to-end?  Yes, there are systems
where only hop-by-hop security works, but generally we should prefer
end-to-end.  If you have a good argument for !end-to-end I'm all ears.

Perhaps you don't like trusted third parties.  But end-to-end doesn't
imply trusted third parties.  Internet scale security has required
trusted third parties to date, but it's not because of the end-to-end
architecture.  (Or perhaps I completely misunderstood you.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Feb 2012 20:00:19 -0500

Before quoting end to end I strongly suggest that you actually read
the Clark paper because it probably does not say what you think it
does. The argument is actually about complexity and strategies for
addressing it.

The end-to-end security model is bunk when it comes to PKI because the
end points of every communication are either people or corporations
and neither can do big number modular arithmetic without some form of
computer support.

So there will always be at least three hops in your model:

Alice <-> Computer  <-> Computer <-> Bob

This really matters a heck of a lot when you start to consider real
world issues like usability.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 13 Feb 2012 17:44:21 -0800 (Pacific Standard Time)

If I were the voice of the user, I'd be arguing for the right to impose and enforce my own personal security policy, without interference from anyone else's attempts to shovel pay-to-play policies down my throat.  I'd be arguing for the ability to make a choice without having my software libel, slander, or otherwise denigrate the systems that I'm working with.

If I were the voice of the user, I'd be arguing for simplifying the process of getting cryptography to work, without a pay-to-play model.

If I were the voice of the user, I'd be arguing against providing false assurances which aren't backed up by the model.

My examples:  Securities and Exchange Commission-regulated trading networks, which do have to support TLS because it's the major means of being able to provide strong authentication over a VPN.  Insurance companies (a specific one that I'm certain of) who must audit to ensure that regulated financial information is not being illegally distributed outside the network.  Educational institutions (a specific one that I'm certain of) who use it to ensure that protected student information isn't illegally distributed.  And on and on and on.

If I were the voice of the user, I'd be arguing against trying to impose what I can and can't do with my own hardware and software.  I'd be arguing against things which reduce the willingness of systems to communicate -- the decision of whether to accept what's communicated is mine alone.  I have an exclusive right to determine what happens here.  No standards body has a right to tell me what I can't do.  No consortium of people, other than the elected legislative bodies, has any right to do that.

We MUST permit every use of our protocols.  We MUST describe the computational processes and we MUST define the intended semantics, but we MUST NOT try to sabotage anything that the standards' implementors or consumers try to do.  If we do, we're overstepping the bounds of what authority we can legitimately claim as standards designers.

-Kyle H

On Mon, Feb 13, 2012 at 3:22 PM, Adam Back <[email-masked]> wrote:
> If you are the voice of the user, you'd be arguing for freedom from mitm by
> robust protocol design.
>
> Its news to me that there are networks that mandate decryption of any higher
> level comms protocols going over TCP/IP on the network.
>
> Closest you get to that kind of thing is voice telecoms where the crypto is
> hop-by-hop and most likely broken by design ciphers etc but there is no SSL
> mitm of 3g/4g gsm-data etc at least in western countries, nor even
> advertised/admitted anywhere else.
>
> Did you have some other example in mind?
>
> Adam
>
>
> On Mon, Feb 13, 2012 at 03:08:59PM -0800, Kyle Hamilton wrote:
>>
>>
>>
>> I completely agree.  The existing security model does not take into
>> account the fact that owners of networks get to impose their own security
>> policies, and aims to do everything it can to prevent useful deployment of
>> interoperable low-security routine key-continuity verification that isn't
>> "pay to play".
>>
>> There are environments in which the data sent off of the network MUST NOT
>> be unknown to the network owner/operator.  This is not by any protocol
>> standards body action, but rather by law or regulation.  It's just like the
>> original order from DARPA Command, that TCP/IP would be used on ARPAnet --
>> once it comes down, it's too late to argue.  I think law rather trumps our
>> desire to deprive everyone of the capacity to perform MITM.
>>
>> yellow address bar.  Eventually, this might lead to the partitioning of
>> "vendor-supplied state identity service provider" from "these CAs are known
>> to issue to businesses which must ensure complete knowledge of all incoming
>> and outgoing data, but nevertheless provide a useful service to the browser
>> user", with the latter provided by the vendor but also being shown in yellow
>> within the application.
>>
>> Or, you know, any certificate that's issued to * or *.tld could just as
>> easily be displayed in yellow.  Nobody considers that it's ultimately the
>> application developers who decide whether to allow and how to present
>> anything we come up with.
>>
>> that actually work.  I am here as the voice of the user and of the network
>> administrator, the one who needs to be able to trust his hardware and
>> software to do precisely what he expects them to, the one who needs to
>> actually use the services we specify.
>>
>> -Kyle H
>
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Feb 2012 13:18:26 -0600

> The end-to-end security model is bunk when it comes to PKI because the

The end-to-end model is broken whenever authentication is mediated by
third parties that can MITM you or worse.  This applies to PKI and
Kerberos, for example.

But the end-to-end model isn't entirely broken as a result.

There's a pretty decent analogy to be made between off-line human
behavior and on-line security protocols as far as trust establishment
goes.  Namely: we depend on repeatability of results for judging
trustworthiness (and much else besides), and in the absence of long
shared history with our peers we do tend to depend on transitivity for
trust to bootstrap new pair-wise trusts.  There are lots of times in
the off-line world when impersonation can occur, but we act as though
the risk of compromise goes down as we repeat experiences.  Even
beyond impersonation, trust between individuals grows over time as
they show each other that they are trustworthy.  But what is the
on-line equivalent of this?  I'd say that something roughly along the
lines of cert pinning is one equivalent: "gee, servers with this cert
haven't stolen all my money yet, and it's been three years, so, yeah,
I trust this cert".  <hand-waving topic="rollover issues"/>

Grant me this analogy for the sake of this argument.

We can use trusted third parties to bootstrap pair-wise trusts and use
those pair-wise trusts to get end-to-end security, meaning, really:
establish pair-wise secret session keys that others don't get to
discover, including the trusted third parties unless they're willing
to MITM or collude with the peer for a very long time.  If a trusted
third party has to be an MITM for years to avoid discovery, they won't
be an MITM at all because that's just too difficult to pull off
(unless the users are an extremely captive audience).

In other words: I'm arguing that while it's true that trusted third
parties weaken the end-to-end security model, they don't fundamentally
prevent the end-to-end model from being faithfully applied, they just
add considerations, caveats, difficulties, but not insurmountable
ones.

> Alice <-> Computer  <-> Computer <-> Bob

Sure.  We make some simplifying assumptions because humans are
insufficiently fast computers.  Our devices speak for us, else we'd
not need those devices in the first place.

> world issues like usability.

Definitely.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Feb 2012 23:55:48 +0100 (MET)

Kyle Hamilton wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >
> account the fact that owners of networks get to impose their own
> security policies, and aims to do everything it can to prevent useful
> deployment of interoperable low-security routine key-continuity
> verification that isn't "pay to play".
> 
> standards body action, but rather by law or regulation.  It's just like
> the original order from DARPA Command, that TCP/IP would be used on ARPAnet
> -- once it comes down, it's too late to argue.  I think law rather trumps
> our desire to deprive everyone of the capacity to perform MITM.
> 
> outside of our sight.

There are two solutions for this type of "usage".

- Provide terminal servers that you monitor, to which your users have
  to dial-in when they want to connect to the outside.

- set up IPsec on your network and disallow the use of TLS on your
  internal network (require them to use an application gateway
  similar to a HTTP CONNECT proxy)

TLS was not designed to provide wiretapping

   http://tools.ietf.org/html/rfc2804

What is currently exploited is a serious flaw in the security of
the trust model used by TLS.  And it can be abused by evil just as
easily, see the DigiNotar hack and for what it was used.

Keeping rfc2804 in mind, when fixing the weaknesses in the trust model
of TLS, maintaining wiretapping capabilities is *NOT* appropriate.

-Martin

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 14 Feb 2012 18:28:03 -0800 (Pacific Standard Time)

On Tue, Feb 14, 2012 at 4:14 PM, Stephen Farrell <[email-masked]> wrote:
>
> So we don't have a moderator/chair for this list for now
> so I'll have to do for the moment...
>
>
> On 02/14/2012 11:54 PM, Kyle Hamilton wrote:
>>
>> Your prejudices and preconceptions are, indeed, the root cause of the
>> problem ...

> The above is ad-hominem and is not suitable for an IETF list
> of any sort.
>
> It may have been accidental of course, but does give the wrong
> impression.

My apologies, I meant "These", in the sense of "these prejudices and preconceptions which you (and everyone else) hold".  I did not intend it as an attack or insult at all, and I am sorry that it came across as such.  I shall watch my words more carefully.

-Kyle H

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 14 Feb 2012 18:28:03 -0800 (Pacific Standard Time)

>   http://tools.ietf.org/html/rfc2804

TLS was designed to prevent undetectable wiretapping.  It wasn't designed to prevent wiretapping in and of itself by one of the endpoints.  And it is entirely legitimate for a company to install keyloggers and screen recorders on their computers as long as they get employee signatures that they have been informed of such.  (I worked somewhere that did this, a large life insurance company.)

Regardless of whether it was designed to permit one thing or the other, the fact is that it is being used such.  We can't rely on standards of intentional purity, we have to engineer something that works.  (If it doesn't work, we're not engineers, we're "money sinks".)

> easily, see the DigiNotar hack and for what it was used.

What was exploited is a serious flaw, yes.  And authoritative CA issued certificates will always be high-value items.  However, I don't really think the flaw is in the trust model "used by TLS".

The flaw is in the trust model implemented by the browsers which (taking its cue from this insistence on a binary "Correct" or "Crap") categorically cannot acknowledge different authorities for different tasks, instead forcing everything into a very simplistic "does it verify to our trust store?  Keep the UI uncluttered, if it verifies to the trust store it's okay for everything".

Put another way, X.509 itself says that the privilege management infrustructure will almost always be completely separate from the certification infrastructure.  Why are we using "the simple existence of a chain which goes up to one of the many authorities we accept" as the marker for an error-free UI?

> of TLS, maintaining wiretapping capabilities is *NOT* appropriate.

I think it's incredibly naive to adhere to the directions and demands of a document created on the cusp of a technology which suddenly had a much broader potential than had ever been considered before.  We've got the Law of Deployment Inertia against us: if we try to create something which breaks compatibility with existing systems, nobody will upgrade.

I'm all for idealism -- believe me, I am an idealist of the highest order.  My main ideal: we must be able to communicate freely, without interference or unacknowledged eavesdropping.  We've had a lot of experiences in the intervening 15 years, and we should learn from them.  We should probably also avoid that definition of insanity, "doing the same thing and expecting a different result".
 
We can continue the slippery slope toward a state-mandated fully-tagged and fully-state-identified communications regime by continuing to specify Absolute Correctness. (Law is the only actual mandate, so the only place to mandate any particular version of Correctness exists in the legislature).  Alternatively, we can do what we're supposed to be doing, which is authenticate the public key used by the endpoint and authenticate the signatures on the certificate chain(s) which terminate there, and somehow communicate that to the user so that someone who's under attack has a fighting chance to realize it.

The person who is under attack's only tool to help in that defense is his computer.  Is it appropriate for the IETF to limit the applicability of its protocols, and snub any implementor who exists in a world that we can't imagine?

We aren't states.  We aren't lawmakers.  We aren't regulators.  We aren't enforcers.  (...unless employed by or as such.)  Your idea of "where the limit should be" doesn't change the fact that there will always exist legitimate reasons to venture beyond it.  We must acknowledge that, and find a compromise which acknowledges that people simply will be presented with trustworthy authoritative CAs, untrustworthy pseudo-CAs, and trustworthy axiomatic bindings, and all categories will be be commonplace events.  Not acknowledging it only means that when these inevitable cases happen, our users and implementors are left without guidance and without compatibility.

I have no problems at all with the output of the current authoritative CAs.  I only have a problem with how that output is interpreted and applied.  Getting a certificate from a CA (which, by the way, makes it rather difficult to say "I'm trying out this technology, this signature doesn't mean anything") should not be prerequisite, or else the security capabilities will not be used.  Nobody knows the value of encryption, because we've made it something they can't use.

All we (as users) really need is to know is when we do or don't have a trustworthy authoritative signature chain.  We still derive benefit from opportunistic encryption; it prevents wide-scale trawling, forcing resources to be spent on targeted attacks.

How and why is the lack of a trustworthy signature chain more alarming than the lack of encryption or authentication at all?  At the very least, a key expresses a useful identity: "if it's verifiable with the same public key, it was signed by the holder of the same private key".  Key continuity is the approach that the One Laptop Per Child project used.

-Kyle H

---

From: Paul Lambert <[email-masked]>
Date: Tue, 14 Feb 2012 19:04:09 -0800

I notice you're still attaching a root certificate of unknown quality as part of your signature.  Since it is different than my current class 2 root for the same named authority it may or may not be valid.  If I accept your certificate and root I'm potentially at risk that you will later maliciously create MITM certs.  I could work harder to validate the certificate constraints or attributes ... but even as a supposed expert, trying to figure out the lineage and veractiy of a new certificate is a pain.  

My point here is not to berate your signature, but to try and refocus some discuss away from your pronounced requirement of allowing "approved MITMs" and find at least one thing in your thread that I agree with.

Ah ... here it is ...

>The flaw is in the trust model implemented by the browsers which (taking
>its cue from this insistence on a binary "Correct" or "Crap")

No ... binary can be ok ... here it really is ...
>categorically cannot acknowledge different authorities for different
>tasks, 

Ok. This is interesting topic.  If I accept a random certificate it should 
be able to be constrained by the user/admin to a specific range of usage.
For TLS and classic PKI, this would be a range of DNS names.

Right now, all the root certs in my store can create certificates in
most any range.  A fundamental principle we need to consider is local
end-point constraint of trust.

If I could do this - then the random root cert that I accept for 
your signature could be locally constrained to be just for you or
a small domain range (e.g. an enterprise)

>instead forcing everything into a very simplistic "does it verify
>to our trust store?  Keep the UI uncluttered, if it verifies to the
>trust store it's okay for everything".
>
>Put another way, X.509 itself says that the privilege management
>infrustructure will almost always be completely separate from the
>certification infrastructure.  Why are we using "the simple existence of
>a chain which goes up to one of the many authorities we accept" as the
>marker for an error-free UI?
>

Yes!  Excellent rfc2804 statement/position and a good foundation 
to not design in MITMs. 

>I think it's incredibly naive to adhere to the directions and demands of
>a document created on the cusp of a technology which suddenly had a much
>broader potential than had ever been considered before.  We've got the
>Law of Deployment Inertia against us: if we try to create something
>which breaks compatibility with existing systems, nobody will upgrade.

Huh?  MITMs are bad as a design requirement.  They are easy to create
if you want - go ahead, but not as a core architectural principle.

Paul

---

From: Carl Wallace <[email-masked]>
Date: Tue, 14 Feb 2012 22:15:49 -0500

On 2/14/12 10:04 PM, "Paul Lambert" <[email-masked]> wrote:

><snip>

Yep.  There are specs that enable this (RFCs 5914 and 5937) but they are
not in wide use.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 14 Feb 2012 22:09:25 -0800 (Pacific Standard Time)

> I notice you're still attaching a root certificate of unknown quality as part of your signature.  Since it is different than my current class 2 root for the same named authority it may or may not b…

Pedantically, as I mentioned, it's not a root.  S/MIME specifies that every CA in the chain except the root be included.

I must ruefully note: the fact your software doesn't handle "standard" X.509 semantics says that the implementors of our standards aren't getting it right, either.  What's wrong here?

> My point here is not to berate your signature, but to try and refocus some discuss away from your pronounced requirement of allowing "approved MITMs" and find at least one thing in your thread that…

I used to be a crypto pure idealist, believing that it could solve all disputes.  Then the real world (literally!) shot me in the back.

Now, I'm a crypto pragmatic idealist.  The world has evolved the way it has simply because it has.  We have to fit into this world, and it would help a lot if we didn't try to supplant the courts.

Don't let the ideal become the enemy of the acceptance of management of all uses of our standards.

> No ... binary can be ok ... here it really is ...

It can be okay, in very simple environments.  Implementation is never that simple.  Every decision is an analog process informed at best by multiple binary inputs and at worst with corrupted-but-apparently-legitimate inputs.  (If you're crossing the street, you look both directions to obtain the binary "is a car coming from the direction I'm looking" twice, and decide based on both answers and whether there's a pedestrian island in the middle whether to go.)

My goal: Get every message on the Internet encrypted by December 2017.  I know it's unattainable, but it's what I'm shooting for.

> For TLS and classic PKI, this would be a range of DNS names.

I agree: I, as my own policy-creating principal, should be permitted to be able to whimsically disregard any statement which I don't believe is legitimate.  (This happens in such cases as the Chinese Government CA.)

See, DNS names are held by an Authority (ICANN, created and explicitly chartered by US federal law).  Individual names are held by the public registry of birth and death (another Authority), and corporate names are held by the Secretaries of State of the various jurisdictions (also an Authority).  Each of these is useful in a different context and for a different purpose.  Trademarks and patents and copyrights are also held and registered by Authority, and are as much property as a phone or vehicle or self-label is.  Why can't I have a certificate chain on the implementations I purchase licenses to which state that a given patent is officially licensed?  Oh, that's right, because not every authoritative registration is important enough to be certifiable.

The CAs we're trusting are trusted to only supply information about the keyholder which the keyholder can legitimately claim to own via a register maintained by Authority.  (While you don't necessarily own your own name, you can decide what you're named.)

Names are labels for people.  Public keys are labels for their private keys, which are known or available only to their holders.  Private key holders are people (or hardware employed by people).  So, I'm going to go out on a limb and suggest that "public keys can be considered to be labels for people", which reduces to "public keys can be considered to be names".

One has the right to choose what identities he puts forth in any environment, and he owns the reputation he's built up over time under those identities.  This is why things like identity theft (impersonation fraud) are bad, they rob people of the time they invested.  However, he does not have the right for others not to ask about him.  Any identity's reputation can be checked instantly once that identity is known, subject only to limits placed by law on financial, health, and false disclosures.  (libel and slander laws)

Also, there are legitimate reasons for one person to have many identities.  They're like "doing business as" (or d/b/a) labels, the same way that corporations have many brand identities and lines of business.  The thing is, these exist independent of any CA's recognition.  Any time we try to place a limit against behavior that legitimately occurs in the wild, we're engaging in an activity which is reserved for legislators alone.

Why doesn't the software in the world today provide this capacity?  Oh, that's right, it's because it's an all-or-nothing atomic structure, you either accept all of it /and every semantic that the absolute implicit trust implies/ or you accept none of it.

> end-point constraint of trust.

The fundamental principle we need to consider, from which derives your principle, is "the owner of the machine is for all practical purposes a minor deity in a world of natural and corporate minor deities."  A natural person and a corporate body are both bodies, and a natural person has as much need for and right to control over his own world as a corporation has for its.  Both of these types of minor deities can be held accountable by the greater deities (the things we call 'states').

I can't hold you accountable.  I can ask the state to hold you accountable, but I cannot directly violate any right of yours.  If I do, you can ask the state to hold me accountable.  Even if I'm hired by the state and have some measure of authority to my work, I also cannot simply barge in and violate your rights.  For our purposes, you are a soveregn, a law-making authority over your own affairs, and I have no jurisdiction there.  IETF has no jurisdiction there.  You can violate rfc2804 all you like, and I can't hold you accountable.  I can violate it all I like, and you can't hold me accountable.  Third parties can (and do!) violate it, and we can't hold them accountable.

The only thing we can do is create a new class of certificates: from entities untrusted to provide authoritative identity information but otherwise trustworthy for some local policy.  (And to prevent this happening in the future, we should create guidance for what to do when a chain from an unknown certifier is encountered.)

> a small domain range (e.g. an enterprise)

I wholeheartedly agree.  Why doesn't software allow for it?  Oh, right, because everything is binary in the software and there's no way to patch all of the binary decisions together because every decision is one decision.

> Yes!  Excellent rfc2804 statement/position and a good foundation

The problem is, IETF cannot afford the psychosis of unacknowledged reality.  It will happen no matter what we do, write, or say.  There do exist (contrary to popular belief) good reasons for it happening.  People will always demand the capacity, no matter what we think should be right or legitimate or legal, because our attempt to mandate it is not legal or legitimate or right.

> if you want - go ahead, but not as a core architectural principle.

Perhaps I'm taking too much from the "harm reduction" lobby, but... if we don't plan for them, they're simply going to do another end run around the end-to-end guarantees we try to make in this effort.  We will have as little control over the process at that time as we do now.  Outlawing them will only continue the arms race.

Perhaps I can draw an analogy: If you hired someone to figure out how to reduce the damage in accidents done on your city streets, and that someone came back with a recommendation "ban automobiles on the streets", you wouldn't be happy.  If he came back with "everyone must drive a 1912 Ford Model T", you wouldn't be happy.  Perhaps one might be happy if he came back with "everyone must drive a 1950s-era muscle car," but that would be counterproductive.  That's pretty much what the Internet has done with us, and what we've to this point given them.

If we allow for it with clear user-interface gudelines, we make it less desirable for the actual owners to spend the time recompiling their software to make their own roots appear green or blue.  (In fact, right now, they always appear blue the same way that DV/OV certificates do, which is the prime reason it does violate the end-to-end guarantee.)  If we allow for them, we diminish the returns available to the owners in doing such.  All we need is for us to implement our software so that it won't throw a hissy fit if it's presented with something from one of these sub-trustworthy authorities, and all that relies on is clear guidance (in the same manner as the CA/Browser Forum's EV green bar guidance) for what to do when something our narrow minds can't conceive is correct.

Really, who is the IETF to tell any user or implementor what he can or can't do?  The sheer conceit is appalling.

-Kyle H

---

From: Paul Lambert <[email-masked]>
Date: Wed, 15 Feb 2012 12:28:09 -0800

>Yep.  There are specs that enable this (RFCs 5914 and 5937) but they are

Thanks. Appreciate the pointers.  Providing an explicit limitation of trust
is an important design requirement.  A well thought out design, but the
complexity may be limiting adoption.  Then again - the complexity
is a function of the core 509 framework ... if trust expressions
were easier to express would there be better adoption and more
trustworthy implementations?

Paul

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Feb 2012 05:47:08 +0100 (MET)

Paul Lambert wrote:
> 
> I notice you're still attaching a root certificate of unknown
> quality as part of your signature.  Since it is different than my
> current class 2 root for the same named authority it may or may
> not be valid.  If I accept your certificate and root I'm potentially
> at risk that you will later maliciously create MITM certs.

Why do you care about the CA cert that signed Kyle's cert AT ALL?
If you don't recognize that CA cert, they you should continue to completely
ignore that CA cert.  If your MUA does not let you pin Kyle's cert
alone (for the purpose of verifying the signaturs on Kyles Emails),
but requires you to add cert of _his_ certifcation chain to add to
your trust anchors as a prerequisite for S/Mime signature verification,
then the PKI software used by your MUA is seriously broken.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Feb 2012 06:24:23 +0100 (MET)

Kyle,

Kyle H wrote:
>
> We MUST permit every use of our protocols.  We MUST describe the
> computational processes and we MUST define the intended semantics,
> but we MUST NOT try to sabotage anything that the standards'
> implementors or consumers try to do.  If we do, we're overstepping
> the bounds of what authority we can legitimately claim as standards
> designers.

We seem to be talking about completely different protocols.

*I* am talking about TLS (any version), which has the clearly stated
design goal:

  http://tools.ietf.org/html/rfc2246

   Abstract

   This document specifies Version 1.0 of the Transport Layer Security
   (TLS) protocol. The TLS protocol provides communications privacy over
   the Internet. The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

  http://tools.ietf.org/html/rfc5246

   Abstract

   This document specifies Version 1.2 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol provides communications security
   over the Internet.  The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

What these MITM proxies are doing is _completely_and_thoroughly_
subverting the entire purpose of the TLS protocol.  They're doing
it not by exploiting weaknesses in the TLS protocol itself
(at least prior to rfc5746), but instead, by exploiting a long-standing
fatal design flaw in the security in the existing TLS X.509 PKI trust model.

Those who want a protocol for encrypted communication that can be
arbitrarily MITMed should design themselves such a protocol.
Expecting the IETF to support continued exploitation of a serious
weakness in a security architecture that is the exact opposite of
its stated design goal is inappropriate for the IETF.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 08:01:33 -0500

The purpose of the IETF is to support USERS

USERS !

Not designers.

So the stated design goals have to be taken with a pinch of salt. They
are almost always wrong. Presenting them as immutable statements of
permanent truth is bogus.

TLS and SSH are the only IETF security protocols thus far that have
not turned out to be technical triumphs but deployment failures. It is
really easy for someone to push for a technical perfection that makes
the protocol undeployable or unusable.

Here we are all agreed that it is generally a bad thing for there to
be this particular hole. That is not the issue. The issue is whether
ignoring the fact that there are regulatory requirements for this
capability and not supporting them results in a better or a worse
outcome for users.

So far the evidence suggests that refusal to consider them has
resulted in a worse outcome.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 16 Feb 2012 10:06:37 -0500

> its stated design goal is inappropriate for the IETF.

I think it's important to remember that whatever the TLS, DANE, and
any other working groups come up with - there will be an army of
people waiting to break the very first implementation, and they will
do so.  I will be one of them.

No matter what Firefox and this working group come up with, I will
break it locally, so I have a non-nagging TLS MITM.  Even if I have to
go in and modify the browser source code itself.

Why? Because I test web apps!  I need a MITM tool like Burp,
Fiddler[0], or Mallory[1] to let me modify the traffic after it leaves
the browser, before it leaves the machine, so I can test the inputs
(form fields, headers, methods, and whatever else) the server accepts.
 That simple, that benign, that necessary, and yet entirely able to be
re-purposed for evil.

> resulted in a worse outcome.

I agree, but I don't really understand why everyone's arguing.  It all
seems to be tangent to the purpose of all the working groups I've
seen, because ultimately, it's left at the discretion of the
implementations.

A:"We shouldn't enable MITM under any circumstances!"  B:"Okay, do you
want to outlaw local trust databases?" A:"No, that's implementation
details."  B:"Yea but.... that's how MITM works."
or
A:"We shouldn't talk about MITM in the protocol!" B:"Okay, but people
are going to do it. Maybe we should have guidelines so users are
notified?" A:"No!" C:"Isn't that up to the browser?" B:"Oh, yea."

The only argument I could see worth debating is somehow _enabling_
MITM in the TLS protocol *itself*.  And not only do I think that's a
huuuge change, super-dangerous, I also think it's entirely
unnecessary, because we already have a viable, working MITM solution:
local trust stores.

It seems to be a simple question: Will whatever "CA
Solution/Improvement" we come up be expected to override local,
user-set (or corporate IT-set) policy?  If no, MITM will work - don't
worry about it.  If so, how do you expect to accomplish that, when I
control everything on my machine?[2]

-tom

[0] Burp and Fiddler are proxies designed for fiddling with HTTP
requests and responses
[1] Mallory is designed to muck about with raw TCP packets
[2] It *is* worth noting that the local policy engine/mechanism then
becomes ripe for attack, and instead of compromising CAs, we'll see
attacks that exploit bugs in it.  But, we can deal with that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 11:18:09 -0500

All that I have seen proposed in this regard is to have a draft that states:

1) This is a really bad idea in general
2) If you really have to do it then do it this way
2a) It is turned off by default
2b) It only permits the authorized MITM to intercept
2c) The user is repeatedly warned that MITM is taking place
2d) There is no way that any credentials or infrastructure created for
authorized intercept can be used to support unauthorized intercept

I would rather have a defined path for this than to see another
iteration where the primary goal is to minimize the effort required
for the IT staff deploying the system.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Feb 2012 13:17:02 -0500

> authorized intercept can be used to support unauthorized intercept

eh?  it seems you're proposing a new mechanism, when Tom just pointed
out that the existing mechanism (endpoint-controlled trust policy)
already works for nearly every case.  (the exceptions being client-side
certs, and the hassle for IT staff of having to configure trust stores
on each client)

> for the IT staff deploying the system.

IT staff already have a simple way to do this: embed a MITM-enabling
root authority (or comparable mechanism) in the client's trust policy.

Who exactly is trying to "minimize the effort required for the IT staff"
to deploy a MITM?

I can't believe that on a list titled "the right key" the majority of
the debate seems to be around whether we want a spec that enables
transparent MITMing or a spec that enables user-visible MITMing.  Which
part of "the right key" does any sort of MITM fit into?

The main argument seems to be "people need to do this for legal reasons"
-- well, ok, let's have someone with a legal requirement for
eavesdropping/monitoring step forward and propose an external,
session-key-sharing mechanism that is *separate* from TLS.  Then IT
staff can deploy such a system on the clients they're required to monitor.

If someone has a legal requirement to not only snoop but to alter
traffic in flight beyond just terminating a session (i find this
implausible, but what do i know), this can also be proposed as a
separate mechanism, outside of TLS, or as a TLS extension.  I don't see
how it's appropriate for this list, though.

Can we get back to discussing how to get the actual "right key" for the
network peer?

	--dkg

---

From: Paul Lambert <[email-masked]>
Date: Thu, 16 Feb 2012 10:22:23 -0800

>then the PKI software used by your MUA is seriously broken.

The user interface on my MUA (designed by one of the world's largest software companies) is unable to indicate to me what I should do with the two certificates in a clear manner.  On importing the first certificate - it indicates that it will be used for both e-mail and internet.  Hence my prior complaint about possible vulnerabilities with cert acceptance.  

  Info on the cert from MS Outlook MUA
	Protects e-mail messages
	Ensures software came from software publisher
	Protects software from alteration after publication
	Allows data to be signed with the current time
	Allows data on disk to be encrypted
	Allows secure communication on the Internet    <----- my issue in prior thread

Deep in the MS controls I can finally find check boxes to turn off everything but the email.  I doubt that any but the most rabid security geek would bother.  Even then, it's very difficult to maintain the large number of certs.  The relationships and associated privileges are difficult to view review for security.

With effort I could make this work ... the security and usability are of dubious quality without very careful configuration.

Also - cleaning up after my experiment, I disable both certs in the path for the user cert, and the UI tells me the terminal cert is still valid!  WE seem to have a mixture of bad implementations - and technologies that are too complicated in their details to make them easy to use.  

Finally - there are no user centric constraints.  The newly accepted cert can issue for any email or dns address.  I can not place any limitations on the new cert.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 13:41:56 -0500

> root authority (or comparable mechanism) in the client's trust policy.

It is a solution to the IT depts problem but there isn't transparency
for the user. The user is not told that they are being MITM'd.

Further, if DANE was deployed or any of the proposals made here was
deployed they would stop the MITM enabling root authority from
working. So we are proposing to break the escape hole you are
proposing they use.

Now breaking that escape hole might be a good thing. But we should
certainly think about the consequences and it should be a deliberate
decision to break it and not provide an alternative.

> Who exactly is trying to "minimize the effort required for the IT staff"

BlueCoat did.

> part of "the right key" does any sort of MITM fit into?

One of the requirements that drives this work is that people did this
in the past and did it in a very bad way. So we need to either tell
them not to do it again or work out a safe way for them to do it.

> staff can deploy such a system on the clients they're required to monitor.

And how does that work?

Saying that 'it should be separate' does not absolve you from
proposing how it would work. If you are putting a proposal on the
table then it needs to be either 'don't do it at all' or 'this is how
to do it', I can't see how 'let someone else do it' helps us.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 16 Feb 2012 14:24:48 -0500

> decision to break it and not provide an alternative.

We just had this same discussion on DANE:
http://www.ietf.org/mail-archive/web/dane/current/msg04306.html I
raised the same point about local policy enabling an override, and the
consensus seemed to be: "That's a good point, and mandating what
clients do is not the spec's problem. Let's propose good solutions for
browsers offline/out of the WG."

A nice side effect was that a locally configured trust anchor
overriding a TLSA enables valid corporate MITM, while a
non-transparent, shady-trustwave-style-subca would not be overridden
by local policy, and the TLSA would cause a hard fail.

I'd also like to go on the record that I think a visual indicator to
the user that shows a cert is valid only under local policy is a
fantastic idea and I support it wholeheartedly.  Of course UI is hard,
especially with this opaque a topic to an average user, but I still
think giving it a shot is a good idea.

-tom

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Feb 2012 14:57:17 -0500

On 02/16/2012 01:41 PM, Phillip Hallam-Baker wrote:
> On Thu, Feb 16, 2012 at 1:17 PM, Daniel Kahn Gillmor <[email-masked]> wrote:

I'm not about to spend my own time writing this up, since i agree with
you that doing an MITM is a bad idea in general.  But the concept of
sharing the session keys of a TLS connection with a third party so they
can listen in isn't some genius feat of invention, and someone
sufficiently motivated to do so could write up such a spec.

But that's not to say that it's in-scope for discussion on this list.

We could also discuss ways that TLS hurts the environment by being
overly wasteful of CPU cycles (and how to improve things there).  That
might also be an interesting discussion, but it isn't germane to finding
"the right key", so it doesn't belong on this list.

Regards,

	--dkg

---

From: Paul Lambert <[email-masked]>
Date: Thu, 16 Feb 2012 13:29:00 -0800

>think giving it a shot is a good idea.

A similar usage of colors - with poor results:
http://www.usablesecurity.org/papers/jackson.pdf 

Is local policy more or less secure to the user?  I'd say more ...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 16:50:29 -0500

I don't trust the results of lab usability studies.

One of the big problems is that a subject comes into a lab expecting
to see stuff that is flaky. So they are primed to ignore warnings.

Another side of this is that usability methodology has been developed
to sell stuff. That is why the priority for Apple was to get the user
comfortable in 15 mins. That is a typical length for a sales pitch.
The whole usability world has evolved around the first impression of
the user and not the long term response.

But the academics are really happy with a paradigm that allows them to
get papers published on the basis of cheap, easy to run studies.

I agree that a security signal needs to be much more than a different
address bar color. I would take over the whole browser window for a
transitional.