Re: SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Hi All,

A think for all the normal cases m=connection attribute must be specified
when TLS is used. There is no way to know if remote party supports tls-id
when offer is sent, so if m=connection is not specified, then it is unclear
how the offer is going to be processed.

The only exception I can this of would be ICE TLS candidates, if ICE TLS
candidates would ever get defined. ICE procedures would overwrite a lot of
what we are going to define here, including how fingerprints are specified
and matched and when TLS connections are established. I believe this is
something that should be defined in ICE TLS document and update this
document, if necessary.

Regards.

_____________
Roman Shpount

On Mon, Apr 10, 2017 at 3:10 PM, Christer Holmberg <
[email protected]> wrote:

> And XXX stands for section 5.1 :)
>
>
>
> *From:* Christer Holmberg
> *Sent:* 10 April 2017 22:10
> *To:* Christer Holmberg <[email protected]>; mmusic (E-mail)
> <[email protected]>
> *Cc:* [email protected]; Ben Campbell <[email protected]>
> *Subject:* SDP connection attribute optional [was: DTLS-SDP: TLS support
> added]
>
>
>
> Hi,
>
>
>
> Section XXX of RFC 4145 says:
>
>
>
>    “When an offerer generates an 'm' line that uses TCP, it SHOULD provide
> a
>
>    connection attribute for the 'm' line unless the application using
>
>    the 'm' line has other means to deal with connection reestablishment.”
>
>
>
> Now, if both endpoints support the ‘tls-id’ attribute, that would be
> “other means”.
>
>
>
> However, section of RFC 4145 says:
>
>
>
>    “The default value of the connection attribute in both offers and
>
>    answers is 'new'.”
>
>
>
> So, I think we need to say something. Either:
>
>
>
> 1)      If both endpoints support tls-id, they don’t need to care about
> the connection attribute (or the default value in case the attribute is not
> present); OR
>
> 2)      We mandate that the connection attribute is present, with an
> ‘existing’ value, whenever an existing connection is to be maintained.
>
>
>
> Option 2) seems most safe, i.e., we continue using the ‘connection’
> attribute and its semantics even if both endpoints support the ‘tls-id’
> attribute.
>
>
>
> Comments?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* mmusic [mailto:[email protected] <[email protected]>] *On
> Behalf Of *Christer Holmberg
> *Sent:* 09 April 2017 10:15
> *To:* mmusic (E-mail) <[email protected]>
> *Cc:* [email protected]; Ben Campbell <[email protected]>
> *Subject:* [MMUSIC] DTLS-SDP: TLS support added
>
>
>
> Hi,
>
>
>
> Based on the decision in Chicago to allow usage of the SDP ‘dtls-id’
> attribute also for TLS connections, I have created a pull request:
>
>
>
> https://github.com/cdh4u/draft-dtls-sdp/pull/26
>
>
>
> Note that the name of the attribute has now been changed to ‘tls-id’.
>
>
>
> The approach I’ve taken is: rather than talking about both DTLS and TLS
> throughout the document, I’ve basically added a section describing the
> TLS-specific considerations – mainly regarding the interaction with the SDP
> ‘connection’ attribute.
>
>
>
> Now, I think we do need some text on WHY we also cover TLS connections
> since, as far as creating new connections is concerned, the ‘connection’
> attribute can be used. We know that it would be needed for
> draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/
> doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been
> adopted yet, so I don’t think we can use it as justification at this point?
>
>
>
> Note that this pull request does NOT include any of the changes to be done
> based on the gen-art/sec-dir reviews. I have updated the 4572-update
> reference, though.
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

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