Re: [Patient] [EXT] Re: [saag] Internet Draft posted as requested -

[Brian Witten <[e-mail]>]

Hi Paul,

Thanks Again.

Re, "...NOT be in the possession of any private key material that will allow it to impersonate the client identity to a remove (sic, remote) server," I believe this could be achieved through "mutual authentication leveraging client-side certs," where the client-side certs are provisioned either through in-factory credential-provisioning, which is quite common in IOT today, or through some other provisioning mechanism, such as Enterprise PKI or how some banks do "out-of-band" (OOB) credential provisioning to client devices.  Of course, the keys & roots need to be set up properly so that the server can verify the client-side credentials and the Protection Service can't forge such credentials, but that's straight forward.  That would seem to prevent impersonation.  Also, the client could then also it use it's Private Key to sign anything it sends back to the server, "akin to Stickler, but providing end2end integrity protection from the client back to the server."  Please LMK if you disagree?

Either Way, Thank You Again!

Brian

   



From: saag <[e-mail]> on behalf of Paul Wouters <[e-mail]>
Sent: Monday, December 18, 2017 11:15 AM
To: Stephen Farrell
Cc: [e-mail]; [e-mail]
Subject: [EXT] Re: [saag] [Patient] Internet Draft posted as requested -
  

On Mon, 18 Dec 2017, Stephen Farrell wrote:

> If the proponents of these mitm schemes honestly and openly
> faced up to such issues and argued for another decades-long
> arms-race and acknowledged the downsides (e.g. assisting
> censorship, breaking all sorts of application assumptions,
> and enabling pervasive monitoring) of mitm'ing https and/or
> tls then that at least would be credible. It'd still be a bad
> plan, but at least one for which we could discuss the technical
> (de)merits and not have to deal with the nonsense claims such
> at the one we both noted above.

If we did an use-cases document for this, to seperate the technical
aspects from the business aspects, the first item I would insist on
would be:

- Protection service MUST NOT be in the possession of any private
   key material that will allow it to impersonate the client identity
   to a remove server. If a client wants to delegate this responsibility,
   it MUST be able to communicate this to the server and the server MUST
   be able to deny such a request (upon which the client may decide to
   close the connection)

The problem here is that providers of these services don't want to double
the traffic load where the client decrypts then forwards for blessing.
But simply insisting that decryption has to move to the network service
isn't going to work.

Another way to accomplish this would be to have signed web pages,
so clients could send hashes for verification. But in today's dynamic
web that is also pretty problematic and would require major changes.
Of course it has the benefit of the provider not even being able to
read the users content.

The IETF discussion should not center around the business model, but
should center around designing (or not) a useful new protocol or
existing protocol modification that addresses a well defined issue.
Instead, I hear about desires and potential business models and how
some of our new technology has affected existing business models.

I also detect a culture clash where I see a lot of praise to proponents
and opponents without technical backing. At the IETF, we try to
reach consensus based on technical merit, for example by stating you
agree or disagree with certain items and why, and don't do "me too"
messages to get a count.

Paul

_______________________________________________
saag mailing list
[e-mail]
https://clicktime.symantec.com/a/1/fiazdLFK3QUq7FT-i8r9StLrGbk9GfOa_1goF9ohiHM=?d=pDpEfizpaOoyRJu2SzY3dci6RLYb38UoHcO56rWd_Waa-XH4XaU_PbZEq2F_Ots1eFq9hFcrLyPIEy48XVNkNuVNaOs-hoRY9sYCvwwTKpc4f-YKEqzZth1bnGLIzloRCg-0QnQdNv56mIQtGktlHz8TajPdmMikqWjbs6jf4VPYjcczDAj9jNyaxcx2IKQYHLloy8tT3EpQiziv7EBh2XdL0QhQnkkhSzCFPg_DkAVAp0nHRv2IKkK8evQNjlGIG5n4l5H7ZK-c5O7bxd8T5NvfXPwX_fA1aXxbKcyxcBBCAsuxquW-NErNyP3CsvoqB9y33t-tWDXxs9RHYaIEEdCZpVKVj6nws46A-ieYJWuMViPN3fvhBKGW1VS3xyIUDcLeTBbhiy_-WdDGzGvoxW-BueESNFM%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsaag