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

[Eric Rescorla <[e-mail]>]

I approve publication

On Mon, Apr 1, 2024 at 10:20 AM Lynne Bartholomew <[e-mail]>
wrote:

> Hi, Eric, Justin, and Cullen.
>
> Eric, thank you for the updated XML files!
>
> The latest files are posted here:
>
>    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 further changes are needed or you approve this
> document for publication in its current form.
>
>    https://www.rfc-editor.org/auth48/rfc9429
>
> Thanks again!
>
> RFC Editor/lb
>
>
> > On Apr 1, 2024, at 9:56 AM, Cullen Jennings <[e-mail]> wrote:
> >
> >
> >
> >> On Mar 31, 2024, at 4:51 PM, Eric Rescorla <[e-mail]> wrote:
> >>
> >> Justin, Cullen, did you make these
> >> changes?
> >
> > No. But I am fine with direction you and Justin are going with this.
>
> > On Apr 1, 2024, at 7:04 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > Thanks. I have provided new XML with this fix. I trust your judgement on
> the other locations.
> >
> >
> >
> > On Sun, Mar 31, 2024 at 10:27 PM Justin Uberti <[e-mail]>
> wrote:
> > 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
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >
> >
> > <rfc9429.xml>
>
>