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

[Cullen Jennings <[e-mail]>]

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] <mailto:[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] <mailto:[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
> 
> 
>