Re: Towards a new charter for the WebRTC Working Group

On Wed, Jan 10, 2018 at 2:51 AM T H Panton <thp@westhawk.co.uk> wrote:

>
> 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> wrote:
>
>>
>> On 6 Jan 2018, at 00:57, Peter Thatcher <pthatcher@google.com> wrote:
>>
>>
>>
>> On Tue, Jan 2, 2018 at 3:47 AM T H Panton <thp@westhawk.co.uk> wrote:
>>
>>>
>>>
>>> > On 2 Jan 2018, at 05:26, Bernard Aboba <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?
>

The JS specifies the cert.  It's up to it to decide.


> 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?
>

It's up to the JS to control any tie back to SDP.


> How does this work with IdP ?
>

It doesn't.  But neither does 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?
>


They aren't.  This is for data channels (and media over QUIC, eventually),
not a replacement for DTLS-SRTP.  We could come up with a replacement for
DTLS-SRTP, but that's not what we're proposing right now.


>
> It looks like QUIC doesn't do labels on streams, what happens if an app
> wants labeled streams -
>

That's up to the JS to decide.  A few bytes at the front of a stream seems
straightforward if it wants to do that.



> does it have to use DTLS/SCTP?
>

No.


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

This is not a replacement for DTLS-SRTP.  That could be proposed, but
that's not this proposal.


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

I'm not really seeing a failure mode except one that JS creates for itself.


>
> - 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.
>

What do you mean by "start a 2.0 group"?  Do you mean the recharter?  No
one is proposing starting a different 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.
>

We've been feeding back some things into the QUIC WG (such as for demux
with RTP and DTLS).  But I think "_pure_ unadulterated QUIC" is the optimal
and that's what we're targeting.


>
>
>
>
>>
>>
>> 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....
>

Well, I said "in a few years (perhaps sooner)".   And there's a lot more
traffic moving over QUIC than DTLS/SCTP.



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

Interesting.  Is it open source?  Do you have a link to it?


>
> T.
>