Re: actpass redux

On Mon, Jun 12, 2017 at 12:25 PM, Christer Holmberg <
[email protected]> wrote:

> Hi,
>
>
>> First, one of the reasons we update specs is because there are usages
>> etc, that people weren’t aware of when the original spec was published,
>> that we think we need to cover. So, rather than just saying that we don’t
>> care about non-comformant endpoints, we should ask WHY they are
>> non-comformant. Is there a specific use-case behind? If so, do we need to
>> cover that use-case?
>>
>
> Yes, and one of the things we have to keep in mind is not breaking
> conformant endpoints.
>
> *"Be conservative in what you send, be liberal in what you accept”*
>

https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/



As far as I understand, we would still mandate endpoints to support
> receiving non-actpass values.
>

I don't believe that 5763-conformant endpoints are in fact required to do
so, and
therefore it's not appropriate to break them by allowing people to send
actpass
in initial offers when offering DTLS-SRTP.

-Ekr



>
> Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp
>> is GENERIC - one of the main reasons we do the spec in the first place is
>> to have the DTLS-related O/A procedures in one place. And, RFC 7345
>> (UDPTL-DTLS) DOES allow non-actpass values in the offer:
>>
>> 	"The offerer SHOULD assign the SDP "setup" attribute with a value of
>>    	"actpass", unless the offerer insists on being either the sender or
>>    	receiver of the DTLS ClientHello message,"
>>
>> draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and
>> by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure,
>> we can do that, but it cannot be based on a claim that existing endpoints
>> are non-comformant.
>>
>> And, I do NOT think we want to allow non-actpass for some usages (e.g.,
>> UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that
>> would go against the purpose of having generic DTLS O/A procedures.
>>
>
> Well, given that we apparently have incompatible existing RFCs, I'm not
> sure I see any alternative.
>
> I object to that – we basically would have to update the spec every time
> there is a new data type, or define the type-specific O/A procedures in a
> separate spec – which is what has been previously been done.
>
> I think our aim should be to have generic procedures, even if that means
> we have to change procedures some existing RFCs.
>



> From: mmusic <[email protected]> on behalf of Eric Rescorla <
> [email protected]>
> Date: Saturday 10 June 2017 at 12:34
> To: Roman Shpount <[email protected]>
> Cc: Paul Kyzivat <[email protected]>, "[email protected]" <
> [email protected]>
> Subject: Re: [MMUSIC] actpass redux
>
>
>
> On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <[email protected]> wrote:
>
>> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[email protected]>
>> wrote:
>>
>>> On 6/9/17 9:17 AM, Cullen Jennings wrote:
>>>
>>>>
>>>> On Jun 8, 2017, at 6:49 PM, Roman Shpount <[email protected]> wrote:
>>>>>
>>>>>   Because of this, I think for the best interop, offerer MUST specify
>>>>> actpass for both initial and subsequent offers but answerer MUST be able to
>>>>> handle active and passive setup roles as well.
>>>>>
>>>>
>>>> that works for me
>>>>
>>>
>>> I don't understand what this accomplishes. If you must be able to accept
>>> anything in a received offer, then what is gained by restricting what can
>>> be used in an offer?
>>>
>>
>> This is all because of legacy interop. There are legacy end points that
>> send non-actpass, so end point MUST be able to accept active and passive to
>> interop with such legacy devices.
>>
>
> Those legacy endpoints are clearly noncomformant, so I'm not sure I care
> about breaking them,
>
>
>
>> There are also legacy end points that only expect actass so end point
>> MUST only send actpass to interop with such devices.
>>
>
> These legacy endpoints are conformant, which is why it's important to
> accommodate them
>
> -Ekr
>
>
>> _____________
>> Roman Shpount
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic