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

Attachment: Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey

Reply via email to