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

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

On Mon, Feb 13, 2012 at 4:06 PM, Paul Lambert <[email-masked]> wrote:
> 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.

It's ironic that it's not a root, it's an intermediate that chains from Mozilla's Built-In Object Token:StartCom Certification Authority.  If your software doesn't handle it, it's your software's policy implementation that's so well-meaningly invasive and unworkable.

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

Telling people that they are being intercepted and MITM'd is irrelevant information?

If users choose to ignore being given a clear visual indicator that what they're sending to and from a particular site is going to be read by a third party, that's their own problem.  We aren't parents, we don't have guardianship of the users, we can't act in loco parentis just because we think that we know best.  (That's how "dictatorships" start.)

At such time as IETF is chartered with regulation-making authority, I'll quite happily help draw up auditable standards of correctness.  Until then, I'm not going to enable undetectable man in the middle.  I'm instead going to enable detectable and correctly disclosed man in the middle.

It all boils down to, "what do you trust a certifier for?"  Certifiers only exist to facilitate communication of data plus policy associated with the data.  Certifiers do not set policy, they only set the requirements to obtain a certificate from their certifier.  It is application developers which have historically set the policy.  I want to ensure that people who don't pay to play under the CA model (and who have sovereign immunity as far as we're concerned) can actually play around with the technology so that they can see why they would want to pay for the certifications.

The fact that applications make larger statements about untrustworthy certificates than they do about the lack of encryption is completely backwards.

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

I want to allow detected MiTM, as long as the user is told about the detection.  How is this 'undetectable MiTM'?

Your prejudices and preconceptions are, indeed, the root cause of the problem which this mailing list is chartered to solve.  Will you please give them up?  Do you have the capacity to give them up?

-Kyle H

>
> 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: Stephen Farrell <[email-masked]>
Date: Wed, 15 Feb 2012 00:14:30 +0000

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.

Please desist from such behaviour.

It may have been accidental of course, but does give the wrong
impression.

S.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 14 Feb 2012 18:40:53 -0800

>Telling people that they are being intercepted and MITM'd is irrelevant

Changing a color in the UI is unimportant if users cannot trust that this color/indication is correct or if they do not even understand what various shades of untrusted mean.  What point is creating a UI to say you are being MIM'd if most of the time you would not get this indication even when you are MITM'd.  Not all MITM will acknowledge that they are monitoring traffic.  This is what we call an adversarial environment.  If we were all friendly and worthy of trust we would agree to be gentlemen and never intercept traffic.  

Hence the analogy of taking one of those little sticky band-aids to patch a major bleed-out.  Allowing the display of a "approved" MITM disregards the much more serious blood loss of the undetected MITM.

I will concede that you could build such a MITM friendly browser for enterprise or Internet freedom challenged countries. It's short sited though to consider just this one use case.  What about my TLS protected electric meter.  I don't think it understands colors.  What traffic is MITM acceptable and what is not?   Exceptions to end-to-end security are much easier to design and deploy than getting it right for traffic that needs to be protected.  Go ahead and build a MITM friendly system, but we need to solve the more important problem of unrecognized MITMs.

Paul