Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Marsh Ray <[e-mail]>]

On 08/18/2010 03:42 AM, Adam Barth wrote:
>
> I think your confusion might be stemming from confusing me with Adam
> Langley.  Although we're both named Adam, we're are, in fact,
> different people with different interests.

My memory is unpredictable sometimes, but how could I forget Adam Barth?

You sat directly to my right on Sept 29, 2009 at that meeting in
Mountain View. You wore, I believe, a white tshirt with colored trim.
Possibly denim shorts and flip-flops? Unshaven. Pretty much the opposite 
of your current Twitter icon! You had a small white Mac. I wondered if 
you really did all your document reading and writing on that thing. I 
wasn't watching what you were typing, but I did notice you were IM-ing a 
bunch.

Adam Langley, however, I don't recall ever having met in person.

---------

Forgive me for chopping up the thread, I think we're getting to the 
substance of the issue:

About the non-normative text it appears that "the motivation in the 
draft is outdated". So this review will have to disregard it.

 > To solve a particular design problem, one IETF working group
 > is considering a design that makes use of technology designed by
 > another IETF working group.  It seems quite appropriate for that
 > working group to ask for advice from the experts in the other working
 > group.

But there's nothing in draft-agl-tls-nextprotoneg-00 about that. If it 
really is building on another WG's work I'd expect a stable normative 
reference and a mapping relating the definitions in that standard to the 
new protocol elements.

Try this: Find someone who's technical, but not involved WebSockets, to 
read the I-D. Then ask them to explain it back to you.

For an I-D describing an extension to TLS, I'd expect it would include 
enough details that a person "skilled in the art" could implement it 
correctly and make testable predictions about the behavior of the 
resulting system. Probably it should even do something demonstrably 
useful to someone.

Yet, on the face of it, this I-D is completely meaningless. It proposes 
a new TLS extension with absolutely no defined semantics. It amounts to 
an empty Client Hello extension, a Server Hello extension containing 
unbounded arbitrary data, and a new handshake message containing up to 
512 bytes such that "The format of this data is not specified in this 
draft".

Allowing big quantities of arbitrary data immediately before the 
Finished message concerns me from a cryptographic perspective. It also 
seems like simple implementation errors could permit attacks where an 
endpoint confuses the new message with a Finished message, or vice-versa.

Other proposals have suggested sending opaque data in one direction or 
another and were not accepted, largely on the grounds that permitting 
non-semantic data in the handshake (data that the TLS RFCs were 
prohibited from interpreting) could only lead to interoperability issues 
(or even de facto usurpation of the protocol by entities outside the 
IETF processes). I realize that that is absolutely not the intent here.

In the opinion of this reviewer, draft-agl-tls-nextprotoneg-00 needs 
substantial rework before it should move ahead in the standardization 
process.

Suggested actions:


1. This appears to be a basic authentication problem. The I-D should 
give a rationale for:

1a. TLS already does strong authentication, and there are plenty of 
other well-understood schemes (from simple to complex). Why are these 
not sufficient?

1b. Couldn't this be done in the app data layer? Is the motivation just 
to save a round trip? Surely plenty of other protocols could shave off a 
round trip with custom TLS extensions, why does this case in particular 
justify it?


2. Decide if it's really (A) specific to WebSockets or it's a (B) 
generally useful mechanism. B is an ambitious project in its own right, 
there's no shame in A.

If A: Get the WebSockets spec solid enough to implement from and serve 
as a stable normative reference.

If B: Define the contents of the fields well enough that they can be 
unambiguously implemented, tested, and interoperate. The protocols being 
authenticated should map to some IANA registry.

- Marsh