On 8/5/2014 9:58 AM, Nico Williams wrote:
On Tue, Aug 5, 2014 at 11:39 AM, Joe Touch <[email protected]> wrote:
On 8/4/2014 9:18 AM, Nico Williams wrote:
On Sun, Aug 03, 2014 at 05:08:50PM -0700, Joe Touch wrote:
...
I think you should let the process continue rather than attempt to shut
this down.
I'm OK with that plan, but not OK with posts that make claims as to how
solutions address the self-contradictory requirements of the charter.
If there's an inconsistency between the charter and the proposals,
then that has to be addressed: that's part of the process. It may
mean updating the charter, updating the proposals, or even concluding
the WG.
I.e., this group cannot have it both ways. If you want to proceed with a
flawed charter, then stop holding it up as the gold standard for solutions.
Your posts have been more of the "this is not good, stop it" vein than
"the proposal is inconsistent with the WG charter [details]". You
can't have it both ways either. Please provide details or stop
distracting.
I did.
To repeat in summary, the charter mandates a TCP solution based on
deployability to address pervasive monitoring. However:
- unauthenticated anything protects against only shared-media
monitoring. the kind of pervasive monitoring I believe motivated
the BCP is at firewalls or routers on-path, and those can
easily act as MITM
so any unauthenticated approach is likely not to suffice to
address the BCP that is the primary motivation of this work
- there is no evidence that a TCP layer solution is easier
to deploy or that a kernel-based solution is easier to deploy,
or that the two are inextricably linked
- there is no reason that a TCP layer solution is appropriate
if we're concerned about monitoring
In fact, the charter starts from a position of wanting to protect
traffic from monitoring, but jumps to the conclusion that a TCP solution
is needed. What fraction of TCP traffic isn't already protected from
monitoring by TLS, and what fraction is TCP of the total traffic
potentially being monitored?
This is a clear case of the streetlight effect.
(http://en.wikipedia.org/wiki/Streetlight_effect)
(BTW, reviewing the charter just now, my only complaint is that
channel binding is not mentioned, but I think it arguably falls under
"hooks for authentication", and anyways, lack of presence in the
charter is not really a problem, since channel binding is a no-brainer
for this protocol.)
Channel binding cannot be added post-facto; hooks for authentication
might not be sufficient for channel binding, and isn't there also a need
for connection latching that isn't addressed at all in the charter?
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
