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

[Eric Rescorla <[e-mail]>]

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
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>