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

[Eric Rescorla <[e-mail]>]

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