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

[Ted Hardie <[e-mail]>]

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
>> <https://doi.org/10.6028/NIST.FIPS.186-4> [FIPS186
>> <https://doi.org/10.6028/NIST.FIPS.186-4>]. 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
>> <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>].
>>
>> 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
>>
>>
>>
>>
>>