Re: [rtcweb] Consent alternative

Actually, this removes some of the complication.  At worst, it just moves it.

This concentrates all of the logic at the DTLS layer.  If you choose
to treat it so, ICE no longer needs to play any role in determining
consent.

DTLS already has a consent mechanism in place (that's the function of
the cookie in the handshake, a feature we don't tend to use when
running ICE).   This expands that to include an ongoing process.  The
only complications come from the interaction between DTLS and SRTP, a
relationship that is already complicated somewhat on the keying layer.

I don't know whether anyone implementing DTLS-SRTP also implements
DTLS renegotiation and EKT at the same time, but those are the areas
where things get tricky.  Otherwise, you have a DTLS (or DTLS-SRTP)
layer that manages consent.

On 22 November 2013 10:08, tim panton <tim@phonefromhere.com> wrote:
>
> On 22 Nov 2013, at 09:55, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> I know that I've been a fan of consent via ICE, but with the decision
>> in Berlin to move to DTLS only, several of us have observed that
>> perhaps RFC 6520 might be a better alternative.
>>
>> We've put together an exploration of the idea here:
>>
>> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
>>
>> The best part of this is that it changes the dynamics (for the better,
>> I think).  You don't need to send extra packets if you are actively
>> using the flow.  That means that 1:1 sessions won't need to spend
>> extra cycles or bytes on keeping the session live.
>>
>> There are some gotchas for multiparty sessions, but I believe those to
>> be manageable.
>
> I have misgivings about this - It feels to me to force a mixing of layers in the
> packet handling - At the moment in the implementation I’m familiar with, the ICE/DTLS/SRTP
> state machines are almost completely isolated. This proposal seems (at first glance)
> to make them intertwine in a quite complex way - consent is generated (if I understand it correctly)
> by any of the layers. Likewise each of the layers needs to know if the others have generated consent
> granting packets.
>
> If we are to blur the boundaries like this, we should go the whole hog and get some real benefits - like
> for example remove some round-trips in session establishment by (say) carrying the DTLS hello in the
> same STUN packet as has ICE USE-CANDIDATE set - for example.
>
> I’m against including this sort of change at this stage in the standards process.
>
> T.
>
>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>