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

["Kyle Hamilton" <[e-mail]>]

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 <[e-mail]> 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:
>>
>>
>>
>> On Mon, Feb 13, 2012 at 8:36 AM, Martin Rex <[e-mail]> wrote:
>>>
>>> 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 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".
>>
>>> 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.
>>
>>
>> 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
>
>
>
>
>> _______________________________________________
>> therightkey mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/therightkey
>
>