Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review

[Justin Uberti <[e-mail]>]

The terminology change to "application" was intentional as many of the
parameters that are exchanged are ultimately under the control of the
application (eg via setCodecPreferences or BUNDLE policy) and we wanted to
make that clear.

Regarding the S8 use of "application's IP address" that you mentioned, that
was an AUTH48 change to replace the text "your IP address". I agree that
your suggestion of "endpoint's IP address" is more accurate here.

Justin

On Sun, Mar 31, 2024 at 3:52 PM Eric Rescorla <[e-mail]> wrote:

> Hi,
>
> I have attached new XML with some minor revisions:
>
> 1. Changed my affiliation as I am no longer with Mozilla
> 2. Changed
>    2<sup>63</sup>-1.
>  to
>    (2<sup>63</sup>)-1.
>
> The current version renders fine in HTML but is confusing in
> plain text.
>
> S 8.
> Changed the reference to an "application's" IP address to
> an "endpoint's" IP address. Applications don't really have
> addresses independent from the systems they are on.
>
>
> I also had a question about terminology.
>
> There are a number of cases where the term "application" is used to
> refer to the browser, both in new text (5.2.1) and as a change from
> "implementation" (5.9). This appears to me to be a regression, as some
> endpoints may not really be applications and in the case of the Web
> there is some confusion about whether the term "application" refers to
> the the browser and the Web app. In this case, it's the browser and so
> "implementation" seems superior. Justin, Cullen, did you make these
> changes? If not, I would like to consistently use "implementation"
> in these cases and can provide new XML.
>
>
> -Ekr
>
>
>
> On Fri, Mar 29, 2024 at 11:29 AM Lynne Bartholomew <[e-mail]>
> wrote:
>
>> Hi, Eric.
>>
>> Checking in with you regarding the status of this document.
>>
>> Thank you!
>>
>> RFC Editor/lb
>>
>> > On Mar 15, 2024, at 11:57 AM, Lynne Bartholomew <[e-mail]>
>> wrote:
>> >
>> > Hi again, Eric.  Thank you for the update.
>> >
>> > RFC Editor/lb
>
>
>> >
>> >> On Mar 15, 2024, at 9:59 AM, Eric Rescorla <[e-mail]> wrote:
>> >>
>> >> I need to find some time to read this, but at this point I think it
>> will be after Brisbane,.
>> >>
>> >> On Fri, Mar 15, 2024 at 8:23 AM Lynne Bartholomew <
>> [e-mail]> wrote:
>> >> Hi, Eric.
>> >>
>> >> Checking in with you regarding the status of this document.  Please
>> advise.
>> >>
>> >> Thank you!
>> >>
>> >> RFC Editor/lb
>> >>
>> >>> On Mar 4, 2024, at 3:39 PM, Sean Turner <[e-mail]> wrote:
>> >>>
>> >>> Many thanks Justin!
>> >>>
>> >>> spt
>> >>>
>> >>> Sent from my iPhone
>> >>>
>> >>>> On Mar 4, 2024, at 02:28, Justin Uberti <[e-mail]> wrote:
>> >>>>
>> >>>> I read through the latest diff and this all looks good to me,
>> please proceed with publication. Thanks all for your help to get this done!
>> >>>>
>> >>>> Justin
>> >>>>
>> >>>> On Thu, Feb 29, 2024 at 5:15 PM Sean Turner <[e-mail]> wrote:
>> >>>> Thanks!
>> >>>>
>> >>>> spt
>> >>>>
>> >>>>> On Feb 29, 2024, at 20:14, Justin Uberti <[e-mail]>
>> wrote:
>> >>>>>
>> >>>>> I'm going to do a read-thru this weekend just to review all the
>> edits and hope to sign off once that is done.
>> >>>>>
>> >>>>> On Wed, Feb 28, 2024 at 6:55 PM Eric Rescorla <[e-mail]> wrote:
>> >>>>> I still have to review the changes; I've been waiting for these
>> discussions to conclude beforehand. I'll try to do that in the next week or
>> two.
>> >>>>>
>> >>>>> -Ekr
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Feb 28, 2024 at 9:11 AM Ted Hardie <[e-mail]>
>> wrote:
>> >>>>> Hi Eric, Justin,
>> >>>>>
>> >>>>> Are you also okay?
>> >>>>>
>> >>>>> Ted
>> >>>>>
>> >>>>> On Tue, Feb 27, 2024 at 6:10 PM Lynne Bartholomew <
>> [e-mail]> wrote:
>> >>>>> Hi, Cullen.
>> >>>>>
>> >>>>> Glad that all looks good.  We have noted your approval:
>> >>>>>
>> >>>>>   https://www.rfc-editor.org/auth48/rfc9429
>> >>>>>
>> >>>>> Thank you!
>> >>>>>
>> >>>>> RFC Editor/lb
>> >>>>>
>> >>>>>> On Feb 27, 2024, at 5:25 AM, Cullen Jennings <[e-mail]>
>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> Thanks looks good to me.
>> >>>>>>
>> >>>>>> I am OK to publish this.
>> >>>>>>
>> >>>>>> Thank you
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Feb 26, 2024, at 3:50 PM, Lynne Bartholomew <
>> [e-mail]> wrote:
>> >>>>>>>
>> >>>>>>> Hi, Justin, Ted, Eric, and Cullen.
>> >>>>>>>
>> >>>>>>> Cullen, we have updated this document per your note below.
>> >>>>>>>
>> >>>>>>> The latest files are posted here.  Please refresh your browser:
>> >>>>>>>
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429.txt
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429.pdf
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429.xml
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-diff.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-rfcdiff.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-auth48diff.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-lastdiff.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-lastrfcdiff.html
>> >>>>>>>
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-xmldiff1.html
>> >>>>>>> https://www.rfc-editor.org/authors/rfc9429-xmldiff2.html
>> >>>>>>>
>> >>>>>>> Please let us know whether (1) additional updates are needed for
>> this document or (2) you approve this document for publication in its
>> current form.
>> >>>>>>>
>> >>>>>>> Thank you!
>> >>>>>>>
>> >>>>>>> RFC Editor/lb
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Feb 26, 2024, at 2:30 PM, Justin Uberti <[e-mail]>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> This proposal also looks good to me.
>> >>>>>>>>
>> >>>>>>>> On Mon, Feb 26, 2024 at 6:42 AM Ted Hardie <[e-mail]>
>> wrote:
>> >>>>>>>> Hi Justin,
>> >>>>>>>>
>> >>>>>>>> Can you confirm you are also okay with this way forward?
>> >>>>>>>>
>> >>>>>>>> thanks,
>> >>>>>>>>
>> >>>>>>>> Ted
>> >>>>>>>>
>> >>>>>>>> On Mon, Feb 26, 2024 at 1:44 PM Eric Rescorla <[e-mail]>
>> wrote:
>> >>>>>>>> This works for me.
>> >>>>>>>>
>> >>>>>>>> On Sat, Feb 24, 2024 at 9:53 AM Cullen Jennings <[e-mail]>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> First, my huge apologies for the ridiculous time I have taken to
>> get back to this. I was out sick for a while and then dealing with reorgs
>> at Cisco but even with all of that, I should have done this long ago.
>> >>>>>>>>
>> >>>>>>>> I agree with Ekr's reasoning on what we should do here to cite
>> both RFC 6347 and 9147 along with the note he proposed for section 5.1.1. I
>> think that should acceptable to anyone else too based on Ekr's argument.  I
>> can see an argument that the note is not needed but I think it clarifies a
>> somewhat confusing situation of what does referencing both 6347 and 9147
>> even mean.  I would argue that since 9147 is permitted, not required, in
>> RFC8827 this could be an information instead of normative reference to
>> 9147. However, I think the note clarifies the issue and I am fine with
>> ignoring if the ref is normative or not. So I’m fine with both 6347 and
>> 9147 normative along with the note.
>> >>>>>>>>
>> >>>>>>>> Lynne, can you make the following changes ?
>> >>>>>>>>
>> >>>>>>>> In 5.1.1 add Ekr's note to the bullet point:
>> >>>>>>>>
>> >>>>>>>> OLD
>> >>>>>>>> * DTLS [RFC6347] [RFC9147] or DTLS-SRTP [RFC5763] MUST be used,
>> as
>> >>>>>>>> appropriate for the media type, as specified in [RFC8827].
>> >>>>>>>> NEW
>> >>>>>>>> * DTLS [RFC6347] [RFC9147] or DTLS-SRTP [RFC5763] MUST be used,
>> as
>> >>>>>>>> appropriate for the media type, as specified in [RFC8827].
>> >>>>>>>> Note: RFC 8827 requires implementations to support
>> >>>>>>>> DTLS 1.2 [RFC 6347] and permits the use of DTLS 1.3 [RFC 9147].
>> >>>>>>>> (I did not change anything in the old, just added note to end of
>> it).
>> >>>>>>>>
>> >>>>>>>> I think that is only change that comes out of this.
>> >>>>>>>>
>> >>>>>>>>> On Jan 15, 2024, at 12:36 PM, Eric Rescorla <[e-mail]>
>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Mon, Jan 15, 2024 at 11:15 AM Cullen Jennings <[e-mail]>
>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Sorry for the very long delay on this. It’s been an a sort of
>> shitty month for me.
>> >>>>>>>>>
>> >>>>>>>>> Hi Cullen,
>> >>>>>>>>>
>> >>>>>>>>> I think we should disentangle two issues.
>> >>>>>>>>>
>> >>>>>>>>> 1. What we substantively say about what version of DTLS people
>> ought to use.
>> >>>>>>>>> 2. What we use as a citation where the bare term "DTLS" without
>> a version number is used.
>> >>>>>>>>>
>> >>>>>>>>> As you may recall, JSEP doesn't specify DTLS versions and
>> leaves that to S 6.5 or RFC 8827, which has this somewhat labored text
>> encouraging but not requiring you to use DTLS 1.2.
>> >>>>>>>>>
>> >>>>>>>>> All implementations MUST support DTLS 1.2 with the
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve
>> [FIPS186]. Earlier drafts of this specification required DTLS 1.0 with the
>> cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this
>> writing some implementations do not support DTLS 1.2; endpoints which
>> support only DTLS 1.2 might encounter interoperability issues. The
>> DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported
>> for SRTP. Implementations MUST favor cipher suites which support Forward
>> Secrecy (FS) over non-FS cipher suites and SHOULD favor Authenticated
>> Encryption with Associated Data (AEAD) over non-AEAD cipher suites. Note:
>> the IETF is in the process of standardizing DTLS 1.3 [TLS-DTLS13].
>> >>>>>>>>>
>> >>>>>>>>> If we wanted to say anything normative about DTLS, we would
>> properly do so in an 8827 bis, but we haven't done so, and I don't recall
>> there being much WG discussion on DTLS versions since DTLS 1.3 was
>> published. So my suggestion would be to try to just address point (2) here,
>> which is to say to provide reasonable references while not creating new
>> normative facts on the ground. I think the text above permits the use of
>> DTLS 1.3,  so the current status is your (A), and while I would argue for
>> A'[MUST DTLS 1.2, SHOULD DTLS 1.3] I don't think that's for this document.
>> >>>>>>>>>
>> >>>>>>>>> This leaves us with the question of what references to provide.
>> What I suggest here is that we cite both RFC 6347 and 9147 wherever we just
>> say "DTLS", except for S 5.1.1, which actually requires the use of DTLS,
>> and there add a note something like:
>> >>>>>>>>>
>> >>>>>>>>> "Note: RFC 8827 requires implementations to support DTLS 1.2
>> [RFC 6347] and permits the use of DTLS 1.3 [RFC 9147]".
>> >>>>>>>>>
>> >>>>>>>>> How does this sound?
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Below I do address your substantive points which might go into
>> a discussion of an 8827-bis, but if you agree with me here, we don't need
>> to reach those here.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> On Dec 11, 2023, at 7:13 AM, Eric Rescorla <[e-mail]>
>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Let's make sure that we agree on the substantive situation
>> first.
>> >>>>>>>>>>
>> >>>>>>>>>> * DTLS 1.3 deprecates DTLS 1.2, so a compliant implementation
>> should be able to use either.
>> >>>>>>>>>
>> >>>>>>>>> I suspect we disagree on what deprecate means but probably not
>> relevant to sort this out.
>> >>>>>>>>>
>> >>>>>>>>> I should have been clear: RFC 9147 obsoletes RFC 6347. As
>> people probably know, I'm not a fan of any of these tags, so I'm open to
>> arguments that this was wrong, but that's what it says.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> I want to be careful on use or implement. For sure, I think it
>> is great for an implementation to support both and negotiate the latest
>> thing it can.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> * DTLS 1.3 is not yet widely deployed, so a compliant
>> implementation should implement 1.2 and 1.3, at least for now.
>> >>>>>>>>>
>> >>>>>>>>> Well, I think I am arguing they need to 1.2 to be a webrtc
>> complaint implantation and it would be very nice if they also do 1.3
>> >>>>>>>>>
>> >>>>>>>>> Even worse that adoption, DTLS 1.3 is blocked by a significant
>> fraction of enterprise firewalls. I would like to keep webertc working in
>> those situations for now. I agree there is a point in time where we decide
>> that things that only do 1.2 just get left behind but I don’t think that
>> anyone is arguing we do that in Auth 48 of this doc.
>> >>>>>>>>>
>> >>>>>>>>> Absolutely not.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> What I don’t want to be in situation of saying you must use 1.3
>> to be webrtc compliant because I think that will cause a lot of breakage.
>> >>>>>>>>>
>> >>>>>>>>> 100% agreed. I also think it is reasonable to argue that we
>> shouldn't have MUST implement 1.3 (see below).
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Neither of these "shoulds" is intended in the 2119 sense, just
>> in terms of what we expect.
>> >>>>>>>>>>
>> >>>>>>>>>> Do you disagree with either of these statements?
>> >>>>>>>>>
>> >>>>>>>>> So just trying to reason my way through this. Look at it from
>> point of view of what we are asking implements to implement if they are
>> compliant with this RFC to be. Some various things we could be asking for
>> are:
>> >>>>>>>>>
>> >>>>>>>>> A. Must implement 1.2 and may implement 1.3
>> >>>>>>>>>
>> >>>>>>>>> B. Must implement both 1.2 and 1.3
>> >>>>>>>>>
>> >>>>>>>>> C. Must implement 1.3 and Must NOT use 1.2
>> >>>>>>>>>
>> >>>>>>>>> D. I guess a 4th option is could have a MUST implement 1.3 and
>> but is optional to implement 1.2 or not but that seems pretty much the same
>> as C from an interoperability point of view.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> I was working on the assumption that we were doing A for this
>> draft because that is the situation for 8829 and we were not changing the
>> TLS version part of things in this draft.
>> >>>>>>>>>
>> >>>>>>>>> I feel very strongly it is too early to do C and it would be
>> bad for WebRTC to do C at this point of time. And this was caused me to
>> think the refs were not right in the draft.
>> >>>>>>>>>
>> >>>>>>>>> On B - I’m just not sure. Part of me feels like mandating this
>> is sort of like mandating webrtc must do both v4 and v6. I have no
>> objections to a very convincing argument either way. I do feel a bit like,
>> is this the right draft for this change.
>> >>>>>>>>>
>> >>>>>>>>> That make sense as way of clarifying a path forward ? I agree
>> with you that as long as we are clear what we are trying to get done, we
>> can figure out how to tweak the reference spices to get that taste.
>> >>>>>>>>>
>> >>>>>>>>> On the substantive matter, I totally agree that C and D are
>> nonstarters. I think it's between A (or maybe A' [MUST TLS 1.2 and SHOULD
>> TLS 1.3]) and B.
>> >>>>>>>>>
>> >>>>>>>>> -Ekr
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>> >
>>
>>