Re: Towards a new charter for the WebRTC Working Group

> On 10 Jan 2018, at 06:10, Peter Thatcher <pthatcher@google.com> wrote:
> 
> 
> 
> On Sat, Jan 6, 2018 at 6:08 AM westhawk <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
> 
>> On 6 Jan 2018, at 00:57, Peter Thatcher <pthatcher@google.com <mailto:pthatcher@google.com>> wrote:
>> 
>> 
>> 
>> On Tue, Jan 2, 2018 at 3:47 AM T H Panton <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
>> 
>> 
>> > On 2 Jan 2018, at 05:26, Bernard Aboba <Bernard.Aboba@microsoft.com <mailto:Bernard.Aboba@microsoft.com>> wrote:
>> >
>> > Martin said:
>> >
>> > "What are the plans for the protocol pieces for the new items?  I
>> > haven't seen any plans - or internet-drafts - for those, and the bulk
>> > of the work for some of these items is protocol work.  For instance, I
>> > can understand why the group might choose not to rely on SDP for
>> > negotiating new features, which leads to some API work, but the bulk
>> > of the QUIC datachannels work is in defining protocols, not the API."
>> >
>> > [BA] The QUIC API presented at TPAC depends only on currently chartered work in the IETF QUIC WG (e.g. the QUIC transport document) as well as resolution of the QUIC multiplexing problem (by whatever approach the IETF decides on).
>> >
>> > As the QUIC transport document evolves, the QUIC API will presumably evolve as well (e.g. the proposed API currently provides a bi-directional stream abstraction).
>> >
>> > As Peter noted, it should be possible to implement the RTCDataChannel API on top of the proposed QUIC API once the IETF defines the protocol for QUIC datachannels.
>> >
>> 
>> I don't think I've seen the requirements/use-case doc for QUIC - or indeed any discussion about why only QUIC will do whatever the need is.
>> If we are picking a new protocol we should be _super_ clear why.
>> The current multilayer protocol soup at least has the advantages that each ingredient is reasonably well known and
>> well specified. Most of them have multiple tested public implementations.
>> 
>> This is useful in 2 ways:
>> 1) it makes the spec possible to implement in a reasonable timeframe.
>> 2) it makes it relatively easy to handwave about the security properties of the stack.
>> e.g: "You were going to use x over DTLS - this is just the same, but has ICE support and works in a browser"
>> 
>> Given that we haven't implemented 1.0 anywhere yet, I'm a bit negative about 2.0 including a load of new untested stuff
>> 
>> It sounds like you're making three completely different arguments:
>> 
>> 1.  Something like "let's not do any 2.0 stuff until all the 1.0 stuff is implemented”.
> 
> Not quite what I meant - more like :
> Our experience is that optionalities in webRTC 1.0 make for complexity and poorer interop - supporting both QUIC and SCTP/DTLS in
> 2.0 introduces a whole swathe of new failure modes.
> 
> I'm having a hard time thinking of what this "whole swathe" would entail.  Could you be more specific?

Ok, off the top of my head:

What's the security context of the proposed QUIC datachannel? Does it share the same cert/fingerprint as DTLS (if you have both) active?
If it doesn't use the same cert, how does it tie back to the SDP and via that to the CORS and from there to the originating domain?
How does this work with IdP ?  

How are the SRTP keys generated ? - Do you always have to start DTLS to create them? Or does QUIC do this ? What happens if
both protocols are available - who creates the SRTP key material?

It looks like QUIC doesn't do labels on streams, what happens if an app wants labeled streams - does it have to use DTLS/SCTP?

Where will you set the SRTP crypto mode? It is currently set in a DTLS extension.

The answers to these questions each imply a possible failure mode.

- Thats all before I've had coffee.


>  
> 
>> 
>> 2.  Something like "let's not do any untested things in 2.0, and QUIC is untested”.
>> 
>> 3.  Let's only do things unless we have good reasons.
>> 
>> 
>> I don't agree with  #1.  If we wait until all the browsers are done implementing all of 1.0 before we standardize anything else, we'll be twiddling our thumbs for a long time in the WG and wasting valuable time.  The standardization process takes a long time, so we might as well start now on work that will take a while rather than waiting until much later.   We should do something with the time we have, but not sit around doing nothing while implementations catch up.  
> 
> I agree standards take a while, but setting QUIC itself as a goal in the WG charter seems like putting the cart before the horse.
> Prematurely latching onto an acronym rather than a set of desirable properties is how we got stuck on SDP IMHO. A charter shouldn’t specify a solution IMHO.
> 
> If you want to say "better data channels" or something generic in the charter and then decide on QUIC in the WG after the charter, I suppose that makes sense.  But I'm not sure how it would be anything other than QUIC.  Is there another option around I don't know about?

I think 'better data channels' with a list of shortcomings in the current offer is a good way to start a 2.0 group. 
I'd be very surprised if we end up with _pure_ unadulterated QUIC - WebRTC has a habit of needing changes to existing specs for it's unique environment.


>  
> 
>> 
>> I don't agree with #2.  While the QUIC that's coming out of the QUIC WG is untested (since it's not done), the pre-draft version of QUIC out in the while is very tested and used very widely in production.  In what sense is QUIC untested?  
> 
> In the sense that there are a _lot_ of independent DTLS implementations running on a vast range of hardware - from SIM cards up to IBM big iron with everything in between.
> QUIC has a much narrower range of tested support and implementations.
> 
> If having a lot of well-tested independent implementations were a requirement for data channels, we wouldn't be using SCTP.  It basically had one.  And in my experience the most widely deployed QUIC implementation is much more robust and mature than the most widely deployed SCTP implementation.  And in a few years (perhaps sooner), there will be a lot of interoperable QUIC implementations.  And there will still probably be only one SCTP implementation that anyone uses.  


Technically that isn't right - the maths is that every chrome/firefox/safari instance runs that SCTP - whereas only chrome runs QUIC, I very much doubt you have more server side 
QUICs than there are firefoxes - Nit picking I know....

Also, that's exactly why I wrote a fresh SCTP implementation - so make that at least 2 ;-) 

T.