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

[Justin Uberti <[e-mail]>]

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