Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
Eric Rescorla <ekr@rtfm.com> Mon, 26 February 2024 13:44 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6ECC151980 for <auth48archive@ietfa.amsl.com>; Mon, 26 Feb 2024 05:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8x1N2QerHib for <auth48archive@ietfa.amsl.com>; Mon, 26 Feb 2024 05:44:48 -0800 (PST)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01612C15171B for <auth48archive@rfc-editor.org>; Mon, 26 Feb 2024 05:44:48 -0800 (PST)
Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-dbed0710c74so2660313276.1 for <auth48archive@rfc-editor.org>; Mon, 26 Feb 2024 05:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1708955087; x=1709559887; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YzIwnLtnZhdTInwZb9z/wfaovakRwhBF162ifVfFXFo=; b=1Kl5lQW5yRRHdO7uyCtYPz//fUTZd3MW0pZwmcSfr7o47nvt3NwByRJLFnykBpZ9ha lt3R+56uzM+21WJ/aABPyim75UXPEtWpzgclEuZkkD8Ex723ZFek8EmiI7zUja5gbnoZ fDGKdorTpFJ2btuo8Cq90cDywZ74glLrg37KBN9FwXTDdGhFou2aV7bAo0yEQ1Dvp4nm f4oxQOXH1dM+Fp5h1swgRHK0oA6uIUDoxR9BEvSxnJw04YyZ5n5Ao97FE9A1r9xzDkXY slyma8sp0+sr/PfdPbjLxUX1sq4jsWsPsSsttQPmkYEyvw2axipcGJB+EsquZt7Un1Kq jMqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708955087; x=1709559887; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YzIwnLtnZhdTInwZb9z/wfaovakRwhBF162ifVfFXFo=; b=gPJTExygyIvEf5FarYflj7ENryseqPOLbpmKPReCeTf0IznvrLTW1bbeeBEkeJyYCm Lp6Rpd6kAVCa4juDEp5mZAUdoORRb4LU0lM3A2MKYzzi4XIQfBXRz63uUA3CXtsf65aF p71/3NryEJxp79D/whOpEiMOd7LDPth/TAwRM+FwOxeAQ92Qdg6Rmgd+3VNBhxjHghb/ cQ4x3/AnKWfw6Ld55VVLTbPjzjImCPj1t1CBxh5ulv+AmWxFT42M54YAX+g+6pXPAEwc 5jD+UgQzUX+8ci2DrIFlUxOpDkHN/XuNaxLa2ASnVfPkf3jGI134P3K+d6iEGfhIrzU/ pwaA==
X-Forwarded-Encrypted: i=1; AJvYcCXfNs350Ua+4pJgZmA5eElUetqGFHOLKdYt9VzIihCfCbo2C00hh9aoJiULNk2Rekk6CPb9CQ+Sb80cnfJLo9w5+IuwmdwlcA5GAsVE
X-Gm-Message-State: AOJu0Ywr8jP68psvYaMPT4+nz7N5Pvkbv6EGl+oBGZmw019sfaJ0FZ0B Ofq9MnWjVlQZ0PcL2AxiYtoXYsYlKvSHTHFJ7B3WhyWiHB/0a38KvBhDsp7Jkq7X+oLw9PVCz/v kzPpTjeUI7zHyD0CtAwLXNU7RmjvfouYLMVFDPQ==
X-Google-Smtp-Source: AGHT+IG1NlsKLujqXPSESxgmVRZb1ABXRq+I0KpB7Wapui5gbkdnGOZXvSZrR02Mlg/hvLM9XD/kFf5v1qDkQ3G/wIY=
X-Received: by 2002:a25:4e85:0:b0:dcc:96db:fc0d with SMTP id c127-20020a254e85000000b00dcc96dbfc0dmr3855192ybb.25.1708955086902; Mon, 26 Feb 2024 05:44:46 -0800 (PST)
MIME-Version: 1.0
References: <20231010213257.4587F18E4B44@rfcpa.amsl.com> <CALe60zDWOpAgXM=T+q=jG7GumtWGzASe=i=x5qBSG+bew5046g@mail.gmail.com> <57DC6A9D-181D-4A92-9B78-1A9E4F97252C@amsl.com> <6530F168-75F1-4CA6-9E7D-2D402D6BEC41@iii.ca> <9F18480D-4F13-4C85-B224-66BA4EF2F4EC@amsl.com> <CABcZeBPjdcsea_X0YMrcwbgQmV_uiDdV+3=Aet7VPMaJG1=9GA@mail.gmail.com> <A60976A1-3B52-42A9-9A5B-13618AE62855@amsl.com> <CAL0qLwZYokpy-UHFf24NyEBufFG4rtJQ6MS8bEUrugaJNmdusw@mail.gmail.com> <882B1E35-51DE-4AE2-85A7-6027CF9A3679@amsl.com> <137CB627-2A2A-46E5-86CA-24FF50C97BBC@sn3rd.com> <1EC63115-8045-4442-B1F9-1621DF507D98@amsl.com> <5B33BBAB-FA41-441B-97AF-6518CA98726E@iii.ca> <CABcZeBOZGsHZR7WarEdF+UyHmOJjbCDA_KCiEUpGT6JE75CGtA@mail.gmail.com> <D610B593-CABA-4B44-ABCB-C712F6F112BC@iii.ca> <CABcZeBOiZrOLmTLHpu_b831TCzm_OpciV1c8JxN4fV57+kOw0w@mail.gmail.com> <A3F92F81-CEB4-4E78-9D46-310A1AAFC542@iii.ca>
In-Reply-To: <A3F92F81-CEB4-4E78-9D46-310A1AAFC542@iii.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Feb 2024 05:44:10 -0800
Message-ID: <CABcZeBMuOKg-=pDGU_6uq1gxxmMM13ZHkNzXt1=qvg3dXr0ZCQ@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: Lynne Bartholomew <lbartholomew@amsl.com>, Justin Uberti <justin@uberti.name>, Sean Turner <sean@sn3rd.com>, "Murray S. Kucherawy" <superuser@gmail.com>, RFC Editor <rfc-editor@rfc-editor.org>, rtcweb-ads@ietf.org, rtcweb-chairs@ietf.org, auth48archive <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000e46b3f0612491cb9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/b-QtuIeMZkRP1N0Wa2xPJEBxwS4>
Subject: Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2024 13:44:52 -0000
This works for me. On Sat, Feb 24, 2024 at 9:53 AM Cullen Jennings <fluffy@iii.ca> 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 <ekr@rtfm.com> wrote: > > > > On Mon, Jan 15, 2024 at 11:15 AM Cullen Jennings <fluffy@iii.ca> 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 <ekr@rtfm.com> 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 > > > > >
- [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtc… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <draft-… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Murray S. Kucherawy
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Ted Hardie
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew