From nobody Thu Jul 1 01:54:19 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A39D3A1E20; Thu, 1 Jul 2021 01:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWAagHKd9GoT; Thu, 1 Jul 2021 01:54:13 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D120D3A1E1F; Thu, 1 Jul 2021 01:54:12 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id h126so818398vsc.6; Thu, 01 Jul 2021 01:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nBZRHoY97egrpzboT5sTl/U6F1Tha7uZIuXj29nwxF0=; b=g34jRK4Ff3ifTVllbqFml15zmUySpxDAkxwhjsnfAPH1/PLHOb/eB+CKtiFyJy2uzW RUkMByZBWH/IbPqhi7moskTqy1tprGIwCTjNyRC9QwOViY8xXJbVff4vFMID2m+47AUS i4GbRw4zd/ZUz4mykpHKjq0WLHOwDPFFjRK1e3siRjooHPiNVYeQdX9KRwEZ2sOnKKY/ y7QS1j/+WTDxfdd9yeCDmpZ5mquXYZ+wvHamkXAhPUSTC+LTwNspPd/KUOEC32DS68rV WbSBmo2NisOLP5NVUaPaCIyiOwfAKAYvuQhBVUc1fTnlvhyUwPblcBZpG57zFG23BOyd Uv2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nBZRHoY97egrpzboT5sTl/U6F1Tha7uZIuXj29nwxF0=; b=CDwLq7LpdbzpeZw+HxUsxPH/1XHDJzjOwa9QcFZN++IbUZ47VH6jUBNsNx+4ucW+OE y6g2z/SpYTjLRQU13wr2G+djmq/cIlKgyVgR7n3tcJZYBaImSqKDZNxaHL399IikZdYU mInmfLL1j1PZBCbBnu68Wp+L0up/ZtrIY3XQkPpKHFkGFPPq5W2NM9p66c50SsXnUtgP Na5fSU9p1CcvSGxNrTZ1S2/7QouFA/3EalbFB8WsnuxPlU7N1unUh/nRG1MjUFaZdR9F fNpXcsyhc7pK5EKTt/Dpq8+ezAB4SATdjeW+BmaJ8unbu+tWhnf+ZeMemRVpB1KS3hIx EF/Q== X-Gm-Message-State: AOAM531AiokMU7+zkcJ5lfOGzXIfU8mQ3ylG01ZRtY/hhhHNF1mo5ocK xBUZ2/o4dfer+TtzXdTrYEe+IgVAIHSGuMLMAsZFjgYf X-Google-Smtp-Source: ABdhPJycrfc14VYND6aXuH7gpociPwW9DL5vPadPsztO69ApTFsqKHiham7TSUVNWc3bbFsg9mujmGqmehC+Fk5qc4w= X-Received: by 2002:a67:f552:: with SMTP id z18mr11656424vsn.0.1625129651379; Thu, 01 Jul 2021 01:54:11 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> In-Reply-To: <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> From: "Murray S. Kucherawy" Date: Thu, 1 Jul 2021 01:54:00 -0700 Message-ID: To: Alexey Melnikov Cc: Paul Libbrecht , media-types@ietf.org, DISPATCH , Ned Freed Content-Type: multipart/alternative; boundary="00000000000095a15b05c60bfb6d" Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 08:54:18 -0000 --00000000000095a15b05c60bfb6d Content-Type: text/plain; charset="UTF-8" On Wed, Jun 30, 2021 at 9:24 AM Alexey Melnikov wrote: > Hi all, > > On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote: > > On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht wrote: > > > I am wondering if the group is the right place to prepare an update of the > registration template so as remove the Macintosh 4-letter-codes and insert > clipboard flavours for windows and universal type identifiers for macOS. > > This was discussed a few times on this mailing list. > I have been in contact with a few media-type proposers, some of which have > accepted a change of their declaration in this direction. > I have been in contact with one IETF-aware person to update RFC6838 but > that has not progressed. > > > I am the guilty IETF-aware person... > > I am thinking that if we are doing all other related work we might as well > tackle this, so I am in support of doing this in the WG. Now ideally I > would like this to be addressed as an extension to the media type > registration template that list extra optional fields. So I don't want to > reopen RFC6838, but a separate draft that updates it would be great. > It's in an internal review state now before being sent out for wider review, so there's time to make that sort of a change unless there's some kind of objection from the community. I interpret Ned's earlier objections to touching RFC 6838 as being specific to the issue of top level media types, but you're talking about something else here. Hopefully he can confirm (or correct) my understanding. -MSK --00000000000095a15b05c60bfb6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 30, 2021 at 9:24 AM Alexey Me= lnikov <aamelnikov@fastmail.fm= > wrote:
Hi all,

On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote:
On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht <paul@hoplahup.net> wrote:

I am w= ondering if the group is the right place to prepare an update of the regist= ration template so as remove the Macintosh 4-letter-codes and insert clipbo= ard flavours for windows and universal type identifiers for macOS.

This was discussed a few times on this mailing l= ist.
I have been in contact with a few media-type proposers= , some of which have accepted a change of their declaration in this directi= on.
I have been in contact with one IETF-aware person to up= date RFC6838 but that has not progressed.


I am the guilty = IETF-aware person...

I am thinking that if we = are doing all other related work we might as well tackle this, so I am in s= upport of doing this in the WG. Now ideally I would like this to be address= ed as an extension to the media type registration template that list extra = optional fields. So I don't want to reopen RFC6838, but a separate draf= t that updates it would be great.

It's in an internal review state now before being sent out for wider= review, so there's time to make that sort of a change unless there'= ;s some kind of objection from the community.=C2=A0 I interpret Ned's e= arlier objections to touching RFC 6838 as being specific to the issue of to= p level media types, but you're talking about something else here.=C2= =A0 Hopefully he can confirm (or correct) my understanding.

<= /div>
-MSK

--00000000000095a15b05c60bfb6d-- From nobody Thu Jul 1 06:07:55 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAF3A0D6E for ; Thu, 1 Jul 2021 06:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21ecZj6i_dyB for ; Thu, 1 Jul 2021 06:07:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959873A0DB0 for ; Thu, 1 Jul 2021 06:07:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0VLRAFQTS00GP7K@mauve.mrochek.com> for dispatch@ietf.org; Thu, 1 Jul 2021 06:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1625144547; bh=wQeVtaHonDoWbpFJq5VA9c2M6NbTQG3R4fMlXDL4UpU=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=I1al44Y35XBkCuvf2YCLp0EnZH4H9j0FzF9K/LK4iswd4fBYcbtYzwT5uiBR96GYJ 5i3z+rv+E49Met5HYq5m9Viuoe56/CgDf9ndIPn5S+e77fXBffSlW1AJe9H/OtQB9B EClLApU8syQO5fXvGGSQrPZVWHar2cw6YkPJwCYo= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S0F3SXH38G005PTU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Thu, 1 Jul 2021 06:02:22 -0700 (PDT) From: ned+dispatch@mrochek.com Cc: Alexey Melnikov , media-types@ietf.org, DISPATCH , Paul Libbrecht , Ned Freed Message-id: <01S0VLR7TAIW005PTU@mauve.mrochek.com> Date: Thu, 01 Jul 2021 05:54:18 -0700 (PDT) In-reply-to: "Your message dated Thu, 01 Jul 2021 01:54:00 -0700" References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> <2aefbe02-bf86-4689-a8d3-b6fd8149ed56@www.fastmail.com> To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dispatch] [media-types] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 13:07:50 -0000 > On Wed, Jun 30, 2021 at 9:24 AM Alexey Melnikov > wrote: > > Hi all, > > > > On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote: > > > > On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht wrote: > > > > > > I am wondering if the group is the right place to prepare an update of the > > registration template so as remove the Macintosh 4-letter-codes and insert > > clipboard flavours for windows and universal type identifiers for macOS. > > > > This was discussed a few times on this mailing list. > > I have been in contact with a few media-type proposers, some of which have > > accepted a change of their declaration in this direction. > > I have been in contact with one IETF-aware person to update RFC6838 but > > that has not progressed. > > > > > > I am the guilty IETF-aware person... > > > > I am thinking that if we are doing all other related work we might as well > > tackle this, so I am in support of doing this in the WG. Now ideally I > > would like this to be addressed as an extension to the media type > > registration template that list extra optional fields. So I don't want to > > reopen RFC6838, but a separate draft that updates it would be great. IMO a separate draft discussing additinal information would be the way to go, assuming a separate draft is even needed. A quick check of the form shows an OID field that isn't in RFC 6838. Additionally, RFC 6838 says to include the information "if available". I think an argument can be made that Mac file type/creator codes are never available, so why bother asing for them? > It's in an internal review state now before being sent out for wider > review, so there's time to make that sort of a change unless there's some > kind of objection from the community. I interpret Ned's earlier objections > to touching RFC 6838 as being specific to the issue of top level media > types, but you're talking about something else here. Hopefully he can > confirm (or correct) my understanding. Speaking as a reviwer, the only additional information that's proved to be difficult to deal with on occasions is magic numbers. It would be very helpful to have some guidance as to how to specify them. The form of such guidance doesn't really matter to me: A note to IANA, draft, whatever. In any case, a work item to discuss what additional information to add/delete would be fine with me. Ned From nobody Fri Jul 2 15:06:19 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7E73A0ABD; Fri, 2 Jul 2021 15:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dispatch@ietf.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337936.26814.6000142877332207922@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:59 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 111 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:11 -0000 Dear Kirsty Paine, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 26 July 2021, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/111/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Kirsty Paine Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: People who must be present: Francesca Palombini Kirsty Paine Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot Monday morning, and list as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, other dispatch groups, and BoFs. --------------------------------------------------------- From nobody Tue Jul 6 07:19:49 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F553A2975; Tue, 6 Jul 2021 07:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC0Gx7S5_H6M; Tue, 6 Jul 2021 07:19:42 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5973A2971; Tue, 6 Jul 2021 07:19:42 -0700 (PDT) Received: from [192.168.3.236] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6CAEF7C6BD6; Tue, 6 Jul 2021 16:19:40 +0200 (CEST) To: Kirsty P , "dispatch@ietf.org" Cc: dispatch chairs References: From: Harald Alvestrand Message-ID: <7faf3be9-294f-4f94-537b-4bb45ef4760d@alvestrand.no> Date: Tue, 6 Jul 2021 16:19:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2881B0155D0151F7DA7344E4" Content-Language: en-US Archived-At: Subject: Re: [dispatch] IETF 111 meeting - call for topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 14:19:47 -0000 This is a multi-part message in MIME format. --------------2881B0155D0151F7DA7344E4 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jonas Oreland I have committed an internet-draft that we'd like to have DISPATCHed: draft-oreland-dispatch-ice-nicer-00 Abstract: NICER presents an usage profile of ICE that permits more dynamic adaptation to network conditions over the time of a call. If it's possible to find time for this, we'd like to present it and ask where we can take it further. On 6/24/21 11:14 AM, Kirsty P wrote: > Hi everyone, > > Do you have some work that needs dispatching? Or something that you'd > like to share with the ART AREA at IETF 111? Then get in touch! > > Patrick and I are starting to put together the agenda for the DISPATCH > meeting at IETF 111 (26-30 July), so if you would like time at the > meeting to discuss your work or ideas, then please get in touch with > us on the dispatch chairs email (CC'd). We're keen to hear from you! > > And if you're not really sure what this dispatching thing is for, or > if you have questions about bringing new work, please get in touch > with us all the same - we're here to help. > > We look forward to hearing from you! > > Kirsty > > > > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer > any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown > Copyright © > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------2881B0155D0151F7DA7344E4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Jonas Oreland I have committed an internet-draft that we'd like to have DISPATCHed:


draft-oreland-dispatch-ice-nicer-00


Abstract:

NICER presents an usage profile of ICE that permits more dynamic adaptation to network conditions over the time of a call.


If it's possible to find time for this, we'd like to present it and ask where we can take it further.


On 6/24/21 11:14 AM, Kirsty P wrote:
Hi everyone,

Do you have some work that needs dispatching? Or something that you'd like to share with the ART AREA at IETF 111? Then get in touch!

Patrick and I are starting to put together the agenda for the DISPATCH meeting at IETF 111 (26-30 July), so if you would like time at the meeting to discuss your work or ideas, then please get in touch with us on the dispatch chairs email (CC'd). We're keen to hear from you!

And if you're not really sure what this dispatching thing is for, or if you have questions about bringing new work, please get in touch with us all the same - we're here to help.

We look forward to hearing from you!

Kirsty



This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright © 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--------------2881B0155D0151F7DA7344E4-- From nobody Thu Jul 8 20:46:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF873A0C4E; Thu, 8 Jul 2021 20:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxt9PwKaa76N; Thu, 8 Jul 2021 20:46:46 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237DA3A0C49; Thu, 8 Jul 2021 20:46:46 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id f17so7510127pfj.8; Thu, 08 Jul 2021 20:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=d9QQi0GAADpTmZUtEIih6YWvln+y2Bvyi1+1jG885Gk=; b=FNmwkB36HaV7c1wrl9m1GPpIRIHR/d6ZylsVoQ0Wyoc54D/cdhlCLswbfxSMH3vSaM Pm4JameKeW+q8YqiX8NxFQvm3JRx121c4mU3G0XbrSXeuvOoZk7ECPYVCEpPHuXAAT06 MRXelCxuBSz1n9H5iDfYUgqvcVlFUGdNuxwEKG2SaoL25gF+CcmjI0lCWYRrU6dnGkFN kZHddYuTbKM/4biWyCXcGniuWHw3+RswXLPraw2AFWAL8hE0nk4Tr7eH8IzMBvE+pBt+ Euf9DQ5v1XIGJps+ZF5puuvYTqQ/VSmdOs8/tQLlCxp4nhoDYrIXNrK5NYcYNbvaf3ge 5Luw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=d9QQi0GAADpTmZUtEIih6YWvln+y2Bvyi1+1jG885Gk=; b=WfYPs+BXNZfxNYC0hdVQnhl527f4S6O2J9p66b7gKlqRAodpUOge0rVxlEMAjKQWI8 VQAE5dqdxWXbZ5NzqDDtTA0xThg2b4eOZbpldJe20yY8xwF6yTNLvz0vRgXpdH9oUBa1 jbjKmmyLUtPyLUi/p5NYlWyUU7YBVbnZgVLwcFFMmSwlMFe6F1/rTL3CYYik3rhFvng2 BHZ2PrpCBYGa4LXwte+f52jOHFTU+uni9nFWxtgdFbz8d3RYS8w/tG0dNnPvtms3ocAc LXvC18J+NMA5k6L4Lj5knN1MK8TgBZK6sVPgYqCrOkk8rc0nxwpf6CZ+3d7KLcSC/6kL sUDA== X-Gm-Message-State: AOAM530QwPGbOiM3v5aTzg5uuAvbsKoiOT5QtwrTfut7PC5tjm2XmDSi CanWq8Jltu5IEU499UuO8Sk= X-Google-Smtp-Source: ABdhPJzSEb+tARu48miTjmnIjCwpjGFumxYYvUyEi1iWANXrNbG0D+Ze+LEOBNrqU8BzbKCIDEWoWA== X-Received: by 2002:a62:6d02:0:b029:324:bc07:4153 with SMTP id i2-20020a626d020000b0290324bc074153mr14714864pfc.58.1625802405436; Thu, 08 Jul 2021 20:46:45 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d191sm5297994pga.27.2021.07.08.20.46.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 20:46:45 -0700 (PDT) To: dispatch@ietf.org Cc: dispatch-chairs@ietf.org, Bob Hinden , francesca.palombini@ericsson.com From: Brian E Carpenter Message-ID: <67e55e7b-e23c-71d6-8da6-16ae49a8e35b@gmail.com> Date: Fri, 9 Jul 2021 15:46:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] IPv6 Zone Identifiers in URIs (RFC6874bis) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 03:46:51 -0000 Hi, Bob Hinden and I are working on an update to RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers": https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ There will be an updated version before the cutoff, and there has been quite a bit of discussion already at https://mailarchive.ietf.org/arch/browse/ipv6/. We expect this to be processed in 6MAN, as RFC 6874 was, but we would like to briefly introduce it to DISPATCH/ART Area since clearly it is not just an Internet Area topic. We're also very much aware that it needs to be looked at by the browser community. So this is a request for a short slot to raise awareness. We're not quite sure who would be presenting due to time zone and agenda clash challenges. Please keep us in Cc as we are not on the DISPATCH list. -- Regards Brian Carpenter From nobody Mon Jul 12 05:14:38 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F243A120A; Mon, 12 Jul 2021 05:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQUATwAs3hfe; Mon, 12 Jul 2021 05:14:28 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC873A11D5; Mon, 12 Jul 2021 05:14:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aXpAi/IV5W2kVP/wMcv5KcSBjkA4nz6NFB/LMvdsLy6AeChKg8yRQZXCd4sErfo6EXkeA6zGsYdZGc3hPirDViFBIh0mx9QH+MOYnffYrNi3PZxar52wxeWqO8bJE76Qp6ZIU0NZA+G2BBmnyx8fDGYHoG11LVT8QqxIAv5RCKdKRid8TeR2URqV4ZupEheG1DJ6gdjzFZo5CNLfd0shCgLff23jk9Q/kjo14ijYxkO2hu8qbuhLTZhMHCfVYScdsMycYXJN3GLrMb0CIFI4wQOCU4Ti2qP6Z7myu0LTWNu+9j9PlipHBQ/WG7DVwp47Jxwzc4xwVuvRN6NbQ5Q5Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpdOfRgnxfK6ma4tNwOLoyJYeBF7fTnsqqpQnb0XQZQ=; b=El912FrXy0tt9SkcawjN71X9gHhc0H48GblIwZLv3biD+IZuv8Mb5EFFfcorxUJldNdw/VSfxqqGgTeMQHHgJnNYWsikahvysIG4O3Cak+hRuUcQxMFsHRGx5qkWksrkY+6MPI2IW/h9yNSBPJfy6WX17aWBgal7o5vvxBM+07a3hcJxkHpuYp8r2RtzYoNgHvKriLlZTb5cixosjYdNo2358PM5fyzAnEZEtY8DKD9FmPl9vKf9NivGMhqIQPTn4M8MqSXr5QW/KhXF1T86V6C/gmMaF8lVXRvg9KEAFrRRQOcRzzudpljmzApJSeQoJztySNkQ91mFpndv2verUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PpdOfRgnxfK6ma4tNwOLoyJYeBF7fTnsqqpQnb0XQZQ=; b=adSp888S2hXttmWTJC+af/dI+eRn4kyepWukPn6DeYfj9sLVa9r2x+Y1wmEz/z2G24oE2Fu6piLoD/qONoFMttVw2lsz3d9aGH0J695nOrcLAl8gFM0iXPwYPf61sV10OkZXV9TzViFeXIKPR9vC6rkMxoRQsrQOkHnqQlTHvR8= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB3001.eurprd07.prod.outlook.com (2603:10a6:3:52::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Mon, 12 Jul 2021 12:14:22 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::5c2c:3dc8:8947:e043]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::5c2c:3dc8:8947:e043%3]) with mapi id 15.20.4331.018; Mon, 12 Jul 2021 12:14:22 +0000 From: Magnus Westerlund To: "dispatch@ietf.org" CC: "mmusic@ietf.org" , "avt@ietf.org" Thread-Topic: New proposal do declare SDP Security Descriptions (RFC4568) Historic Thread-Index: AQHXdxdylpWLeaPaxkigdz2oXMXVfg== Date: Mon, 12 Jul 2021 12:14:21 +0000 Message-ID: Reply-To: "dispatch@ietf.org" Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afb7d7c3-3c25-4ba4-2d90-08d9452e950c x-ms-traffictypediagnostic: HE1PR0701MB3001: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OPtyzhOj+3AW03+Huyav0ngQ7oXI45/f8zNB+a3vNTKZTxtQUvK5U4YPF8S1Uen8pN+66RLItbLs6Rj8W8YXoL/SRTSfeo1jRnwiCflFFgrzzB2QTt/VehWp+DdAFSkITw3DZUQQFntcCA1qSm8z9E038DDLHnm82fKygGUy/tqa8b40Dg/alb3HNUqBFXwCnjm9uDwqcx4d5Nr8ev+0b+vKi/IUqh7IgQ0E/tet8KXifppDQZ8cM1WUtOSXI5dppgBA+yDo4ymvpcSJK2PVMzEZdtqVJd69h0XnxKcvF5Xsey9O5VQkM1x+/w141qo9/kKgXtgcFhcOkiKudWwDTBPn6UKiPfogFKh8a5iJvZx8yIJsPi6TwGLczh1oVqMhLsmA/ZFk1S6vGqP0k4i0Tg7eCjyrQIf0m/0S2N7Ox+FGbCD9QVZ9+uTdPsLLrW+htUXNWvbsq8DwD86eCPcv6YnPU/6G9NL1EwlwW94/cu9zcArJm8xBZCOazdzD7tQn7aMgdXrVCnbYykZ5DznjnxOPrm9V0YkqPuyAHS5KxLy/9tFduAic7roDR+vzTs7bWgeEdYQHFNlwQv8QzxCQR//LGK5k7Oav2Di6ugUZOTG61/qiB/MrBckWE2l+jw+dJzieNkzXlb5HGdPz40wQ+qipNAOe2FIvXgd0BOrH76U7rx9lT+Jgdwh/dN9mjYzGxMacciHRRU18fzz7JumnVQoQejFnjdI7DakiKSz/pQwI8/PQA0agQOlgrKNtAfdf2WISfuarhAq0u4o733oiJkdti8rz2NroNuaSC3/kxY70zK3Z3PdEZfAINXNoroLi x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(396003)(376002)(366004)(346002)(99936003)(36756003)(86362001)(2906002)(66616009)(166002)(6512007)(186003)(54906003)(38100700002)(6916009)(4326008)(15650500001)(6506007)(44832011)(26005)(66476007)(66556008)(66446008)(8676002)(83380400001)(122000001)(64756008)(966005)(76116006)(450100002)(66946007)(71200400001)(2616005)(478600001)(5660300002)(6486002)(66806009)(8796002)(316002)(8936002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VytoZ0k2K0N6WWI2bUN4NERmOWJJZnpQTnBEemxFa2NhWCtDaGVjYkc1NXIr?= =?utf-8?B?Qm1DWGl6NW91NEFwVXZFK2Fmd20vcUtrQkNKM3RnQVhOTGZjTmxadzlWSEE0?= =?utf-8?B?YUpBSDR6OEltS0RldGlzclFIQVBGb0VJQXlPVWZjcStHSzZlNVpaRVlmcWVF?= =?utf-8?B?MncwWkpzbmFDaUhsTkNCVlB6R1E3em54RjVQem54elQyNWZJWE9ReUNaUTNK?= =?utf-8?B?SHlWYmZneStZVEhUK2lYNDdQMEdnd2lUVjl2a21YWjBRYmlObklQQVhiWmVa?= =?utf-8?B?RmtCOHE5K29pNlNzVjlVWm01Q0xOelFjUmNlNVV3MDhjRUZFbDhsMnozK1JB?= =?utf-8?B?SzZiNVV1Y1Fvdk5va1pnZ2lXRmVHSW91RDkzMUVjWFJ4TmxyOVZHaHF1TFpa?= =?utf-8?B?YXVYa0R5ckl4eGovZ3JQL1k0aHZ1aVpqU0FJZm9acFo1NXBENUZyOFRvWFh4?= =?utf-8?B?OGhPRDhkWHA1Znl6cnR5VUE5QnJwM0pqamJmbWVMc2grQ3NPdndib00zaWE2?= =?utf-8?B?VTdvbEk4cXJ5bWRTcXlGRmxUc204QWZtNGoyQWxENlp6dThUSEh6bzltc2VU?= =?utf-8?B?dks4dHhUWUpyZUk2cWduU1RlMSs5QjY2RndsZ3NOdnZsb2hHYkN2V29wS0Vm?= =?utf-8?B?c1p0RWxaUGZvQW4wOFFmSkxSR0kxc3psNFJPeDA1SEtyVTNUK0xQbXFFNW95?= =?utf-8?B?a1ViS25jbWROMHVqM3hBWDhXeitlczVyS3htUjJ5d3pzMFQ2anNNZ0U0TSt5?= =?utf-8?B?SXZQeFh4ZEZBQlpVdGlxeDh2YWdpODkydHpkWVgvUVNIV3pqYkNySE96Nktv?= =?utf-8?B?RTI1eDI4YXBGcEtEK1B5MGo4b0VLNlliL3JzVHo1dDZPR0tkSHR0ZkpSdkV6?= =?utf-8?B?SFhsb2NCdU83aHFPa3ZJQUJkdTU4VDVnUzF0Ny9uRk95UDU1emZ4OUNTc2pF?= =?utf-8?B?N3NnTDJybUUzZk12TWRlOTI0bFpROXE1dG82dEpwbEtoazNTOUpnVG96dG5r?= =?utf-8?B?bjJBZnQzekVyU2I2OXRlZVAzUHdoaThEdjBCTzJMRTZWQWR6Y3hUTGtiR09P?= =?utf-8?B?LzE3YllBSUJCS2w1UG15L0Npc0FGRVhrNjl6WVlPZ25XZEZ1Z0xWNy8yZzBz?= =?utf-8?B?bzh5UCtEN2dLOTBnc3N5U2ZZVnpPQjJTbVdjZVA5L3lTd2lTZVVhZmJ1RlNY?= =?utf-8?B?RU9zUkJSemxhUk8wRHQxa3FINkcrV1FIelJXQ1VTSnN0V0VYa3pRRVJ5elhE?= =?utf-8?B?eFhoTW9xY0xIYUdvMDFxQU9XYU1UQ2NxZEphRHZvNVcvU2Fpa0I5dSs4OTVw?= =?utf-8?B?YUo4SFdGZ2VpTjgvb2pub1BuMHlEMU1tOXlQQStBUi90SGYyTTlzMzdUejJU?= =?utf-8?B?SWRxRnM0YjhHSFVyZHgyd3M4dDBkci9QckxiWC9PTytzSjFvSE1EQTMxYkVT?= =?utf-8?B?aEdDbmUzUmlJV2I1S1ZyZ2UvMlFsanI1L0FkaU4zUExXREQ4RE1lNzQ2Sksv?= =?utf-8?B?dGhTZk1MMldRKzN6dWg4aHk1UmgvSUV1dXZQRjMwT09Pd3VlQklKeFdXZkY1?= =?utf-8?B?ZjJKOGE2NkRXNnY5MXU5c1dYOWx3dUhWQitKaFluUlMyd01OYThiUklBTTdK?= =?utf-8?B?MFJ5R0RQNXJzZXBXRG5ZYjZYNjlwZHNLcU0zZUZtcDFqNW4yVUc0dHdZbGs2?= =?utf-8?B?eUdDNUY4MVAzdXA4WXJpeDY0eDRJa1RHdHhHOHdvRDFSc0xmWGMvMUV0c1JF?= =?utf-8?B?TFcrVDJqV1A3ektYTWJDTDRPazZFcWlJckxoZDhRNmEveXRxWWxSVk93U2c1?= =?utf-8?B?Y2ZuaFo5N3BNOGE3WkJ4UT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-TdekSvdb9VJwdaBdkLQM" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: afb7d7c3-3c25-4ba4-2d90-08d9452e950c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 12:14:21.9971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sBrcBziffzLgavPnH1TNOIGAIFJRmAqgEA1Yf5+5SvJ6xfcqffqthFhH/xM4NjQ00UMdSKn51O+DtRYcaY2J6habN1/AJnE+D/uRnhceS3I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: [dispatch] New proposal do declare SDP Security Descriptions (RFC4568) Historic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 12:14:33 -0000 --=-TdekSvdb9VJwdaBdkLQM Content-Type: multipart/alternative; boundary="=-AInXeuLXTfkSAlx7Uzjq" --=-AInXeuLXTfkSAlx7Uzjq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, John and I have a draft that proposes that RFC 4568 (Session Description Protocol (SDP) Security Descriptions for Media Streams) should be declared Historic. As the draft explains the security level SDP Security Description provide is not on the level on could expected by an IETF in force proposed standard and there exist alternatives. =20 We currently point this draft to Dispatch as we are a bit uncertain if this should be handled in MMUSIC WG or somewhere else?=20 Therefore we proposes that this draft is discussed on the dispatch list until dispatched.=20 Cheers Magnus Westerlund Name: draft-mattsson-dispatch-sdes-dont-dont-dont Revision: 00 Title: SDP Security Descriptions is NOT RECOMMENDED and Historic Document date: 2021-07-12 Group: Individual Submission Pages: 8 URL: =20 https://www.ietf.org/archive/id/draft-mattsson-dispatch-sdes-dont-dont-dont= -00.txt Status: =20 https://datatracker.ietf.org/doc/draft-mattsson-dispatch-sdes-dont-dont-don= t/ Htmlized: =20 https://datatracker.ietf.org/doc/html/draft-mattsson-dispatch-sdes-dont-don= t-dont Abstract: Key exchange without forward secrecy enables pervasive monitoring. Massive pervasive monitoring attacks relying on key exchange without forward secrecy have been reported, and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to long-term keys enable passive attackers to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Session Description Protocol (SDP) Security Descriptions (RFC 4568) does not offer PFS and has a large number of additional significant security weaknesses. This document specifies that use of the SDP Security Descriptions is NOT RECOMMENDED. New deployments SHOULD forbid support of SDP Security Descriptions. This document reclassifies RFC 4568 (SDP Security Descriptions) to Historic Status and also obsoletes RFC 4568. This document updates RFC 7201 (Options for Securing RTP Sessions) to note that SDP Security Descriptions SHOULD NOT be used. --=-AInXeuLXTfkSAlx7Uzjq Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi,

= John and I have a draft that proposes that RFC 4568 (Session Desc= ription Protocol (SDP) Security Descriptions for Media Streams) should be declared Historic. As the draft exp= lains the security level SDP Security Description provide is not on the lev= el on could expected by an IETF in force proposed standard and there exist = alternatives.  

<= /span>
We currently point this dr= aft to Dispatch as we are a bit uncertain if this should be handled in MMUS= IC WG or somewhere else? 
Therefore we proposes that = this draft is discussed on the dispatch list until dispatched.
<= span style=3D"font-family: "Ubuntu Mono"; font-size: 17.333333969= 11621px; white-space: normal;">
Cheers

Magnus Westerlund
=


Name:=            draft-mat= tsson-dispatch-sdes-dont-dont-dont
Revision:      &n= bsp;00
= Title:          SDP Secur= ity Descriptions is NOT RECOMMENDED and Historic
Document date:  2021-07= -12
Gro= up:          Individual S= ubmission
Pages:          8
URL: &= nbsp;          https://www.= ietf.org/archive/id/draft-mattsson-dispatch-sdes-dont-dont-dont-00.txt<= br style=3D"font-family: "Ubuntu Mono"; font-size: 17.33333396911= 621px; white-space: normal;">Status: &= nbsp;       https://datatracker.ietf.org/doc/draft-mattsson-dispat= ch-sdes-dont-dont-dont/
Htmlized:       https://datatracker.ietf.org/doc/= html/draft-mattsson-dispatch-sdes-dont-dont-dont


Abstract:
   Key exchange without forward secrec= y enables pervasive monitoring.
   Massive pervasive monitoring attacks = relying on key exchange without
   forward secrecy have been reported, a= nd many more have likely
   happened without ever being reported.  = If key exchange without
   Diffie-Hellman is used, access to long-term k= eys enable passive
   attackers to compromise past and future sessions.&= nbsp; Entities can get
   access to long-term key material in different = ways: physical attacks,
   hacking, social engineering attacks, espionag= e, or by simply
   demanding access to keying material with or without a= court order.
   Session Description Protocol (SDP) Security Description= s (RFC 4568)
   does not offer PFS and has a large number of additional = significant
   security weaknesses.  This document specifies that u= se of the SDP
   Security Descriptions is NOT RECOMMENDED.  New dep= loyments SHOULD
   forbid support of SDP Security Descriptions.
   This document reclassifies RFC 4568 (SDP Securi= ty Descriptions) to
   Historic Status and also obsoletes RFC 4568.

   This document updates RFC 7201 (Options f= or Securing RTP Sessions) to
   note that SDP Security Descriptions SHOU= LD NOT be used.
--=-AInXeuLXTfkSAlx7Uzjq-- --=-TdekSvdb9VJwdaBdkLQM Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCErYw ggX0MIID3KADAgECAg8BdlE9InYZOYLl1zGep4IwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMB4XDTIwMTIxMTA5NTg0OVoXDTIzMTIxMjA5NTg0OVowXjERMA8GA1UECgwIRXJpY3Nzb24x GjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCIT6U9ddUp UCEryIA27xtF8WsRAIfc5jBavfu0OGDmwITYYRD2PaMEdEK+I4dqz0f6xcCrDnBk2Xj+JxjhaRkq TAifJZima9WE2JoI/uq8UsS2HJWlhspAwKx1osARgtRiMjRZZyyfiRZLbgXHWYpnTt3i9QsuX/uo 9oZFWpDCbZee4Il9uldsUcuBLZx2PyZvBvC8KCUaBXsZX6bwV7hssRVn+BgFCuEievJMx0khTRVh i9goObxu5Jl44RtwbZNYB1UE1IzRWEZw+b3cEvXiQjPl2e3ytMZSmhy+IaKmjxES6ODiuh51KAcm PZfZIaX2djmD76YGi+ETmnb8Xm3dAgMBAAGjggHEMIIBwDAfBgNVHSMEGDAWgBQcexmel5x2rCA9 2NzjkWrj2y2mUzAdBgNVHQ4EFgQUICO/88T0EQvEUm5+HVt/d9Mm+Z8wDgYDVR0PAQH/BAQDAgWg MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3Qu dGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2Vy aWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQADggIBANRZXQy+lUW97uaL uApOixnDKLpUoz+N/5Owd/9illmbxQDEY1/pPs4KJSvw88p+F3bmOzb+fLUNa6Mi/2Tw83FzEVmO 3RqzKtca+I9GDpRQ8oWL7hrUPJoNacidSZLmAP4L4kwHIhvGNX4f1c/oB4fAkP/xZsAAxYi7nKxd XA2n/KMWNkezyB9BSsD8ZOS4pWU8UaZjd5r0fzqM5zQbU4EPqHa8jFMSMz1UrYXPKKxl6E4WA3TE w1oLjcli0NWGQHyQ+3Kh7fe6zPoXfLd/2EQjr2o76ssgoqd2V1Mx5TRHdUyxjIMPEOVYpvcerNUB hEBkaOQ9FugYcMhMc8BF7nQZq+hsL/T7idg4gE2sEfNdK9RBf/EVH10GMrmbadqTycztD1gUL3dV Qxik4TCMxIctt9XqtTGHaMewZLQAXp/sHWlU/vmz9brcuzYQ9YVd5hTendGMUyGhWPV/KvxouKPK zdrGeEqUQCeBwWgQASQNOrpTzMJwZAV/Ww3ExQCjHvflvUQzVuU0sC6AEVkgqMATIXS6h6rjLL31 pjt2JV84XRjF5afYkcRIHTsrtcoWeFtOu/GpZNhtq+tde0QvnkSsjczMWU0gKk0hXBmXwEGUimuD Vq/Wvr0mr18d9mKA6xPNQOfn/VL5CWXa11OtOjj8WsTy3XUpyJ6dc9Z72TmKMIIF9DCCA9ygAwIB AgIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEy MTEwOTU4NDlaFw0yMzEyMTIwOTU4NDlaMF4xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFN YWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiE+lPXXVKVAhK8iANu8bRfFr EQCH3OYwWr37tDhg5sCE2GEQ9j2jBHRCviOHas9H+sXAqw5wZNl4/icY4WkZKkwInyWYpmvVhNia CP7qvFLEthyVpYbKQMCsdaLAEYLUYjI0WWcsn4kWS24Fx1mKZ07d4vULLl/7qPaGRVqQwm2XnuCJ fbpXbFHLgS2cdj8mbwbwvCglGgV7GV+m8Fe4bLEVZ/gYBQrhInryTMdJIU0VYYvYKDm8buSZeOEb cG2TWAdVBNSM0VhGcPm93BL14kIz5dnt8rTGUpocviGipo8REujg4roedSgHJj2X2SGl9nY5g++m BovhE5p2/F5t3QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMw HQYDVR0OBBYEFCAjv/PE9BELxFJufh1bf3fTJvmfMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzApBgNVHREEIjAggR5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIG CCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBI BggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQDUWV0MvpVFve7mi7gKTosZwyi6VKM/ jf+TsHf/YpZZm8UAxGNf6T7OCiUr8PPKfhd25js2/ny1DWujIv9k8PNxcxFZjt0asyrXGviPRg6U UPKFi+4a1DyaDWnInUmS5gD+C+JMByIbxjV+H9XP6AeHwJD/8WbAAMWIu5ysXVwNp/yjFjZHs8gf QUrA/GTkuKVlPFGmY3ea9H86jOc0G1OBD6h2vIxTEjM9VK2FzyisZehOFgN0xMNaC43JYtDVhkB8 kPtyoe33usz6F3y3f9hEI69qO+rLIKKndldTMeU0R3VMsYyDDxDlWKb3HqzVAYRAZGjkPRboGHDI THPARe50GavobC/0+4nYOIBNrBHzXSvUQX/xFR9dBjK5m2nak8nM7Q9YFC93VUMYpOEwjMSHLbfV 6rUxh2jHsGS0AF6f7B1pVP75s/W63Ls2EPWFXeYU3p3RjFMhoVj1fyr8aLijys3axnhKlEAngcFo EAEkDTq6U8zCcGQFf1sNxMUAox735b1EM1blNLAugBFZIKjAEyF0uoeq4yy99aY7diVfOF0YxeWn 2JHESB07K7XKFnhbTrvxqWTYbavrXXtEL55ErI3MzFlNICpNIVwZl8BBlIprg1av1r69Jq9fHfZi gOsTzUDn5/1S+Qll2tdTrTo4/FrE8t11KcienXPWe9k5ijCCBsIwggSqoAMCAQICEFO4foPhnJko k7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe7 2FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh /VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98M vWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmd vkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7 zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP 1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3s p0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25a EvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUU kBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4IC AQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNM Vek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7 m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HT CIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNM MbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7 DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPN mJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKa kDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i 0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+W kDGCAsowggLGAgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwDQYJYIZIAWUD BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcx MjEyMTQyMFowLwYJKoZIhvcNAQkEMSIEILBP5ec0hoElZLSnQgahe2PZweKWJgsQDSu6rsQuuxbe MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBABWTi3teUyq1KxMHbe0oR3ohOXept0hfr53hAY9o/3rbh938Z6yS+Z/UChan3MYbbChY MER7rjRfOOX9y9aLfpJZ4mPG1E16NkdZhxMDFWY5bAteMAS8bnDUdJa1DoC7ZKLYa3chu52mgiKC rPSka9yJvBQQHh2OberK5hCcqpb53dnUgXok3LmieySJcYTtda6mDIClSx22c+hGq1XjA/ZkPEtF r/LsFxDL0/SgY+S18GRao5dqfp3jHPigMDj8X5XIS9IgUAS4WiK9ZjU6oaik4DCgyV3lpz874qYX 7Rtmi+03vyjwZZGn7hPO17bbMg+Kn6EsxcWLIZ4ccI1sUloAAAAAAAA= --=-TdekSvdb9VJwdaBdkLQM-- From nobody Mon Jul 12 06:02:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC483A1714; Mon, 12 Jul 2021 06:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2O4j3TQNFv7; Mon, 12 Jul 2021 06:02:37 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B503A173E; Mon, 12 Jul 2021 06:02:19 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id x70so13501095oif.11; Mon, 12 Jul 2021 06:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JKQPYvrO0t4MzxTtE2afA2WgvDSMRQfo3W5VStGHn18=; b=XizxLu/k6wWB3LkTuL27HLqXx+vVJAMybCwtfnpiPM//GgXa9cRGJoZTUDiFeDmLZ2 lUK6xBDkfy+qYGGNoSTwmT1uM/w7D2ZQJFMFnRKP+Xq9fkRGBby0OW/JRPAHoMKeJgVW NrK9bSAiYVnyo+IbEXbJAhQ73KTjfz9bi0VMyYS6NlBjx/TnMsyw/NyyMlR+nKPk7GXn Cizh+OjH1ev4kqYVZM+1j4c8xYIrjB2n+ia7J3RbldtfeH5tsHjWLIs4gi2HbhfdsKgJ tYhpXkMAiR0DWF6QKkP5mf9tgYUmFMEm7obOdQK8As8hmaLPTXkyAY4gxbW+HyMUyzq6 Kx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JKQPYvrO0t4MzxTtE2afA2WgvDSMRQfo3W5VStGHn18=; b=IqN3Zo7fcwZLpTtGqU9e3iJz++FvKH+pdDs6gIx7CHfc0eUCvIe1inHttknpVgs+iO IHR2Gm/oNV5PmiDnlfI1G+x+TvM3hBeTIm0LvAwWF3XX0mWP7n5dkywlYpCHG6UYZz4Z Y8FI4gYaX1qGCTBOzAUW2BLqEik/G2ib9InmfbIDuWBh5Q1JOGuYjLaxltv4+bZDa9f1 bsTKcn7WHZaFVKmD89Ic1OmNi4TGI3mFttsXbNLk3eKjzRXn6/5bghWQWn3yH3z/ZnNm Re7iiPtrKKtz1V8hMLuegj9l9zg5e/eAlkxGGM232wvmiks9kUfMTyCGTZx5ZwbEtf2h zOmQ== X-Gm-Message-State: AOAM531q/YGA04JGq/U/6G1gFXxkfcD7bTn4BwQ050BNGbHPPIU/VtxO fRhgPVZ9275j9jSXwLvFVqPaa4+EdxXPttYVS/9SengxvaimPg== X-Google-Smtp-Source: ABdhPJy/KfOwoqycVCgmjfOvTMo80NjqyaZ0u8fLoXl1uT3Irz5WQ60HSQOWrGSyX2SHHSYitEZVxAYqXklFAeB0zLc= X-Received: by 2002:aca:acc5:: with SMTP id v188mr10192145oie.167.1626094937688; Mon, 12 Jul 2021 06:02:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Mon, 12 Jul 2021 14:01:51 +0100 Message-ID: To: "dispatch@ietf.org" Cc: "mmusic@ietf.org" , "avt@ietf.org" Content-Type: multipart/alternative; boundary="00000000000021cc6c05c6ecbbdb" Archived-At: Subject: Re: [dispatch] New proposal do declare SDP Security Descriptions (RFC4568) Historic X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:02:49 -0000 --00000000000021cc6c05c6ecbbdb Content-Type: text/plain; charset="UTF-8" Hi Magnus, This seems like a reasonable work item for MMUSIC to me (and a reasonable goal as well). regards Ted On Mon, Jul 12, 2021 at 1:15 PM Magnus Westerlund wrote: > Hi, > > John and I have a draft that proposes that RFC 4568 (*Session Description > Protocol (SDP) Security Descriptions for Media Streams)* should be > declared Historic. As the draft explains the security level SDP Security > Description provide is not on the level on could expected by an IETF in > force proposed standard and there exist alternatives. > > We currently point this draft to Dispatch as we are a bit uncertain if > this should be handled in MMUSIC WG or somewhere else? > Therefore we proposes that this draft is discussed on the dispatch list > until dispatched. > > Cheers > > Magnus Westerlund > > > Name: draft-mattsson-dispatch-sdes-dont-dont-dont > Revision: 00 > Title: SDP Security Descriptions is NOT RECOMMENDED and Historic > Document date: 2021-07-12 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/archive/id/draft-mattsson-dispatch-sdes-dont-dont-dont-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mattsson-dispatch-sdes-dont-dont-dont/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mattsson-dispatch-sdes-dont-dont-dont > > > Abstract: > Key exchange without forward secrecy enables pervasive monitoring. > Massive pervasive monitoring attacks relying on key exchange without > forward secrecy have been reported, and many more have likely > happened without ever being reported. If key exchange without > Diffie-Hellman is used, access to long-term keys enable passive > attackers to compromise past and future sessions. Entities can get > access to long-term key material in different ways: physical attacks, > hacking, social engineering attacks, espionage, or by simply > demanding access to keying material with or without a court order. > Session Description Protocol (SDP) Security Descriptions (RFC 4568) > does not offer PFS and has a large number of additional significant > security weaknesses. This document specifies that use of the SDP > Security Descriptions is NOT RECOMMENDED. New deployments SHOULD > forbid support of SDP Security Descriptions. > > This document reclassifies RFC 4568 (SDP Security Descriptions) to > Historic Status and also obsoletes RFC 4568. > > This document updates RFC 7201 (Options for Securing RTP Sessions) to > note that SDP Security Descriptions SHOULD NOT be used. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000021cc6c05c6ecbbdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,

This seems like a= reasonable work item for MMUSIC to me (and a reasonable goal as well).

regards

Ted
<= br>
On Mon,= Jul 12, 2021 at 1:15 PM Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org= > wrote:
Hi,

John and I ha= ve a draft that proposes that RFC 4568 (Session Description Proto= col (SDP) Security Descriptions for Media Streams)=C2= =A0should be declared Historic. As the draft explains the security level SD= P Security Description provide is not on the level on could expected by an = IETF in force proposed standard and there exist alternatives. =C2=A0=

We current= ly point this draft to Dispatch as we are a bit uncertain if this should be= handled in MMUSIC WG or somewhere else?=C2=A0
Therefore w= e proposes that this draft is discussed on the dispatch list until dispatch= ed.

Cheers=

Mag= nus Westerlund


Name:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-mattsson-dispatch-sdes-d= ont-dont-dont
Revision:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A000
Title:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0SDP Security Descr= iptions is NOT RECOMMENDED and Historic
Document date:=C2=A0=C2=A02021-07-12
G= roup:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Individual= Submission
Pages:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A08
https://www.ietf.= org/archive/id/draft-mattsson-dispatch-sdes-dont-dont-dont-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://datat= racker.ietf.org/doc/draft-mattsson-dispatch-sdes-dont-dont-dont/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>https://datatracker.ie= tf.org/doc/html/draft-mattsson-dispatch-sdes-dont-dont-dont

Abstract:
=C2=A0=C2=A0 Key exchange without forward secrecy enables = pervasive monitoring.
=C2=A0=C2=A0 Mass= ive pervasive monitoring attacks relying on key exchange without
=C2=A0=C2=A0 forward secrecy have been reported, = and many more have likely
=C2=A0=C2=A0 = happened without ever being reported.=C2=A0 If key exchange without<= br style=3D"font-family:"Ubuntu Mono";font-size:17.3333px;white-s= pace:normal">=C2=A0=C2=A0 Diffie-Hellman is used, access to= long-term keys enable passive
=C2=A0= =C2=A0 attackers to compromise past and future sessions.=C2=A0 Entities can= get
=C2=A0=C2=A0 access to long-term k= ey material in different ways: physical attacks,
=C2=A0=C2=A0 hacking, social engineering attacks, espionage, or b= y simply
=C2=A0=C2=A0 demanding access = to keying material with or without a court order.
=C2=A0=C2=A0 Session Description Protocol (SDP) Security Descrip= tions (RFC 4568)
=C2=A0=C2=A0 does not = offer PFS and has a large number of additional significant
=C2=A0=C2=A0 security weaknesses.=C2=A0 This document = specifies that use of the SDP
=C2=A0=C2= =A0 Security Descriptions is NOT RECOMMENDED.=C2=A0 New deployments SHOULD<= /span>
=C2=A0=C2=A0 forbid support of SDP Secu= rity Descriptions.

=C2=A0= =C2=A0 This document reclassifies RFC 4568 (SDP Security Descriptions) to
=C2=A0=C2=A0 Historic Status and also ob= soletes RFC 4568.

=C2=A0= =C2=A0 This document updates RFC 7201 (Options for Securing RTP Sessions) t= o
=C2=A0=C2=A0 note that SDP Security D= escriptions SHOULD NOT be used.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000021cc6c05c6ecbbdb-- From nobody Tue Jul 13 09:53:10 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2183A0C7D; Tue, 13 Jul 2021 09:53:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kirsty Paine via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Barry Leiba , Ben Campbell , ben@nostrum.com, dispatch-chairs@ietf.org, dispatch@ietf.org, iesg-secretary@ietf.org Message-ID: <162619518815.21132.5391978015568875531@ietfa.amsl.com> Date: Tue, 13 Jul 2021 09:53:08 -0700 Archived-At: Subject: [dispatch] Publication has been requested for draft-ietf-dispatch-javascript-mjs-09 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 16:53:09 -0000 Kirsty Paine has requested publication of draft-ietf-dispatch-javascript-mjs-09 as Informational on behalf of the DISPATCH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ From nobody Wed Jul 14 05:51:46 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D473A1211 for ; Wed, 14 Jul 2021 05:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDa5K0-C-_Zt for ; Wed, 14 Jul 2021 05:51:39 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110102.outbound.protection.outlook.com [40.107.11.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEFA3A120D for ; Wed, 14 Jul 2021 05:51:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7nr72lqYu+r1tdMlxYr3oCTxFj34hXsj6xUXCDM59UGmXrPdYjEzSlbuQIL1ND8gxDTdLJR+7djyeHiZIdD2SqTI8WQ84IRFy63AMrhuSCiXtrvtItmiPABN+ELb867G6ueo6PI4UktsllZj5VVDTVxXtomJwJ03iyHbqMXu7HEUHsVuxTCpJsZN0gVKEYT/LxKWf1SjFf5hkASvuhblnCvUjOxRaXEF/rb+ChHWrSLtEKkx0LevmHmHMOmWeDIWzYm1Ae6jkyrZViqWyaI+7ZFMQTAlQJbo1RefodDbRsFo/F5sOOdtOrwu6tf3FkmBAQmViFH3AgJWozODT74+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h2P3/IgLaXp6WF3cGLtN4c6P/iT513EdTAZFOgJh59A=; b=N3gzWye52l071GMpSMPyYPsd0qplukZgemuGu3iT1JGZ5L+X8vSqZSgzxTRPGBi81j/oLX4WceNmzUADT4VhGeLazgOMGJjrnso+SluqIt7FZgPVeEZxAHfl6vViEBZUchuUWOzuZUiS9LbAn0YiFeG+h5fjA9eBUWW1xQ4XuwttDbHUkyxfebBrOvmOaySRoNoO18MHJdPdJquQWbghzmAjOFGfA5ZcHfYXdOH0HTvWxSF6xzHA56BHsCpMTNtyljO3S5YqDO8jcK1owcLaJNZSU7fnnFqUoYdZ/TjEgxg0dnEHNamGYeu7NPnjAZhQZfjWAEoXb7XRVzPhYgEgCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h2P3/IgLaXp6WF3cGLtN4c6P/iT513EdTAZFOgJh59A=; b=O+w8jnq1YAGsmejHGsPAz2qtCZ3Z3DHNj1DR5ez0DTCo56HitAMiSCXdwLf2iOITGW9/BUH5SHAJbS18jmO9UcF8DP+b8Vm1veSlbKwqk4ylw5oDuKZzs8g+2Q8ctjkCwtHbFlZoSqvDCrO43Wh/QVIpEizPbFDwPArlNCOV3NuZgKqOZEdQ+9l1u4xs8nnXFvvI6OKpcMZYogC5HRxn4yRTkXVXGNdg9Ptk3+VpcpGxNS6qtqxxuTsxTgXrO9A+8HWbce7zRiHvOxU4gF409t9z/AYh/cHiZUQTDlvnm0vzIPOV5J6ZYihyupMVT7FVFmOfCbGTaruqu31VDWOxSA== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LOYP123MB3021.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ec::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Wed, 14 Jul 2021 12:51:37 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01%5]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 12:51:37 +0000 From: Kirsty P To: "dispatch@ietf.org" Thread-Topic: IETF 111 DISPATCH draft agenda Thread-Index: AQHXeK7b+h/WJ68yskmIE6PSgC/vPw== Date: Wed, 14 Jul 2021 12:51:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df020c47-110e-4faa-a3f8-08d946c61e16 x-ms-traffictypediagnostic: LOYP123MB3021: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: l3gn7cGdA7a6rNCU7l3aYJmCubNVU5v/iqvfF8C37EJZLn2SVImvQmf41CQL1gxsUSXNVgTvS2FSUGAo59SWPbCBV5qtGgQkQpUss/DEqXJVGaiI/RKDMiGHsKYztT7Gm5STKWqkBePoZxOzGPfFcN65eW8R1Yp+txf8fc/M8J976piV2ccMtktuyVwla005U1z+z+vImB8IdoLshppG9ibsKI9gID4ttlSUw2P58sVXsianVzYQZJyLogpAjTGN2Ha7+TezyxF7FwoldnNNOkbv6Q13dGr0bh8rQF9VE4KYJ7bd5/RVdS3tomMxHQgX1N2gL5aU3WgxO9wElKpVMpCnjdJQ03IeW2D7F6KU9K2qnHFwfyPP/0mTY6RO4yLyKEHVB108zbwF9Pvh8G6K6UJVKpLpPx4O3XD5obl9nwLLK4JENKUZC+BvC8RdpSUd6pcqSreK0jznSeFt9ci2d/pE0/0f0DKlonxwqYXDD7IdD94XVm5oys6zEkHkDOeeLZ+bYGAJqjDz1L445oNhIFgCQFwaYu+YvZwJGmCeCYWby2EILp5sCgdBkd2XGxG3iryQQo0pxD1XSZz0MaAzLRn3JAe9qXyMFmWEdJcA7JhOanwkPneVKP2w30eZrK3v43QpzxxeCV8yd3ia0YEzKjMvHIt8aecmkvo9nsIateQhw389aihhszvrWU0OCt+UoI6VVmfgaZf+INBHoWF4Tt/YdHaNJuNmmZYi551ER7X2LCEPOkYlYUf8NHLk4v2izJVvywSZqh+OgVvPpFhi3s206uzsm8njtANeFtt4aik= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(346002)(396003)(376002)(136003)(83380400001)(6506007)(2906002)(478600001)(86362001)(52536014)(5660300002)(8676002)(6916009)(9686003)(122000001)(33656002)(966005)(66446008)(19627405001)(4744005)(66946007)(26005)(71200400001)(186003)(55016002)(66556008)(316002)(66476007)(7696005)(76116006)(38100700002)(8936002)(64756008)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?/QNZqfdxfFAK0dyXmuOOhqXzeRmfRTm5LPXXn/AImloiHxy2x19fza/EsZ?= =?iso-8859-1?Q?UK5i4lJ3RyPYuQ/5yT+SABeu7PKhpJvQeZWpm1r1fyR+kN7rNNl3+r4mf1?= =?iso-8859-1?Q?YfinShkiNH8gzoc4jtxGjpDSW20d9dgiAml4H7h9bwjR9XUQyGMqaKfuXZ?= =?iso-8859-1?Q?oWOWNPHRsG9ZLvv0fHl9ibUbE8NnTQqoBhLkHTOGn9b5KjNM5jUb9d1StJ?= =?iso-8859-1?Q?NVlInZka6r9r1PJTG20LsrzFJiA1IAfETT0TUTKClDiS08uNvOtV18KQcg?= =?iso-8859-1?Q?/3mVwJZ1sbE+I1X5BrUz2WxWuwrAswV3M2TqMtkZpu5sKrQn5wfacxQYOT?= =?iso-8859-1?Q?CCYZBwjfTypoT1paGo9Hki1iVwE6cDQRHUnzSoBDOGPf+5SJ6NTVq5mzhT?= =?iso-8859-1?Q?0S0b6KUJAdjXYd35TUQEHyr4hz6k05FR8u55XgDnxNuUXyUgrI6QNFdF09?= =?iso-8859-1?Q?ZKy4uEZRz2IW0Pr+oUaailma3QrZrL14Tax3sJP2cxpg4Zr1k4wGHIq9xD?= =?iso-8859-1?Q?iNurzhLCqUybno/ysjjVuzlLGLiMEBOz/iQwhHKnUFiKTo6Oiry5FmFm0A?= =?iso-8859-1?Q?GDUoeJcOIgfPVSs4OkGEZc7MMbhS4GtpjDhj3dIBtRvOq0MPcGgroT+l8s?= =?iso-8859-1?Q?uv4QihwEwrcH9GbH71FNT9ObYG2c4Do4lcGgjVs1vs5CIBHZvkIDU5Xhdr?= =?iso-8859-1?Q?/YpQ7FhqaiofHAOumVpRZsG2tc76Q5TWyTbjf/3MhwT/g3Bgb9f2pdr+vp?= =?iso-8859-1?Q?UHPU8pyqvYzsiI70JthQDSv9nEQ5wPkBGYLKYydl1CvcftFrHcX7JAR3SL?= =?iso-8859-1?Q?HxGAjeH++Ij1MKLE4QyvMpo5bRzAtwrU5RutJO/kuBDK9TkMdVQyEddAUP?= =?iso-8859-1?Q?vVZEOtIYJI6jV9E2EnFZ6IK4c9VX2bOR9AK4Kl+J5vLPDStWb7RYRCXO/W?= =?iso-8859-1?Q?0llLZe3mBVmFsxSCj1+eHTbwLRanXUJfSZJoKkchY4ClTITWjz0ny3C5Ob?= =?iso-8859-1?Q?Uur6fKaTez5PIdVVoaQkdCgMPlJukVSvrZIqFPz783y8ph0SNVjRwN+ztS?= =?iso-8859-1?Q?4qWTVwIa5lNxhpY0muWQDp0L4cZjXADLfPAatfzmfw6HMCDUysJ8uTstHH?= =?iso-8859-1?Q?UhVM8AIHx53TT3NznWunUNqfwwzQf0WI59ODGEFrontx5yyaEZb2423NbB?= =?iso-8859-1?Q?FjsJwfgFRMMaeAnA0vwHzQMoDfUdCPknBFco7p63tK/8oEe0SkTAr9/ZZB?= =?iso-8859-1?Q?AKHX9zBLqhV1DObDtEXrZLaECV4WxdrFjFt7bqSc71vx+dVy/UtlxdjrOc?= =?iso-8859-1?Q?SWDV7CaDM38PceefwAdXmJrEzKqsXZlco/rYKVTJnByMU+kzkdQGoZKaOR?= =?iso-8859-1?Q?3OCSJ7xuJQ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB359961D18D1E3CAC79B3CB6CD7139LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: df020c47-110e-4faa-a3f8-08d946c61e16 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 12:51:37.0789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xT8pKKFNci7ur/W/UDHNVIYtVluks+XCcBdMyhBCPk1yKzjl95opi+bxAQkE0+bL8//JLG5+cJsrX6Xt7DHTCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOYP123MB3021 Archived-At: Subject: [dispatch] IETF 111 DISPATCH draft agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 12:51:44 -0000 --_000_LO2P123MB359961D18D1E3CAC79B3CB6CD7139LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi dispatchers, Our draft agenda for IETF 111 is now up - please let the chairs know of any= corrections or omissions: https://datatracker.ietf.org/meeting/111/materials/agenda-111-dispatch-00.t= xt We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://datatrac= ker.ietf.org/doc/agenda-111-dispatch/ Kirsty & Patrick This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359961D18D1E3CAC79B3CB6CD7139LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi dispatchers,

Our draft agenda for IETF 111 is now up - please let the chairs know o= f any corrections or omissions:
https://datatracker.ietf.org/meeting/111/materials/agenda-111-dispatch= -00.txt

We'll update the list if it's updated, but if you want to check for yo= ur own peace of mind, you can always find the latest agenda at: https://dat= atracker.ietf.org/doc/agenda-111-dispatch/

Kirsty & Patrick

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359961D18D1E3CAC79B3CB6CD7139LO2P123MB3599GBRP_-- From nobody Wed Jul 14 06:48:40 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DDF3A1787 for ; Wed, 14 Jul 2021 06:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.596 X-Spam-Level: X-Spam-Status: No, score=-17.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADZUKuRFTepT for ; Wed, 14 Jul 2021 06:48:34 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C193A1786 for ; Wed, 14 Jul 2021 06:48:34 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id g19so3215851ybe.11 for ; Wed, 14 Jul 2021 06:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4RUZ/1TdCtz50V4EJFUaxA/JK/hH2Uq/66CBaXVThR0=; b=MINmwYNci65ew8Nm9vvgt5cv/TliO/8Ixp99kchpkE7pm+9iiDO1oXn4UdwwmuDfq5 pYDXq3Zh/8ub+U6E3TBm8YYA9J3xmtRxJAJ9ar1/RzdIC4aWGwMyoQd6RGd4UPAsxzcz cuCICh36WsRF032fgKUnmICfVRi1U1BCCLs9wV1wIK3k1JB6uBpzT8/CydGmN45uJmph haHVSoyLUBdbYbj7d5mUreeravy87+Ej/dqupcbMwNIQRsD9+6ySYMGvOodXMdlfMT+U I16c2aF4tPucl7IbeTXFf9pttrJWSAFOvj8dunVx2l5VhWAsrSmC/feu5XDBhtVtAOLi kMIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4RUZ/1TdCtz50V4EJFUaxA/JK/hH2Uq/66CBaXVThR0=; b=ZD7Nxa2DZHyxWBv6mt/kog9shsiv9lns4A/hFuoqnwPSHHfSspTRJIZAXrrZycLOwl 3djCiR4Yoz+Kf3K5YMBkDc70wjgPKEt/lH64oJSdh8frrMDNfV4nkOgt/UphW2yoOliH 5xjFTeANhe9QCDd/u/2MrXYdVSoRdffrT2wEcLQsAS2vcIaLGc6j9bIcAlNWIiLvP98x +D+Iu59PHfs6yx8AekFJY7zvZkqY9Sm2KNlWAOG3anZr3fmAFWObCRoa+9ahTdincoQI niDvSOIECrNNE5E59Dl465itwswODIbJ7twZSd0MsdSoqiLRvFbYq9Z9dz1Cokx88PZ7 rRuw== X-Gm-Message-State: AOAM533WAEy0xEehIXGxLBpbDqYjF5tDi9EL1f6hZfYJc1T/EgwymJVE hLHiX9wPqOBfoUKdoXxveXFBWCzl3VyhwVbag3jyog== X-Google-Smtp-Source: ABdhPJxuu//bOcQ6sJvnq8ZtJR+7v9b3Rmb7viuwKiouvFZoewr2Qe3VBKAbjEtD1IpguiE8JmxpBs9EqBw5W1EaqQg= X-Received: by 2002:a25:9942:: with SMTP id n2mr13898204ybo.230.1626270512669; Wed, 14 Jul 2021 06:48:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mathias Bynens Date: Wed, 14 Jul 2021 15:48:21 +0200 Message-ID: To: Kirsty P Cc: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037bf4305c7159cb0" Archived-At: Subject: Re: [dispatch] IETF 111 DISPATCH draft agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 13:48:40 -0000 --00000000000037bf4305c7159cb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should draft-ietf-dispatch-javascript-mjs be on the agenda? On Wed, Jul 14, 2021 at 2:51 PM Kirsty P wrote: > Hi dispatchers, > > Our draft agenda for IETF 111 is now up - please let the chairs know of > any corrections or omissions: > > https://datatracker.ietf.org/meeting/111/materials/agenda-111-dispatch-00= .txt > > We'll update the list if it's updated, but if you want to check for your > own peace of mind, you can always find the latest agenda at: > https://datatracker.ietf.org/doc/agenda-111-dispatch/ > > Kirsty & Patrick > > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer an= y > FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown > Copyright =C2=A9 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000037bf4305c7159cb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should draft-ietf-dispatch-javascript-mjs be on the agenda= ?

On Wed, Jul 14, 2021 at 2:51 PM Kirsty P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> wrot= e:
Hi dispatchers,

Our draft agenda for IETF 111 is now up - please let the chairs know o= f any corrections or omissions:

We'll update the list if it's updated, but if you want to chec= k for your own peace of mind, you can always find the latest agenda at: https://datatracker.ietf.org/doc/agenda-111-dispatch/

Kirsty & Patrick

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncsc= infoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000037bf4305c7159cb0-- From nobody Wed Jul 14 06:57:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0833A1846 for ; Wed, 14 Jul 2021 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR_lKeUNR_Bs for ; Wed, 14 Jul 2021 06:57:41 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110135.outbound.protection.outlook.com [40.107.11.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2A43A1843 for ; Wed, 14 Jul 2021 06:57:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F6wPJrU1YX8CNjRv5bVl4rkwOZHT0XXNlaykZtdwfpH3527ICIHTQ4c23w64+t+ZhvOnZXYQKD5h4V6G4WEEk3WNjVfYvHXAb9enS3B9yk7gquE/F0jB+bdyE+6YsRy167+GF0UQ4OqaWkNcuN8b9gz6Q95hJRvDCC6uFTNdwbe5d8km6O7MbX7MCqo4N5TGFcyBx8iqdNvpPAxsR3lji+2AOt37W01vOwVbTVNpHhvBJZpXGyi4YX9ChiTT+ebdaj0k/qTP522QVxUtsZgDBSELsT1QvBoQxPre6DiwPQD/PNNivBZx5tbiMj3U6wteZl7VtHBKOZ6ccOVpMZAp4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S2USsRj4pBAxInrBXPBpDV+M8qILLDdrof1P5VDewFQ=; b=gqfcgF6daG+1weiDwUvpd8BMA2+Dhdx+rhZMpA4aZd372UsyE3dQUTIyirSMLie8x8XpHy5AKBFrznBjQzWIkN1awA2tfKqY1uwIfv+/oDM7RFN6dv5qx5JolGcAOHjDdXu1E6mZ/WrwMNieGkEa4vdeClhSUPbUgGNbfq1+3cTACDjy4LjjRPKJcZlij5UdNOWEQaceO+LqehlS5HaELqwL0g0TI2Q2EtJKoi5QPqjj3Hx3T9k0sAuENlJohPrDiUObhkmi2sWW1eH9vUGtsGfGnEocaFDTuiBTGVEHAJ+SyqF14uoeeye48NNHPLn7PVRt6yAXc5tAsIf3Rze2jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S2USsRj4pBAxInrBXPBpDV+M8qILLDdrof1P5VDewFQ=; b=po0UBwXH6N1WVXP/WHdy5Q7Q6GVeIe6NLu6wZhld73wPXXnsMh16sR6YcF61SpUs8YrtcyeinmMFJKFM4/Cc1/v2OWRJmpX70hrVZw2opXvD6fHwbRA4i9iuzFCPOBI/09HUysD7TMAm23IH7CXg+SBW8xlUA4Vci2AMtxaDRU2HYHXEn7kXowIXiI+5YvR+mBFygQxJji/fsu3/N5kYKmi8bVOc371zTnbxOQRdpuBVQKrFpoMgZQwxkTDwupZE9G+bLnjuGF0Hfc9cJk8Z55zF1l9gYozVpPVc/Lu1wCXR/PQj8WoR8OSohsyXttP4+LVafup11GyTwQWjB1/ITA== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LOYP123MB2816.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ef::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Wed, 14 Jul 2021 13:57:38 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01%5]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 13:57:38 +0000 From: Kirsty P To: Mathias Bynens CC: "dispatch@ietf.org" Thread-Topic: [dispatch] IETF 111 DISPATCH draft agenda Thread-Index: AQHXeK7b+h/WJ68yskmIE6PSgC/vP6tCfHOAgAACCCs= Date: Wed, 14 Jul 2021 13:57:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3516dda-5f3a-465c-cd0f-08d946cf572a x-ms-traffictypediagnostic: LOYP123MB2816: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: emZ9+C5Ayovh79pvt0K2GJK+I967BGALgNn9hKGrZ70T8f2XMFUmNo/QPDs9ZK9NzCbcvVi2xOz3sdGlvznVxH1LSSJnLStuHa53VaccfGbfcJcxWs8YkrY89u8rFLAvfNpua/nMfIJGT1J4Xi/NTVt5IhRoUniUibt296aBd9YG/isQ72J5SZ8I9NpnBLndJTh+NTaoAp0PKxJfaGhzWX/DWtuxbK+52JkIOsypu2CNVMoV7LqmSfGQC/Wa8+pHZGBkN3v70LESK5VWb1rTxbI+UOPOxt5L2DBZB2qR01NKGg+Nah6PEsisft09NAEkF114rxCj9gtOi0WfMw/YEl/NAtjlslin62fPypgUKyTKTfbhS4d0WFKY9aXH2hZ3xm04lpXUgZJdPuqyX8FlhkMjrGvaaVLjv8Dlp+6td2yd5OaLu/S9vIxFmlr6hcrnJQOTK3CCh5UaKXYwmrhj6QZGpc71KlECZ1ZmMWD82k7eSbbGrMU7QtOG8HjuYvNgkKY5vrdlDZ9AvJZ4WOiYtnnLbE4hqAjjx/hYUPChHNqykM1gVr3I0rdafGB7T5tOtI/viVSNqreazPEV4WcqYlLluM8EyCuqB6V4awWFhozQ+W42qTWlN1XZN5shPXv8MPN9TngJJZyIXq0ASaAke2tRkbNS9gXoBKH7y+R2x48Uw5qdyX7g3OdCZqlfSQYNzJZCSj0k8QOdNpvrARemdV5I0NwJC5g8M8+zU6AqGvNZUnc3sy2EYPDIXa5aUcCZVAtKuPdVLsz4uJ8ezQqZg1Uw3m1K0UeslF9U0HSnxUzh7q79zfEpX5MGLef8OMkr x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(39840400004)(396003)(366004)(346002)(376002)(8676002)(2906002)(76116006)(66556008)(6506007)(66946007)(66476007)(33656002)(5660300002)(66446008)(64756008)(316002)(71200400001)(966005)(8936002)(55016002)(53546011)(83380400001)(9686003)(4326008)(38100700002)(86362001)(19627405001)(186003)(122000001)(166002)(26005)(52536014)(478600001)(7696005)(38070700004)(10090945008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?pS3sSxInFzRNZowr1DDlY21ggfEDn6nCLJu3U2obPcdQZWmpQ0OV/PBmCE?= =?iso-8859-1?Q?/DpGKp8L1mfDn+p7eYEPqB1rC0AeSZDvjimS4LO//rfllPZPQf4bOPM01U?= =?iso-8859-1?Q?aOzPTcIcuH3p287G50srL467ZjhjKEBJj6SdtGfKvq9UdYxw+23NoRBvNB?= =?iso-8859-1?Q?kk6y2cfwfrcbrwNmgfPTAY8h98We178BILwolBQ5iXEPX2O5LAumhmdCr0?= =?iso-8859-1?Q?9Pcy8Fe/8+mc3xUihGf1i/M7HsvnSf8ScLDSI3wFc1BpXPXvbKZ/M9E+4a?= =?iso-8859-1?Q?987cdDK/VIk745iIZ2nK+HXvKg0OnCy9hm4EWpbKneq9a1B1Idz6XuZpD7?= =?iso-8859-1?Q?WNvjGLiR4aJkGgzoAU4vg+gdOreuXC3H2fDYLKB9+mg4QEnRHXlh5mC5HV?= =?iso-8859-1?Q?/4WV4eeJlVPcwf2VrtD9f/0Hw+lijus7tdbXWcZ4id1fTp+dQd2vB6eCq8?= =?iso-8859-1?Q?pXNStl5B4h4sS8UjfRnIBSeOM0y/fW8DQRRgBFA8AgXV1kWDJ3HVKptL1L?= =?iso-8859-1?Q?V2dcRb/cEfHWH0+WnaM+4Ve42xOBC0brkk0t4ofH0T8LctXYGqxp29Eqvc?= =?iso-8859-1?Q?0YHDHaqxE20HjsbcxHhcr12NMuhxpfOM/xVGbaaTsElJyjs9vHE3jMLm82?= =?iso-8859-1?Q?69glbxKRsY3IbXIO4qd4RFikDHtebtiOtL+Jk7m5l91JoL2JlRfhoGn4JL?= =?iso-8859-1?Q?fNV8PDijNbRvNXmgQaRjn3WlnuBQwdz5eTCpYvT65eVmjoyB02fM7iAAmw?= =?iso-8859-1?Q?EbL8B6DaxrWCc3aQyZt5BtoUZMwZs/n38xESVA1y+XgiwtmSYCABYtL15p?= =?iso-8859-1?Q?DPI9fLB7YR1V1lIhlG2aPEn1CYTBK/s4CoRZoF+AW3YQV1MhMAC4GUkpj1?= =?iso-8859-1?Q?d7vsRHpgLOHx93Zh2YB2MB/r0dL3bkPc1HUhXxKxKrurOBD7g5idglVX7s?= =?iso-8859-1?Q?reWPc968iQBejiurX0HO12JGzGkeqQP2OMP0Idq1afUVvX6k8d/aVlkG8J?= =?iso-8859-1?Q?8xI4Na4W19vDJqQSPXNqbN0+3Hs8dSDm5067MzbE/6MnNAGoIDhg6ZbwhJ?= =?iso-8859-1?Q?DiYRjBkvll2LL75z4aDd4vbxUMtEdMiqSySVJFGER/x4enhmETYLLfNtmj?= =?iso-8859-1?Q?s32h7bMacMniJGMLip8ckExx8aFv4pPBxgkdzNEnnFCZvazYF4oXXhVHwf?= =?iso-8859-1?Q?Hbu4RqpQ3i3xjUxXBlVWwpNBFJMU0U4Od3UZPevqmwDxPnYP5pcN0gXX5a?= =?iso-8859-1?Q?/273xqNmFyjvGJo7UaZTnUUdpZ9MdjMHmlpwRXt54WuzCw0YfMk/aTscSS?= =?iso-8859-1?Q?dZofh/1shBUjdEaJ3QxkZY0SEOQEdyLBWRlWeh+GSk6M6vhxPspUEA+ZUN?= =?iso-8859-1?Q?LSljG8bu9S?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB359946DC3BBF05E3B188B871D7139LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c3516dda-5f3a-465c-cd0f-08d946cf572a X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 13:57:38.3884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ql7u94c9NpJhuVYoOO6uBpmVWBIIo2kc+uYgRlTMnthGi/rh/+3yU/3iDANHfZYdenaZj4WjYWQiQOsR+6J4zQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOYP123MB2816 Archived-At: Subject: Re: [dispatch] IETF 111 DISPATCH draft agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 13:57:49 -0000 --_000_LO2P123MB359946DC3BBF05E3B188B871D7139LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathias, It shouldn't. We plan to mention it in the chair update section as an FYI t= o the group but, as it's out of dispatch now and with IESG, there wouldn't = really be much to discuss beyond that. Thanks, Kirsty ________________________________ From: Mathias Bynens Sent: 14 July 2021 14:48 To: Kirsty P Cc: dispatch@ietf.org Subject: Re: [dispatch] IETF 111 DISPATCH draft agenda You don't often get email from mths=3D40google.com@dmarc.ietf.org. Learn wh= y this is important Should draft-ietf-dispatch-javascript-mjs be on the agenda? On Wed, Jul 14, 2021 at 2:51 PM Kirsty P > wrote: Hi dispatchers, Our draft agenda for IETF 111 is now up - please let the chairs know of any= corrections or omissions: https://datatracker.ietf.org/meeting/111/materials/agenda-111-dispatch-00.t= xt We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://datatrac= ker.ietf.org/doc/agenda-111-dispatch/ Kirsty & Patrick This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All mate= rial is UK Crown Copyright =A9 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_LO2P123MB359946DC3BBF05E3B188B871D7139LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mathias,

It shouldn't. We plan to mention it in the chair update section as an FYI t= o the group but, as it's out of dispatch now and with IESG, there wouldn't = really be much to discuss beyond that.

Thanks,

Kirsty
From: Mathias Bynens <mt= hs=3D40google.com@dmarc.ietf.org>
Sent: 14 July 2021 14:48
To: Kirsty P <Kirsty.p@ncsc.gov.uk>
Cc: dispatch@ietf.org <dispatch@ietf.org>
Subject: Re: [dispatch] IETF 111 DISPATCH draft agenda
 
You don't often get email from mths=3D40google.com@dmarc.ietf.org. Learn why this is important
Should draft-ietf-dispatch-javascript-mjs be on the agenda= ?

On Wed, Jul 14, 2021 at 2:51 PM Kir= sty P <Kirsty.p=3D40ncsc= .gov.uk@dmarc.ietf.org> wrote:
Hi dispatchers,

Our draft agenda for IETF 111 is now up - please let the chairs know o= f any corrections or omissions:

We'll update the list if it's updated, but if you want to check for yo= ur own peace of mind, you can always find the latest agenda at: https://datatracker.ietf.org/doc/agenda-111-dispatch/

Kirsty & Patrick

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@nc= sc.gov.uk. All material is UK Crown Copyright =A9
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch
--_000_LO2P123MB359946DC3BBF05E3B188B871D7139LO2P123MB3599GBRP_-- From nobody Wed Jul 21 05:08:38 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3C3A136B; Wed, 21 Jul 2021 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYHcOUoSlYWm; Wed, 21 Jul 2021 05:08:23 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A1D3A1366; Wed, 21 Jul 2021 05:08:22 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVDqz5z75z2xK7; Wed, 21 Jul 2021 14:08:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann Date: Wed, 21 Jul 2021 14:08:15 +0200 Cc: anima@ietf.org, dispatch@ietf.org X-Mao-Original-Outgoing-Id: 648562094.3070641-59b4fd530bf8d450524f93895243ecee Content-Transfer-Encoding: quoted-printable Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [dispatch] Creating CBOR-based media types and content formats X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 12:08:29 -0000 We had interesting discussions yesterday about how to fix the media-type = and content-format registrations for CBOR-based anima vouchers. I=E2=80=99m growing a bit tired of dispensing the ancient wizardry that = is required each time such a registration is needed, so I started = writing it up: = https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-= types.html Comments and PRs very welcome. I plan to submit this as a -00 on Sunday; probably too late for DISPATCH = (but I wouldn=E2=80=99t mind some discussion over there as well). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 21 15:14:42 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D65C3A2C6B; Wed, 21 Jul 2021 15:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6naqcZxdG1R; Wed, 21 Jul 2021 15:14:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2642B3A2C1C; Wed, 21 Jul 2021 15:14:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 60BE9389F9; Wed, 21 Jul 2021 18:17:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3u9iGLUaXZd8; Wed, 21 Jul 2021 18:17:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F4E838A01; Wed, 21 Jul 2021 18:17:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 612CE54A; Wed, 21 Jul 2021 18:14:25 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: cbor@ietf.org, dispatch@ietf.org, anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [dispatch] [Anima] Creating CBOR-based media types and content formats X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 22:14:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > We had interesting discussions yesterday about how to fix the > media-type and content-format registrations for CBOR-based anima > vouchers. Thank you for your input, and for trying to remove yourself from the loop. > I=E2=80=99m growing a bit tired of dispensing the ancient wizardry th= at is > required each time such a registration is needed, so I started writing > it up: > https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-m= edia-types.html > Comments and PRs very welcome. I did find reading it invoked a new appreciation for Arcane Wizardry. Specifically, I found that sections 3 and 4 didn't tell me anything that I recognized as important for filing in the template. "The Encoding considerations are often used in a way that is different fr= om the intention in Section 4.8 of [RFC6838], which is a simple selection between "binary" and various alternatives that are now all obsolete. " so, really, it's always binary now? Maybe, just say that somewhere. I don't think you should hide the example in the appendix. Rather, I think that you should make it the core of the document, explaining each bit of arcana. If it's worth publishing this as a new RFC, then it's worth obsoleting RFC6838. Otherwise, I suggest some nice HTML, maybe in the new-fangled single-hop-over-building wiki. ("Go big, or go home") =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD4nEAACgkQgItw+93Q 3WXOWggAsOgWIkSZYDJRQS7H+cKayLKPLstugS2nqKEOtEDeGUvSvpkp9KzWx+T0 st1uiMfUhq1Oj+vjfDERWnJwK2mBf7hYLwCEKO1+oyS9ZwJjlfs+VIp3Lqk2mugd WdI1VKQKmzcLOKvlY8IFX60lHd9jgjc10L0rqAUPUU3rOZNbmTRz+txyUk0cEQ2Y wXJOiqpFctvkqR6rWvaJ4CqmoYhV8747dmf4vyk8dGG2vYc6oZivsFn+Bnjmb8Un ssyjLjERb7SRY+uc+SkZV6XM1hYqd4PXI3sqlGqM8DCDtHJLdu7hJfQeO3L2AdoZ sstlMhlAtQCczNwT3z8Z3VZBQU5cZQ== =XBfo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 21 17:37:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9513A308C; Wed, 21 Jul 2021 17:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V68eP9ba9-sw; Wed, 21 Jul 2021 17:37:38 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8442F3A308A; Wed, 21 Jul 2021 17:37:32 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GVYST33sqz31Lg; Thu, 22 Jul 2021 02:37:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Carsten Bormann In-Reply-To: <9867.1626905665@localhost> Date: Thu, 22 Jul 2021 02:37:29 +0200 Cc: cbor@ietf.org, dispatch@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9867.1626905665@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [dispatch] [Cbor] [Anima] Creating CBOR-based media types and content formats X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 00:37:44 -0000 >=20 >> = https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-= types.html >=20 >> Comments and PRs very welcome. >=20 > I did find reading it invoked a new appreciation for Arcane Wizardry. >=20 > Specifically, I found that sections 3 and 4 didn't tell me anything = that I > recognized as important for filing in the template. Right, Section 2 is the one that is collecting the information about = registration. (Section 3 and 4 haven=E2=80=99t been written yet, anyway. =20 I thought it would be a good idea to get Section 2 out as input for the = ANIMA constrained voucher. But it doesn=E2=80=99t discuss media type parameters yet, so it isn=E2=80=99= t complete either.) > "The Encoding considerations are often used in a way that is = different from > the intention in Section 4.8 of [RFC6838], which is a simple = selection > between "binary" and various alternatives that are now all obsolete. = " >=20 > so, really, it's always binary now? Well, for CBOR-based protocols, yes. If you have a JSON-based protocol that can only represent =E2=80=9Ctrue=E2= =80=9D and =E2=80=9Cfalse=E2=80=9D, this might qualify for =E2=80=9C7bit=E2= =80=9D. (But if that protocol ever needs to be extended to alternatively carry, = say, a number, you=E2=80=99d have to make a JSON-foreign rule of = limiting the number to 999 characters, or you run into trouble with = =E2=80=9C7bit=E2=80=9D. =20 Once you add strings that can contain more than just enumerated ASCII = values, you are solidly in binary land, as UTF-8 is =E2=80=9Cbinary" in = this selection.) Here, the fact that MIME stands for Multimedia Internet *Mail* = Extensions (where =E2=80=9CMail=E2=80=9D means SMTP) comes through. (I think you briefly brushed into that history with RFC 7030 EST, which = is combining E-Mail Content-Transfer-Encoding with HTTP. =20 [Utterly amazing how this could clear the IESG.] You fixed that in RFC 8951, without making it entirely clear that you = changed the meanings of the media types to now be base64-legacy, which = by the way, with the right line breaks, is 7-bit...) > Maybe, just say that somewhere. I thought I did, but I certainly can make it more obvious. > I don't think you should hide the example in the appendix. >=20 > Rather, I think that you should make it the core of the document, = explaining > each bit of arcana. =20 That sounds like a great project for long winter evenings at the = fireside. (Macintosh file type code(s)? Fragment identifier considerations?) (I forgot to encapsulate the example in ~~~ wiggles so you can = copy-paste.) > If it's worth publishing this as a new RFC, then it's > worth obsoleting RFC6838. =20 It has no normative intent (*) (and it doesn=E2=80=99t cover a tenth of = 6838). I do think that it will be worth publishing, after a lot of feedback has = been obtained from the people who actually have been around when the = arcana were invented. I also think that the next update of 6838 might want to structure that = template in a more meaningful way. > Otherwise, I suggest some nice HTML, maybe in the > new-fangled single-hop-over-building wiki. > ("Go big, or go home") I think my parser is failing here. Gr=C3=BC=C3=9Fe, Carsten (*) That is a lie: In fact, examples are always more normative than = descriptive text, frantic disclaimers notwithstanding. From nobody Thu Jul 22 13:46:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A563A0A39; Thu, 22 Jul 2021 13:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZsEWcq9zPcB; Thu, 22 Jul 2021 13:46:18 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D088C3A0A40; Thu, 22 Jul 2021 13:46:17 -0700 (PDT) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 3564C1F451; Thu, 22 Jul 2021 20:46:11 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4CD9F1A02FD; Thu, 22 Jul 2021 16:46:10 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , cbor@ietf.org, dispatch@ietf.org, anima@ietf.org In-reply-to: References: <9867.1626905665@localhost> Comments: In-reply-to Carsten Bormann message dated "Thu, 22 Jul 2021 02:37:29 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 22 Jul 2021 16:46:10 -0400 Message-ID: <571281.1626986770@dooku> Archived-At: Subject: Re: [dispatch] [Cbor] [Anima] Creating CBOR-based media types and content formats X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 20:46:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> I don't think you should hide the example in the appendix. >> >> Rather, I think that you should make it the core of the document, >> explaining each bit of arcana. > That sounds like a great project for long winter evenings at the > fireside. (Macintosh file type code(s)? Fragment identifier > considerations?) Yeah. (I was cooling down in my unheated my pool last week, wondering why I can't edit code while floating. firesides would be other nice places) >> If it's worth publishing this as a new RFC, then it's worth obsoleti= ng >> RFC6838. > It has no normative intent (*) (and it doesn=E2=80=99t cover a tenth = of 6838). okay, then Updates/Amends-6838, and replaces the template part then. >> Otherwise, I suggest some nice HTML, maybe in the new-fangled >> single-hop-over-building wiki. ("Go big, or go home") > I think my parser is failing here. I'm saying that if we aren't going to publish, then it goes into the new wi= ki. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmD52REACgkQlUzhVv38 QpD3sAf9Eq7rLwtg6jD5Lg5coyy2q5enD0SqX7qv30GoBK7Osqyv5JE48bSuJbsV PHxtv+UROyfZYTboaHIrVrLfbX3ufjtDildpoIhdpE/NXKoYugzb+Ye3kLzc9HDb epQy7gPIqHLoor64P61aE2l8N67qBTKV9qrzwldQepmizeR1l5GDzcKVvXoEUlUv QwPofmoVX4+cWl9YYJ2NnaqojO79srnEdGRnRNE1SGML0CPrz75DMrRgS6Y4mw9K K/qgvfT17KYVDM1mIG5/Q6POIldZRl9KVcQWaAF7GLPpFJvAWq+V0xDrc9mG+hpf vZ5tyjeMpoJOCXwmeFP2dSKowgioKw== =Ww/x -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 25 01:20:12 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2783A1C08 for ; Sun, 25 Jul 2021 01:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-v9nGKe1yje for ; Sun, 25 Jul 2021 01:20:09 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F983A1C06 for ; Sun, 25 Jul 2021 01:20:09 -0700 (PDT) Received: from [192.168.3.236] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9C7A17C70C2 for ; Sun, 25 Jul 2021 10:20:05 +0200 (CEST) To: "dispatch@ietf.org" From: Harald Alvestrand Message-ID: <42554488-41e3-e0e5-33a2-8c41c71039fa@alvestrand.no> Date: Sun, 25 Jul 2021 10:20:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dispatch] NICER presentation is now in materials X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2021 08:20:11 -0000 The NICER presentation has made it to the DISPATCH materials page. The draft is still draft-oreland-dispatch-ice-nicer. See you on Monday - and happy to answer questions on the mailing list too! Harald From nobody Mon Jul 26 07:40:36 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A263A168D; Mon, 26 Jul 2021 07:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAP0Am3Nq4Vk; Mon, 26 Jul 2021 07:40:32 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A83A3A168B; Mon, 26 Jul 2021 07:40:32 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYMzL23lvz2xLr; Mon, 26 Jul 2021 16:40:30 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 649003229.8576519-4d08c7421958c0521437717dc01c3458 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Mon, 26 Jul 2021 16:40:29 +0200 Message-Id: To: dispatch@ietf.org, secdispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [dispatch] draft-jordan-jws-ct X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 14:40:35 -0000 I would have said the below on the microphone later today, but IOTOPS has been moved on top of SECDISPATCH, so I need to make my point on the list(s). As many of you know, I don=E2=80=99t care much about the mechanism = proposed, but then I=E2=80=99m not here to protect your feet from shotgun wounds. However, I am strongly opposed against labeling a proposed mechanism in a way that is misleading about its main characteristics. There is nothing, *absolutely nothing* "clear text" about extracting data from a JSON data model level input with an unspecified extraction mechanism(*), re-encoding and processing this into a (hopefully) deterministic(**) signing input, and then signing that with JWS (which at least is a standards-track specification). The latter employs base64 encoding, so it is even less "clear-text" than the essence described above would leave possible (RFC 7797, the only thing that might be called "clear-text" here, is explicitly excluded). I have already made this point repeatedly to the authors; this has been ignored. I'm therefore not very optimistic about the future veracity of claims about this effort. I have no interest in attempting to block this effort, but I would ask that we at least institute some language policing here. Gr=C3=BC=C3=9Fe, Carsten (*) The infamous `Transforms` in XMLDsig was at least specified. (**) Which, to increase the insult, requires a detour via UTF-16 input to create the deterministic signing input, cleartext ** *** (to paraphrase a well-known Apple executive). From nobody Mon Jul 26 14:31:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7773A1345; Mon, 26 Jul 2021 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXjjxgKzIDC7; Mon, 26 Jul 2021 14:30:58 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100104.outbound.protection.outlook.com [40.107.10.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BFB3A1349; Mon, 26 Jul 2021 14:30:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TSYldJG7SlcI1iwHW+enxy1MXch4qVKGH3Exg7h5xdhUpO3FlXaDe3zX4uCzFcnRzydlyDxbVL1gwr4WVTwo+btF13QyydD6XdXGmoYx/ySoPwufiofZvnU00scJz6tnNDJ1Aayb1zkgRUEUGa1kEveBKKhIoezjJRb5rQX7rx9dNVHGFvRt/IlNijjsc/SdvdG2OdNasHltL8f7/viaaiLXijjaICW+rsUmChiZ+5eaGbeOkMjWVlz5sjHW3Yui41u0sA94Qg5bGMjfwNcfqnXUuGOGafe5yWBLmsECLPOyzZhbCfWEpnMj216s4tQXpg9aJdItwF8SUx+Scb5HQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dT+k/qUjAc3+F0elFqRT9GG4Rddz2qMLGb4I56ZfcCk=; b=YYsp6JLOUmYfdFKkc1U79Rtg+qcekuad6PeGgkgIV9s0/eTYRWorkoUu+5yFK79C2synTtcFPtr7EXTW6GLKnU0AqUor4qsmCGHPX3pOS/ZoeNsx1f/ux5x6IdMCsgY+QwwM8ViQPGsQfl9I99ENyysXNbyQlgHiSKOIKgJCyYrgj6J7d5Lc17oXoAuydE8is0fOUjlCeLTkp5NpURx78WED+1pmemTdDMWSi9ByKqIDx9qMjDo2/axpIJK6Sl3H06M9JS6c1wzb3BOEHVvbfACwqYZDaOdIkL9LqbYkWAUFxsx2lAl0Y/q7CXK4BMLpBMjVAAVPWOFA5JDa2G7K8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dT+k/qUjAc3+F0elFqRT9GG4Rddz2qMLGb4I56ZfcCk=; b=XLT95zNXsx3xc1vz7YF2rZ6b04cB8H4Hi8+B1b5g2/GcTljvDloKRNWwPkL3lUxVfeTm+NcSbe9O7ujZXkvpmF6DN/QVcACtWuQCTrokLXBkwC5OS3Rj2Tk99MX3vftNqw9UCfF/hAVNcc28imMqw6xB/GIiXQrnwVgXwEdjabVIXrj9kYCP7rCk8WrNi8FLrxTqeNXvqKfZ8EduNXImsPS7uOJa5nUp69VIflQS50NTLKIFKsmyizYnhHAZEYTNP82SoJ9nevDUynJs2ti3BbUs2tx78eU7JONzyAqmTsoQe6FCHBeQmAt4LaBPsDEHBI7J1HxYuEhM5lvr6d8+yQ== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO3P123MB3049.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ff::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.28; Mon, 26 Jul 2021 21:30:55 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::3c36:33ea:ca34:ef01%4]) with mapi id 15.20.4352.031; Mon, 26 Jul 2021 21:30:55 +0000 From: Kirsty P To: "dispatch@ietf.org" CC: dispatch chairs Thread-Topic: DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes Thread-Index: AQHXgmLiO87/5DsgQEeaXtyUK3XhJQ== Date: Mon, 26 Jul 2021 21:30:55 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4282818-0024-4f20-5e6c-08d9507ca6cd x-ms-traffictypediagnostic: LO3P123MB3049: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2l56UYlyPsHXTi9AnKZCwhXdEAGNBDplZXxoagajnGkr/m6tNIaD5bBXbuMNjeN0Hvijop9DQC3sKwtXMfTZo+0VFznnRrDrzpBAwZ0sCz1mU0nD4psRe5N4aSTMj0N8l5VJeta7uS+LcJoJqbnTml54jT1OIE6/wBK+eEC8HdCpDdBaQ/aBGpgN1nAEiqCl9KlsnxvUMquriJ8HudGJchX27LAvdsh5DCPIYLWUAN/1IMlYgFWZT5rDEDrXd7yJ/zJ1SzcJk1VBlXc8uYY6Xt/2BABwilT+YEPGwN2GTEJ4B9PYVN5gUZ/9sk/fHcOlQgYTHwf/Yg32ozypOez3dqmmtUgcfTtgkYL4jHKyVCgbPsOofLTYQ5gtpwKXpmpsR7BV1xehffYgmtyAnJ//kScaA3tHsSlFnrWGhn7SlyF3BOGsrPY3cqTfeC/zBDoBqXTg2BfttKBPGUPjWwrtU12smBywm4mk02pAfyZxiri8MXfwpX/ZoFmt/rpnDl1gSoW7TC9ZxRvqj6k/OwQTwl7C7cMBOfG8GnUkT0Y0XVoZw+v/zFfYG2YC38fZOr/8yhn4WrBU14Et6WVwh7AQpxMxRLxpZh20IFzdYv/eplykPkpBSD93pwiHBjbSaIztA/AmtYcYD3T9ySJJ33gHhXxSwRDB+ht4uT+VS/hk2q6q/nwu4G4TMy3ktGqhmoN5N2JFfZZo6sV5iGww0oCa+tbiECmem94HHk84VXpkuEGQ9cu2h9qXmpRB1XER7Cq3h252DpErRgawpG9Qn+U35fr8VxW4LVltr+vinzLf3wY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39840400004)(346002)(136003)(366004)(376002)(7696005)(38100700002)(76116006)(66946007)(2906002)(86362001)(478600001)(66556008)(19627405001)(26005)(64756008)(55016002)(316002)(33656002)(450100002)(9686003)(186003)(6916009)(4326008)(5660300002)(66446008)(6506007)(52536014)(66476007)(966005)(122000001)(8676002)(71200400001)(83380400001)(8936002)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?m6f/fHtgFF8oJl6TCeQVXS468JXES63Ry17ybgnneregsK39R8Q9bKCu?= =?Windows-1252?Q?vC0OvplYMiY+RBUCF8IjHHI+D+61so3PTrAKQg6q/gAW69VNFKm/nZhk?= =?Windows-1252?Q?QflLbJBtYMsLx4eboNIhLXOjRr4XX9I8w4pMvdc7GeQMZ2rc1+wcP6Lv?= =?Windows-1252?Q?a8proyFHZFLF/7Naimj2dG3pQzGJCm/Fdk3ymHFrCSFKuW29N4ulHfKJ?= =?Windows-1252?Q?utaKFzrC6yakrxJzDMUc4MuuZ2L3h6mFBv2DtG0+Oj1WQ8WeqTirbQa3?= =?Windows-1252?Q?SrowM3WMG16M/KOregwMq2muFWJ3lNkdwjQ+LzruiE8gI3GPdpt4RGv8?= =?Windows-1252?Q?OHjY7gpGAv1K4zPrVHRV+IQ3VxRr2ETGTQuHn2jXkzBlckko9g0ZiLVK?= =?Windows-1252?Q?H0crIsCSyspzYyFPpfTOA8djEMc+AyYjgvtGka3PbV70zaNK4+6kK0fr?= =?Windows-1252?Q?7wsERj2hVF8Q1ixGJlQABseDDaOgQlVhKXpwABWYEMUvIbVGwU9l8xqz?= =?Windows-1252?Q?hKRkFIKtOlfY63rT3ilRSmCll7T8y8oeQGPj/FYa8B8V+LB2K8ETxXnL?= =?Windows-1252?Q?M59sZmbRnvbHnj3OxqrymFJ1J3UPsDYhcEQ2ykRLgUAfmHy9d/2qm39t?= =?Windows-1252?Q?4ynlTlDb7mSPKMKOQWagp2WeRAuSmFXV/xQbzuQKmzlg1vTX1QmXrpOO?= =?Windows-1252?Q?e5t+enNyHBKYDUaRTEqzlFge4aJ1UH5UG7+V2rjR7V7waquS0arzRbF/?= =?Windows-1252?Q?toHyYN75K4GWWASeU4WDNHVIPPIxVqRK29F5bG5TTxsO/b4/hQPbwHJb?= =?Windows-1252?Q?KPOAMuXBejWVabSs37YvdWkiwh/IwJASriMdkQj7G5XlxPLMLm4Egmn5?= =?Windows-1252?Q?hgw7hWFArl6RtFuUHbJV6sxxIiVETn7OwEgGxRCniPggXE1Juqb7UqD9?= =?Windows-1252?Q?FIW71lPo+9Xn+15gJ2V0P7ivZqrZR7GgaIRQDnRD5S0ivY3z3oFyboH6?= =?Windows-1252?Q?gKH367MQp2KH40CEc8UOPEhyOYvemLRrWdNHW7ZghHhGwknjtMWy1uZG?= =?Windows-1252?Q?M0Egn08fxYY8r2x83v7N0Xl4APPv2N+pYn69kITONBN70GrwVJ/XYk2q?= =?Windows-1252?Q?1HZjgHZip2JUNoFspZtGoKZ1vuE8/rJXkECsaHOEnQXoMkxyf/XleYvh?= =?Windows-1252?Q?8Eg1O/pgxSm20UMQEICm1k9ZyaugtxObB9Ry2CaEk4spqKtpjRYXYJVT?= =?Windows-1252?Q?QogmRl2pVD87bQd5koszTb6d8F2YdJvBkfajOfMXl7uKh1E6GQclWyd7?= =?Windows-1252?Q?HAvE+dDSUP6bO0DU+FkKKPVLDR8udsFr4r7Ie4rVsnHnwcvzcDyPVJlX?= =?Windows-1252?Q?jtUwAdf2wkXMA7js5VUgQQXkv+/ZRZwXKSH6VEi0cHiVT+rt96vz/SPr?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599783EEC14F3E314CA9BBBD7E89LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a4282818-0024-4f20-5e6c-08d9507ca6cd X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2021 21:30:55.3761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jinPQnmANfb4j7qlIepKhiVWZf8P7ndXdpXOZr5L6eAnsVTzIeGkKmLOIXvkIYjxGKoPwDPwDaEdN+U378m+Kg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO3P123MB3049 Archived-At: Subject: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 21:31:03 -0000 --_000_LO2P123MB3599783EEC14F3E314CA9BBBD7E89LO2P123MB3599GBRP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Firstly, many thanks to each of our presenters for bringing their work to D= ISPATCH today! And thanks too to every attendee who helped us towards a DIS= PATCH outcome for each of the items - we appreciated your participation, es= pecially when the virtual format makes things harder to take the 'mood of a= room'. Preliminary outcomes from DISPATCH at IETF 111 (now being confirmed on list= ) were recorded as follows: 1. JWS Clear Text JSON Signature Option: chairs did not hear support for= the IETF taking on this work at this time; dispatch will not recommend doi= ng so. 2. image/webp mime-type registration: Murray Kucherawy is deciding betwe= en expert review and AD sponsorship. 3. NICER (usage profile of ICE): ADs to determine if "ice-revisited" as = a broader topic for a WG would be right, or if this would be better in MMUS= IC as a standalone item. 4. SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus = was sub-optimal. There was support for revisiting the space currently stand= ardised by SDP, but not on direction (whether to do a deprecation with/with= out replacement). Future paths suggested included: mmusic, a new WG, more w= ork required for it to be ready, or a BoF (said in chat) to vet the idea fu= rther. 5. The =93large file in email=94 problem: recommend new WG, charter to b= e drafted and shared on dispatch list for further discussion. For info, the draft minutes are also available at: https://codimd.ietf.org/= notes-ietf-111-dispatch?view A copy has been uploaded to: https://datatracker.ietf.org/doc/minutes-111-d= ispatch/ Please email the chairs (dispatch-chairs) with any corrections or omissions= - and thanks once again for your dispatching energy! Kirsty This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599783EEC14F3E314CA9BBBD7E89LO2P123MB3599GBRP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Firstly, many thanks to each of our presenters for bringing their work t= o DISPATCH today! And thanks too to every attendee who helped us towards a = DISPATCH outcome for each of the items - we appreciated your participation, especially when the virtual format ma= kes things harder to take the 'mood of a room'.

Preliminary outcomes from DISPATCH at IETF 111 (now being confirmed on list= ) were recorded as follows:
  1. JWS Clear Text JSON Signature Option: chairs did not hear support= for the IETF taking on this work at this time; dispatch will not recommend= doing so.
  2. image/webp mime-type registration: Murray Kuchera= wy is deciding between expert review and AD sponsorship.
  3. NICER (usa= ge profile of ICE): ADs to determine if "ice-revisited" as a broa= der topic for a WG would be right, or if this would be better in MMUSIC as = a standalone item.
  4. SDP Security Descriptions is NOT RECOMMENDED and= Historic: consensus was sub-optimal. There was support for revisiting the = space currently standardised by SDP, but not on direction (whether to do a = deprecation with/without replacement). Future paths suggested included: mmusic, a new WG, more work required for it to be ready, or a Bo= F (said in chat) to vet the idea further.
  5. The =93large file in emai= l=94 problem: recommend new WG, charter to be drafted and shared on dispatc= h list for further discussion.
For info, the draft m= inutes are also available at: https://codimd.ietf.org/notes-ietf-111-dispatch?view
A copy has been uploaded to: https://datatracker.ietf.org/doc/minutes-111-d= ispatch/

Please email the chairs (dispatch-chairs) with any corrections or omissions= - and thanks once again for your dispatching energy!

Kirsty


This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599783EEC14F3E314CA9BBBD7E89LO2P123MB3599GBRP_-- From nobody Tue Jul 27 04:58:35 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527B03A217A for ; Tue, 27 Jul 2021 04:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jA7iwkrO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eBmzQNu7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcuwXqarmebY for ; Tue, 27 Jul 2021 04:58:27 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4413A2176 for ; Tue, 27 Jul 2021 04:58:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F10A05C0103 for ; Tue, 27 Jul 2021 07:58:26 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Tue, 27 Jul 2021 07:58:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=Cc96c0+ jtSLqfKJjz9xVunb9L2/yAZn/3ZGkCXB2yPw=; b=jA7iwkrOqCmUBbv3ybRcDEE hbFOrYhmxTeVTncNnOSD4RKSsh9ur3AX/hyLByZN+1SzZqD/hMf/sMcMjyO2z/0v azDXGfa5qYR2h5Lgu/jVIIx6SqOGhaXE4o2qn18TBSmr41nqLKh0zQrMnWjfCIg8 ybtYvMmd/C9IWsOtMhY6K8vf0GaM2YQC/06cBl0y9f/Hz6ebVMEH7Aw4szia7kCu dauf2ntjOa/uL9hrObbABko9y0/LeEV7ijQzO7oVZ2VLPjZTK1784JLFgD40Ilor kqiKUENh0Z80Ki75LwZzhQ0t3KLpUng4O3+LMUFvvgxyOZ4UQbQ4VQ03mSNmIcA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Cc96c0 +jtSLqfKJjz9xVunb9L2/yAZn/3ZGkCXB2yPw=; b=eBmzQNu7EoBWXsk4zjokVf N3sbO19nhwLZ1KnWnt9luSaA6bd3I0udJ44VNnDHHlHR4vE1HjV/WyBZX0GoY58I q3XyupruDJBpfykkiplta+LK7cOEhMXB/uEiSOGB2i4uixpmk7mZIA3ciYJ++Hsb dr8vzlb1gd7Vro8NyivgQGhsqwidUgjkAXngVeGUN31T50e5RoQNiu6Oa1KT8WYI FkWkwscdsPQvF6if2gCAI3CxnNpd7lDoJ/0pIcUNV58omSk8QRlbcTiYQrUtIEzt ppL/mPR9LN/F0/QGpWOGQlZUXtd3nGkVdeezCoHTbSO+oYdOzqCdBdR87qN/XyKg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeejgdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D8D6AC0DD0; Tue, 27 Jul 2021 07:58:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 27 Jul 2021 21:58:05 +1000 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=cc5f224f5c91471ab465de026ba3759b Archived-At: Subject: Re: [dispatch] =?utf-8?q?DISPATCH_IETF_111_meeting_-_preliminary_out?= =?utf-8?q?comes_and_draft_minutes?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 11:58:33 -0000 --cc5f224f5c91471ab465de026ba3759b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2021, at 07:30, Kirsty P wrote: > The =E2=80=9Clarge file in email=E2=80=9D problem: recommend new WG, c= harter to be drafted and shared on dispatch list for further discussion. Thanks Kirsty. I'm happy to help with developing a charter. I've also added discussion of this topic to the JMAP working group, sinc= e we had time in our agenda, and working out how to handle large files w= ill be in scope across all our datatypes that allow attached data (at le= ast email, calendar events, contacts and tasks for far!) This will be in the second hour of the end of the final session on Tuesd= ay:=20 Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --cc5f224f5c91471ab465de026ba3759b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 27, 2021, at 07:30, Kirsty P wrote:

The =E2=80=9Clarge file in email=E2=80= =9D problem: recommend new WG, charter to be drafted and shared on dispa= tch list for further discussion.

Thanks Kirs= ty.  I'm happy to help with developing a charter.

I'= ve also added discussion of this topic to the JMAP working group, since = we had time in our agenda, and working out how to handle large files wil= l be in scope across all our datatypes that allow attached data (at leas= t email, calendar events, contacts and tasks for far!)

Th= is will be in the second hour of the end of the final session on Tuesday= :

Cheers,
Bron.

--
  Bron Gondwana, CEO, Fas= tmail Pty Ltd
  brong@fastmailtea= m.com


--cc5f224f5c91471ab465de026ba3759b-- From nobody Tue Jul 27 05:20:33 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB03A2473 for ; Tue, 27 Jul 2021 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNqB7JT12DKP for ; Tue, 27 Jul 2021 05:20:27 -0700 (PDT) Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18563A246E for ; Tue, 27 Jul 2021 05:20:26 -0700 (PDT) Received: (qmail 12966 invoked from network); 27 Jul 2021 12:13:44 -0000 X-APM-Out-ID: 16273880241296 X-APM-Authkey: 255286/0(159927/0) 877 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 27 Jul 2021 12:13:44 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1697480F26; Tue, 27 Jul 2021 13:13:44 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JeprWiUmYwtB; Tue, 27 Jul 2021 13:13:44 +0100 (BST) Received: from phage-rock.fritz.box (p2e5a5dc4.dip0.t-ipconnect.de [46.90.93.196]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E742680A6A; Tue, 27 Jul 2021 13:13:43 +0100 (BST) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_38089D14-84E6-447F-946E-57EDE13A49FA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 27 Jul 2021 14:13:36 +0200 In-Reply-To: Cc: "dispatch@ietf.org" , dispatch chairs To: Kirsty P References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 12:20:31 -0000 --Apple-Mail=_38089D14-84E6-447F-946E-57EDE13A49FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26 Jul 2021, at 23:30, Kirsty P = wrote: >=20 > SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus = was sub-optimal. There was support for revisiting the space currently = standardised by SDP, but not on direction (whether to do a deprecation = with/without replacement). Future paths suggested included: mmusic, a = new WG, more work required for it to be ready, or a BoF (said in chat) = to vet the idea further. My sense is that there was a rough consensus around a goal to make it = possible to deprecate SDES - but the required steps were unclear.= --Apple-Mail=_38089D14-84E6-447F-946E-57EDE13A49FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> = wrote:

  1. SDP Security Descriptions is NOT RECOMMENDED and Historic: = consensus was sub-optimal. There was support for revisiting the space = currently standardised by SDP, but not on direction (whether to do a = deprecation with/without replacement). Future paths suggested included: = mmusic, a new WG, more work required for it to be ready, or a BoF (said = in chat) to vet the idea further.
My = sense is that there was a rough consensus around a goal to make it = possible to deprecate SDES - but the required steps were = unclear.= --Apple-Mail=_38089D14-84E6-447F-946E-57EDE13A49FA-- From nobody Tue Jul 27 06:38:40 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853343A094F; Tue, 27 Jul 2021 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbUJq0CGeaA9; Tue, 27 Jul 2021 06:38:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00923A0945; Tue, 27 Jul 2021 06:38:34 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m8NI1-0007cp-Fz; Tue, 27 Jul 2021 09:38:33 -0400 Date: Tue, 27 Jul 2021 09:38:27 -0400 From: John C Klensin To: Kirsty P , dispatch@ietf.org cc: dispatch chairs Message-ID: <2CE65D72FE374121C9185890@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 13:38:39 -0000 --On Monday, July 26, 2021 21:30 +0000 Kirsty P wrote: >... > 5. The "large file in email" problem: recommend new WG, > charter to be drafted and shared on dispatch list for further > discussion. Kirsty, If one includes the chat discussions as well as what was said over audio or video, that is not the impression I came away with. Specifically, there were comments from several people that we have been down this path before, including with message/external-body (went nowhere and raised security issues) and various URI approaches with which results have been poor (I think the term used was "terrible"), at least as soon as the mail crosses the Internet rather than sender and recipient being on the same platform. As I understood those discussions, there was a strong case made that any effort, even a charter, should include or be preceded by a systematic review of what has been attempted already and the reasons those efforts faired to gain traction. If we do not do that, we are almost certain to repeat old mistakes. thanks. john From nobody Tue Jul 27 13:18:44 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2A3A10D3 for ; Tue, 27 Jul 2021 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HRPLfBJP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g7oupS2U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bo5ZnVSJt8g for ; Tue, 27 Jul 2021 13:18:35 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887B33A10D0 for ; Tue, 27 Jul 2021 13:18:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 134145C01D4 for ; Tue, 27 Jul 2021 16:18:34 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Tue, 27 Jul 2021 16:18:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=DqYV9nE modVCSFnPZQNwD/pIR4l4M+QMnLHHfbSK6IM=; b=HRPLfBJPsZpcMKne/E6S5z9 1kfQUsmn7FYwWMy9NHeTEM744RhvkjE0gdMzGj8W14fvzJxAUbEeH8maR58zJRbM 8Q2vs7ZXWkSSFN9Kf0dRQqJjzCOpCoZC8x654OfjUNlNOKI7A4OVMY6dfY23aIVJ zQnuIBKqlrUNYxaOLJjKo3FYLj3BfhRbK7VDg1MWA6sp+qsWZ3CiKe13lWD3r1bF knvwNHPm7qNc4mLkTCINbS410KlzCuLFav6jHcLNQ+tbSFNg2iyYiLNp17ZmjXpI +m2pqhiQkgr63SLl0tsIFB7kV09ScOG4iR+YpusoFuTEe9PAotwn8KNhIiZfFIg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=DqYV9n EmodVCSFnPZQNwD/pIR4l4M+QMnLHHfbSK6IM=; b=g7oupS2UsgkDHmDcHlWLy+ 8u37N2o8wE9Jt9a0+tY7p8R/mRkE5b4bMmO738rX7CL5IkipYhptSuJ7Hj9Ue58p +nli7DSTxOHQ6pglqRApQotC3Bd3tp9YXXBnlKCL9V5wr/VWBG98Go77OHaIJdsK LD9JwLoIFZsLOBeXMJ54xZ7NiX27w433jWZPeHbcv+T2ZdJtnvaOlXlimoIJpLAJ 3ouqtWqD4e5c8bCJACrIPYRMKXZfhokA+BDOohXqVR0iQ+IJG9ZZPe+EhlpEODEP 5ucviXBNBkCPbAwzhEKbEi/nYLRLP7H0Vx425+a4wxzRVUDPJjnLXRHPuJtkjc3w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeejgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtheetgeefve etudffveetheffgfehhfdvveekuefhheeuteduhefggeeikeejteenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 916DFAC0DD0; Tue, 27 Jul 2021 16:18:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: In-Reply-To: <2CE65D72FE374121C9185890@PSB> References: <2CE65D72FE374121C9185890@PSB> Date: Wed, 28 Jul 2021 06:18:13 +1000 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=5e6ff85f3e1647f2b6b551c4ae71519f Archived-At: Subject: Re: [dispatch] =?utf-8?q?DISPATCH_IETF_111_meeting_-_preliminary_out?= =?utf-8?q?comes_and_draft_minutes?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:18:42 -0000 --5e6ff85f3e1647f2b6b551c4ae71519f Content-Type: text/plain On Tue, Jul 27, 2021, at 23:38, John C Klensin wrote: > --On Monday, July 26, 2021 21:30 +0000 Kirsty P > wrote: > > >... > > 5. The "large file in email" problem: recommend new WG, > > charter to be drafted and shared on dispatch list for further > > discussion. > > Kirsty, > > If one includes the chat discussions as well as what was said > over audio or video, that is not the impression I came away > with. Specifically, there were comments from several people > that we have been down this path before, including with > message/external-body (went nowhere and raised security issues) > and various URI approaches with which results have been poor (I > think the term used was "terrible"), at least as soon as the > mail crosses the Internet rather than sender and recipient being > on the same platform. > > As I understood those discussions, there was a strong case made > that any effort, even a charter, should include or be preceded > by a systematic review of what has been attempted already and > the reasons those efforts faired to gain traction. If we do not > do that, we are almost certain to repeat old mistakes. Thanks John. I would agree that we've been down approximately similar paths before. I'd also argue that the need hasn't gone away, and that I pretty clearly demonstrated that the major email services are all "solving" this problem in their own separate ways - and in a way that puts undue burden on end-user email recipients. I would expect that the chartering effort would include a review of past attempts as well as of existing solutions to the problem! While the standard approach attempts may not have gained traction, non-standard work arounds certainly have gained traction in the intervening time, so if we do nothing we are also repeating a mistake, which is to encourage non-standard and incompatible alternatives to proliferate. Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5e6ff85f3e1647f2b6b551c4ae71519f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jul 27, 2021, at 23:38, John C Klensin wrote:=
--On Monday, July 26, 2021 21:30 +0000 Kirsty P
<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> wrote:=

>...
>&= nbsp;  5.  The "large file in email" problem: recommend new WG= ,
> charter to be drafted = and shared on dispatch list for further
> discussion.
<= br>
Kirsty,

If one = includes the chat discussions as well as what was said
over audio or video, that is not the impressio= n I came away
with.  Spe= cifically, there were comments from several people
that we have been down this path before, including = with
message/external-body (w= ent nowhere and raised security issues)
and various URI approaches with which results have been poor = (I
think the term used was "t= errible"), at least as soon as the
mail crosses the Internet rather than sender and recipient being
on the same platform.

As I understood those discussions, there was a strong case made
that any effort, even a charte= r, should include or be preceded
by a systematic review of what has been attempted already and
the reasons those efforts faired to= gain traction.  If we do not
do that, we are almost certain to repeat old mistakes.

Thanks John.  I would agree that we've been down a= pproximately similar paths before.  I'd also argue that the need ha= sn't gone away, and that I pretty clearly demonstrated that the major em= ail services are all "solving" this problem in their own separate ways -= and in a way that puts undue burden on end-user email recipients.

I would expect that the chartering effort would include a revi= ew of past attempts as well as of existing solutions to the problem!&nbs= p; While the standard approach attempts may not have gained traction, no= n-standard work arounds certainly have gained traction in the intervenin= g time, so if we do nothing we are also repeating a mistake, which is to= encourage non-standard and incompatible alternatives to proliferate.

Regards,

Bron.


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--5e6ff85f3e1647f2b6b551c4ae71519f-- From nobody Tue Jul 27 16:08:46 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F99B3A0E5D for ; Tue, 27 Jul 2021 16:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwcXY6W4Y95M for ; Tue, 27 Jul 2021 16:08:39 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070.outbound.protection.outlook.com [40.107.20.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0483A0E5B for ; Tue, 27 Jul 2021 16:08:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VWQrdr7O73iDEnTqzs76Fe0HEA1NNGCI9xQOcacq4c9fhPAUqoqaNCr/C5nYvKIxU2ESI7WNFz0INZHqsyqSynLhYC6PTaGPEY2yf3E/NmTMSj5NMfBRFjkjuvpS3tbSAhuv5qgU/Pppw2CBq/y2tMS3WW5ffESf19wR9kPUQIkgTrUFgEWrrH3XfdF8I6tTpOP/SjiwpOWZYs016l+9myjTruPue+fMt80So0J8acTtZ2C5slWMNZ7VprQik2Oo7AatxBMfQ5jO0MVtfio5EpH5h4UIjcnkha5pHumjHuzfkS4xJVJCsi1aIbUDrKT64/Vwc0JI5sQYzNLJ5E6mwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kx4hxErPI4fq1ZzjoMUtYzFSewqxidI7W1m/apQvM7s=; b=HqztwwvXxM9Ix4j0yfPcJo8WLuQAPWKKY0G+Jpd8Uj1+Qzss7V+NYc5slvPtxttX3ouKULr6UtyJiveg7Ie8vrrpSgqI0gu9gtNMCU05altEx47kI4ToikLZoO3dMBTynoBIjSFLYghwlf2uCeKZ0DKF2pW5QOeubmzThPaMJE8gqPag9hFmg3WXhkWFcuHwwVHxfBt8lqyp6nFVp6Wx77/23i3cphZKxQ3wYDzNTEDCsobV/wfG2ZbG2ImllUoCRVgHKxtKg9BYbzwTS3LwkSLr23HAQvKvdMAMniiuNtgiADrU+63118Qfn9dEWT+0TEPv/IR1VGjFoJKAtSkcYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kx4hxErPI4fq1ZzjoMUtYzFSewqxidI7W1m/apQvM7s=; b=KzOw5O8TvAYqr7CqGZe+DvUOWSOaJIIlzgcYMnmhOCx2pWODdKhJWaKpZ7o1IcpNw6WMr5SQ9Xjg7ylEsegd0L7JK0F4bI7wSMkyQhnFQlWbx7wr0ChJvP5YIur193bHG1Mv8aIAhELY5Vpnz0UfS0Z5R+aXc4JH8nbkcmP7zmc= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2506.eurprd07.prod.outlook.com (2603:10a6:3:68::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.11; Tue, 27 Jul 2021 23:08:35 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b%5]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 23:08:35 +0000 From: John Mattsson To: "dispatch@ietf.org" Thread-Topic: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes Thread-Index: AQHXgzpb6iflqBZmeUGEzWRA3H1WeQ== Date: Tue, 27 Jul 2021 23:08:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f625ca98-7fea-4cfd-834a-08d951537621 x-ms-traffictypediagnostic: HE1PR0701MB2506: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nNNa2x1V5VtDQC/0EAyRYy1KgI80IPUMasBsrccjSojX8CBSE8aheyXnh17aMLQadlGcdjhWjROS7JgeyrEDm8RLou9kjQsI06I48dWNNtkIDWWyXNRHFNXaLXc2rMGLK21KdZmApLSJgWRmHjL/WfG55o35rxJIsBNO3TzFbofHVM2KTGZqb9vRQ2OEfiCssLAxPU4SHn9eh3YdMFAzIxJvjSo9WQZ7XLKka6pYVV7BAxi3xbxJ4C8q4RMjM2xqFzGwAa46HKB+8jg8vkehOJKrVmXEUcvWO6AbYk2pVxcu+gnqNJpyIrLhkMT5UpcpmP77WUWpY0L7bxGo/+ysw5l7cpm5lgTnCqkCumlk5bpNNXsi3H1Y9K9SHz8y3wBQbSqgWKpOw3ZQv+rV1dGeQC+mVtQnpLDlMloVEJQPWJrAmgIguWtI/ac9oOzIKN4fcEGoW7+4oh55vXNAW3c2qz7fkhid3WJ32JHZifQLowNfX0RjjSSFhs3RB6jyL8VOHbUZC3px8ef/L8g0X1ck7MkZY/d9cLNAYsDlXahrPTFmIiZMDU8skozeyLHvWyUhYkImD24jSpPRoKyf4b1Desi6/SYcyfNCXsPNoPC5a60h5tBqs5oiX+nX782vwzmTublZOu4WyT2SbQ+KJZHtRnMFMPXqx86pMi6Oq9Gk4nBBLiK81RzG4iQMJajwwQSPGFVY10Y3MzCkC3PRFJMScQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(44832011)(122000001)(38100700002)(64756008)(76116006)(7696005)(8676002)(66446008)(66556008)(66946007)(55016002)(33656002)(66476007)(8936002)(2906002)(6916009)(5660300002)(316002)(478600001)(71200400001)(186003)(6506007)(52536014)(83380400001)(9686003)(38070700005)(26005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?VKUnSY5fFGiXFqUHp/WjZsWra6GUE4SCSpo7A8HAMD9jcea6M3F5Y1Sp?= =?Windows-1252?Q?SpHAdtZ5HpNP8nHRKKy1P9iJitWMKAdgCuyE1tTDQwD7WFByQ0HeC/kj?= =?Windows-1252?Q?Px/pR9j1uW3HBPahGfINoR7i/1odLOScQKEhT+vui+HjH47Vs6GWqXom?= =?Windows-1252?Q?undSV0fTGP6RN4YH83uxBTzppXiKg5SB5sqxpwnyzQrJlIwXl6qtJ+GX?= =?Windows-1252?Q?6q2gDtQl7oeBQ6kD5yZaHRlR59xq7I4jHHyhjkyPgsu3JGyfvQMeuYEl?= =?Windows-1252?Q?oawCZZxPEETu2jNerBIkGHIpwDkfgUqcddXE/1G4excagK9GRyR0fsJb?= =?Windows-1252?Q?E32ZlSt/RDSYbiXH2KeIkYh6xCzxDpsKx+4/Itageki8HYPVD9poqGgW?= =?Windows-1252?Q?KCVjEXD9pk4Z4+JY/PuWo3LwWDBjfg8EIM0HIVda2htJ5m3RozU1nqES?= =?Windows-1252?Q?juIGDHjCHRxJB7xHYIoZWdB5ZClmS0ehaHBelBMFIwrhaNP13mrp3uGN?= =?Windows-1252?Q?kac3yBFy0+reLB8/Syj2ts3ti1h16dOPBA5QUUCHhVeomAZhxhd7GVlb?= =?Windows-1252?Q?Y/C0R5z8zWklWr3XjC6uagrgXKOImlmdpQcRYSjtshpxjMZV+MwHDHL1?= =?Windows-1252?Q?xv2sokdLb0EDhuz6XMVe8dTPaSblRDSuKCWE0e1e9Lz5Snwv6zWSXM5v?= =?Windows-1252?Q?daGzsKySWY6Dt/Bp6y04PC2blGjLUXBDvQyCnqHAiZtB7hcHRdY3pQVt?= =?Windows-1252?Q?Yq0WkPD0xkbiTM2yI65o2taCNgDbL4IMUmQ2Y/loW1za96uqmHr5htpE?= =?Windows-1252?Q?Ge9xNuAw8niz0bNNeI5U372oTxrB1Fg98evl3sODdLjrSSq2uMjUS98b?= =?Windows-1252?Q?HdzIgSUF/Dq14Msc4GS0fZjrQWRXVyus5V/R19JU76usymXw5LzEK44R?= =?Windows-1252?Q?CLdA12AU1SYWkkIfFtdP1zywCveXJlZrXQAMlWEh3emeFdX3dR9BrzAa?= =?Windows-1252?Q?EKgVSOGAGd2WcI2NjUU9EuVIZdpWMaNmi3rPNVfjFT/tz9PBw8qPe0UO?= =?Windows-1252?Q?HxWHySnn055UWKPEjtYVtAGBbiGPDzfmrNVOBP7sIJT/jXIeKYvdWQzS?= =?Windows-1252?Q?wg1u1h2CGslFBCp/Lplqpca2e+ALXz/NMTPMrXHqPbp8AcJ0uA0zMiuA?= =?Windows-1252?Q?ImKPztT8k5nonDbVKvgrr4hI3dzvhYX1k8UZk6VaNt9ZvvLuo5075NY5?= =?Windows-1252?Q?gkK2TJjyb7eQuDpET/QGqFkdcn2EEX/cQe4yymqrGACSPGvtLDnHmLl3?= =?Windows-1252?Q?N/HPp/GpkUi2X8EAWxXgXkzYnNSt/OT1R6eATPR7v0fEQumRXtM8iewB?= =?Windows-1252?Q?fGKVXTIxqNzLQieHNxpntX/ZEEoFq5zXGE6e02S15az18MB97s/uBltW?= =?Windows-1252?Q?RRNjLztHgz6G5EiSo7qE+g=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30504412F0FCC7C14E2D504289E99HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f625ca98-7fea-4cfd-834a-08d951537621 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 23:08:35.4289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SHWTrLkFAfkhLRJc6o0kAeWsITgU7RX8jmkRYJnq4O8wGMT3GwshFIrZMGl+Vt2yMxvC0gCIXuPXRxhsKlskP+8a45W+7J8Aq4PPgU7rALM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2506 Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 23:08:44 -0000 --_000_HE1PR0701MB30504412F0FCC7C14E2D504289E99HE1PR0701MB3050_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable westhawk thp@westhawk.co.uk wrote: >> On 26 Jul 2021, at 23:30, Kirsty P >wrote: >> >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was= >sub-optimal. There was support for revisiting the space currently standar= dised >by SDP, but not on direction (whether to do a deprecation with/witho= ut >replacement). Future paths suggested included: mmusic, a new WG, more w= ork >required for it to be ready, or a BoF (said in chat) to vet the idea f= urther. >My sense is that there was a rough consensus around a goal to make it poss= ible >to deprecate SDES - but the required steps were unclear. Yes, looking at the Jabber log there was quite strong support for the goal = of deprecating SDES: Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a g= ood idea and promote it to full standard toda Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before? Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;) Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? Sean Turner: +1 to what ekr said Rich Salz: +1 also Regarding the next required steps I agree with Pete. Let=92s charter. Ben Kaduk: So is this dispatch to BoF, or straight to WG? Pete Resnick: @ben: Sounds like this discussion has done the equivalent of = BoFing. Charter. Cheers, John --_000_HE1PR0701MB30504412F0FCC7C14E2D504289E99HE1PR0701MB3050_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

westhawk = thp@westhawk.co.uk wrote:

 

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> =
>wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

&nbs= p;

Yes, looking at the Jabber log there was quite strong support for the= goal of deprecating SDES:

 

Eric Rescorla: Let's al= l just agree that this (Mattson's SDES) draft is a good idea and promote it= to full standard toda
Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

&nbs= p;

&nbs= p;

Regarding the next required steps I agree with Pete. Let=92s charter.=

 

Ben Kadu= k: So is this dispatch to BoF, or straight= to WG?

Pete Resnick: 

Cheers,

John

--_000_HE1PR0701MB30504412F0FCC7C14E2D504289E99HE1PR0701MB3050_-- From nobody Tue Jul 27 16:10:37 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198D83A0E83 for ; Tue, 27 Jul 2021 16:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4P5gnrp_Qs6 for ; Tue, 27 Jul 2021 16:10:31 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A583A0E82 for ; Tue, 27 Jul 2021 16:10:31 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id r5so846761ilc.13 for ; Tue, 27 Jul 2021 16:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jKYwHkk84sQH0BPZ98R53SfPUEOYMK4fP9UmaquQ3Qg=; b=ozOkDS/wuxnozueji4jww+2dQggtDShdAkzouzHnXWBwHrT1rJedIORC1jnikiakUX GZh+MX6zwIBNnCynP6HYvX+iSaIlAOhV5ABx9anDPy6a7QrTo/6FAHI4l5S4a7gXTeyR Jsnwu0jF9pKRVuBGa/gXp/GA29N3Vy/rt25zTkiZyw5lVMVLZQoHAKI5tMDZpoq46K2g mO+2jW5AUfrXXta/XaDRXkWD3GajRSiw6zmd2hsYMgPcby7ITRstaXHlMtWoJzEwShMN 7jzA83Qnn+rfQAljAXMDeAnbnomvWEkxeydgcAFpAt6P3qCJAnTPWjPVV/KcQSRFU2R+ 7eYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jKYwHkk84sQH0BPZ98R53SfPUEOYMK4fP9UmaquQ3Qg=; b=LQUI6JTHp2XoVA2hsz6pkHChXmr1gtXIjpkwOTER+IaQBuh8Mlc0eRsIDuLoSqZufL /zshY41y+fI7oNPaROKlhwvqPs61vC4kJh8smXbpX5rJbFL4JJjpWcCk9a1Xk+k24xTz ij00op/402jof2frOrmwOXBgRBFK70deyJGWWlzbVMlehbDg3qvSeCrCgdFq0bVe7/wL RNkhDVk/woVQRFBHRxThAonBOpFvOnxP2Pj/RgsesBlH3Uwnxd4eLqkiVAlsIt29qj4y 1i8coOglXiDOY3mUpnsq8bnj+doG30boe5rXLnwzvKTz00Kik5JMnGIzbTTv47/vk1qy VoEw== X-Gm-Message-State: AOAM533bxLAzNJ7aBhd0VJesIu1zmckKKKzlzqRANfBDuCwJq2D/UHVe z3NEjXMrU9InWrzNQBgTPdkySJMB97+vRnzNk5OeGcI43DRqEw== X-Google-Smtp-Source: ABdhPJzqL6E3MpVaYhOb6frppo3vQ820COp0GbTj+6ATIh6iXnjw0ToYNxnjqumgTT2Rkztfx7L8LF89dnh0/tL9q74= X-Received: by 2002:a05:6e02:13d3:: with SMTP id v19mr18815264ilj.167.1627427429553; Tue, 27 Jul 2021 16:10:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 27 Jul 2021 16:09:53 -0700 Message-ID: To: John Mattsson Cc: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d62cb705c822f96f" Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 23:10:36 -0000 --000000000000d62cb705c822f96f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2021 at 4:08 PM John Mattsson wrote: > westhawk thp@westhawk.co.uk wrote: > > > > >> On 26 Jul 2021, at 23:30, Kirsty P <<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org>> >wrote: > > >> > > >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus w= as >sub-optimal. There was support for revisiting the space currently stand= ardised >by SDP, but not on direction (whether to do a deprecation with/wit= hout >replacement). Future paths suggested included: mmusic, a new WG, more= work >required for it to be ready, or a BoF (said in chat) to vet the idea= further. > > >My sense is that there was a rough consensus around a goal to make it po= ssible >to deprecate SDES - but the required steps were unclear. > > > > Yes, looking at the Jabber log there was quite strong support for the goa= l > of deprecating SDES: > > > > Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a > good idea and promote it to full standard toda > This was maybe slightly sarcastic but for avoidance of doubt, I strongly support this work . -Ekr Martin Thomson: now that I see John presenting this, I have to wonder: why > didn't this deprecation happen before? > Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I > assumed that was that ;) > Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? > Sean Turner: +1 to what ekr said > Rich Salz: +1 also > > > > > > Regarding the next required steps I agree with Pete. Let=E2=80=99s charte= r. > > > > Ben Kaduk: So is this dispatch to BoF, or straight to WG? > > Pete Resnick: @ben: Sounds like this discussion has done the equivalent > of BoFing. Charter. > > > > Cheers, > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000d62cb705c822f96f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 27, 2021 at 4:08 PM John = Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:

westhawk thp@westhawk.co.uk wrote:

=C2=A0

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

=C2=A0

Yes, looking at the Jabber log = there was quite strong support for the goal of deprecating SDES:<= /u>

=C2=A0

Eric Rescorla: Let's all just agree that this = (Mattson's SDES) draft is a good idea and promote it to full standard t= oda


This was may= be slightly sarcastic but for avoidance of doubt, I strongly support this w= ork .

-Ekr

Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

=C2=A0

=C2=A0

Regarding the next required ste= ps I agree with Pete. Let=E2=80=99s charter.

=C2=A0

Ben Kaduk: So is this dispatch to BoF, or straight to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Chart= er.

=C2=A0

Cheers,

John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000d62cb705c822f96f-- From nobody Tue Jul 27 20:58:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732473A1A7E for ; Tue, 27 Jul 2021 20:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf0JmtngNp2K for ; Tue, 27 Jul 2021 20:58:44 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B6D3A1A79 for ; Tue, 27 Jul 2021 20:58:43 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id h14so1349363lfv.7 for ; Tue, 27 Jul 2021 20:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8+iYdZzMovMvRWdyvYmhypEFGN0qr8rjZibl1+Xgm4k=; b=TwV+MSTrojqIK5MHZx6Pd5tJ0sZla93qpkeQvwwW03bRPEi307QWhY/koFiNS8/qxp Hnv7aS2Pt05L1uNgRusHp9AV+FN5pKRy68DBFqW5t0WXNqbT97kcKZ+pVrev1kSpNAAZ ImgDJEryswRq6e8Zcn/ULSSCRc9ghVJmbCpWrnoPU8us7Lswt8SWwxNzplc/WdnOc+HF NZ0apsn5aROi0X5z4/MzN11Fmqzijueh9xH+MmUs9pVmh+YOtNInWD3eFWUfV4oPP2P9 Tw8Ua+E7lR21ZPsuW0XntqGo0mv7CqhuHBvH+HgOdKHCcjQDlAE4qUEAMu+A/zzu54+9 UZ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8+iYdZzMovMvRWdyvYmhypEFGN0qr8rjZibl1+Xgm4k=; b=ALCjNgiiLO/Jr8ke9rrn7yF6EuE3vIT9F6ZNgQvc1lnCu1uXQDwE0BZaCcbQKBrOFE krJ+ofSmtQYqpRI9FeWC/W4j9DBCSI6mWY/HHWyj6rkgO44q+/jPcMsL6oAdjId7QbGY 3GznbxpxcocYo+5nh3b5DqueyUgdI5yLEyFB+FkzWP5n+8MsdRgzNiNzEPOHrzxHLgxi snzAVCLV3Iyx9hgGYKhESXby1osoUpxmp5iD1xKZJFlSIlUtmm94HiEReQBcbEQ8lvjb wli0sk6u8nkr1QU0naiSp0gNCUvFDMgEK644P2OQem85byprCEG9rp2Mfi/JgUGpS+R/ 8LWg== X-Gm-Message-State: AOAM533XQeRNdHzSynUkzs6kMcz8581JwrYKp5wsdYEyeXvJnzOjM6UE 3xDJrF3Sf/hYalb9P8W+MqEtyNgkbjFJ7Wc6QMRdCLIRbnOrSdZ8 X-Google-Smtp-Source: ABdhPJxABaGLU9WXznEQjQJDLqy4qDfSGEXbqecehlk3NhmBE37PUKTHkd+Alpn32Qza3I1uEebuBM7X9ZJAWA1mQJ0= X-Received: by 2002:a05:6512:3699:: with SMTP id d25mr19153159lfs.380.1627444719875; Tue, 27 Jul 2021 20:58:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Zern Date: Tue, 27 Jul 2021 20:58:28 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="0000000000006c554705c82700f2" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 03:58:49 -0000 --0000000000006c554705c82700f2 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 30, 2021 at 7:00 PM James Zern wrote: > > > On Tue, May 25, 2021 at 12:31 PM James Zern wrote: > >> Just bumping the thread for visibility. Are there any opinions on the >> right processing path for the image/webp mime-type? >> >> On Wed, May 12, 2021 at 10:13 AM Murray S. Kucherawy >> wrote: >> >>> On Thu, May 6, 2021 at 6:45 PM James Zern >> 40google.com@dmarc.ietf.org> wrote: >>> >>>> On Thu, May 6, 2021 at 12:53 AM Murray S. Kucherawy < >>>> superuser@gmail.com> wrote: >>>> >>>>> On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: >>>>> >>>>>> It was suggested I post a message here requesting advice on the >>>>>> processing path of my submission to register the image/webp mime-type [1]. >>>>>> I'm not familiar with the process, so if you could have a look and see if >>>>>> this is appropriate for the DISPATCH working group or suggest another I'd >>>>>> appreciate it. >>>>>> >>>>> > In a thread on media-types there was a reference to MIME types supported > by Debian packages [3]. image/webp is widely accepted, but I'd like to see > it recognized officially to help unblock other work [4][5]. > There were some questions at Dispatch 111 [6] about the format specification and whether it was possible to have an independent implementation. The references for the format are in the draft [1]: lossy compression [7], lossless compression [8] and the container [9]. Some examples of independent implementations are Apple (Safari, Mac OS, iOS), go lang [10] and FFmpeg [11]. > > >> >>>>> Just a reminder that DISPATCH's charter includes: >>>>> >>>>> "- By agreement with ART ADs, processing simple administrative >>>>> documents." >>>>> >>>>> If we agree that this work fits that description, then that's a >>>>> processing option here. >>>>> >>>>> I would also suggest this be floated by media-types@ietf.org, if that >>>>> hasn't been done already. >>>>> >>>> >>>> I requested a review on that list [2]. Did you want to start a separate >>>> thread to request advice on a processing path? >>>> >>> >>> Nope, that's what this thread is for. >>> >> > [1] https://datatracker.ietf.org/doc/draft-zern-webp/ > [2] > https://mailarchive.ietf.org/arch/msg/media-types/EYRWG6ochcIhAFhBwHCJlsBVV38/ > [3] > https://mailarchive.ietf.org/arch/msg/media-types/r0MJSX-WIywIAnq9w7slgWtLhUU/ > [4] https://crbug.com/webp/448 > [5] https://crbug.com/webp/485 > [6] https://datatracker.ietf.org/meeting/111/session/dispatch [7] https://datatracker.ietf.org/doc/html/rfc6386#section-12 [8] https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification [9] https://developers.google.com/speed/webp/docs/riff_container [10] https://pkg.go.dev/golang.org/x/image/webp [11] https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/refs/heads/release/4.4:/libavcodec/webp.c > > >> >>> -MSK >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> --0000000000006c554705c82700f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 30, 2021 at 7:00 PM James= Zern <jzern@google.com> wrot= e:


On Tue, May 25, 2021 at 12:31 PM James Zern <jzern@google.com>= ; wrote:
Just bumping the thread for visibility. Are there any opinio= ns on the right processing path for the image/webp mime-type?

On Wed, May 12= , 2021 at 10:13 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, May 6, 2021 at 6:45 PM James Zern <jzern=3D40google.com@dmarc.ietf.org<= /a>> wrote:
On Thu, May 6, 2021 at 12:53 AM = Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Apr 29, 2021 at 7:58 PM James Zern <jzern@google.com> wrote:
<= div>It was suggested I post a message here requesting advice on the process= ing path of my submission to register the image/webp mime-type [1]. I'm= not familiar with the process, so if you could have a look and see if this= is appropriate for the DISPATCH working group or suggest another I'd a= ppreciate it.

In a thread on media-types there was a reference to MIME types supported = by Debian packages [3]. image/webp is widely accepted, but I'd like to = see it recognized officially to help unblock other work [4][5].=

There were some questions at Dispatc= h 111 [6] about the format specification and whether it was possible to hav= e an independent implementation.
The references for the format ar= e in the draft [1]: lossy compression [7], lossless compression [8] and the= container [9].
Some examples of independent implementations are = Apple (Safari, Mac OS, iOS), go lang [10] and FFmpeg [11].
=C2=A0=
=C2=A0
<= div dir=3D"ltr">

Just a remin= der that DISPATCH's charter includes:

"- By agreement with = ART ADs, processing simple administrative documents."

If we agree that this work fits that description, then that's = a processing option here.

I would also suggest thi= s be floated by m= edia-types@ietf.org, if that hasn't been done already.

I requested a review on that list= [2]. Did you want to start a separate thread to request advice on a proces= sing path?

Nope, that'= ;s what this thread is for.


=
=C2=A0
=C2=A0
<= br>
-MSK
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000006c554705c82700f2-- From nobody Tue Jul 27 21:13:47 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCE73A1AF3 for ; Tue, 27 Jul 2021 21:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drBlSqu7f_zg for ; Tue, 27 Jul 2021 21:13:38 -0700 (PDT) Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57ADE3A1AE9 for ; Tue, 27 Jul 2021 21:13:38 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4130142E5; Wed, 28 Jul 2021 00:13:36 -0400 (EDT) From: Cullen Jennings Message-Id: <63B7ABE0-A546-4354-A2FB-002CC22D50BB@iii.ca> Content-Type: multipart/alternative; boundary="Apple-Mail=_0ED83293-A0FB-4BEE-886A-ABD545A4A94F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 27 Jul 2021 22:13:34 -0600 In-Reply-To: To: "dispatch@ietf.org" References: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Classification-ID: 4f2615af-d4e2-49ee-ba65-56b31d896a1e-1-1 Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 04:13:45 -0000 --Apple-Mail=_0ED83293-A0FB-4BEE-886A-ABD545A4A94F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The jabber chat certainly does not represent the room in any WG I have = been in. I do not think the slides represent an accurate summary of the = what we are trying to achieve by deprecating SDES or what we would need = to do get there and thus don=E2=80=99t lead to a useful input on what to = do next or where to dispatch it.=20 As I said at the meeting, I am in favor of discussing and solving the = problems we need to sort out to have a viable replacement. It is pretty = hard to have a conversation about that in 10 minutes when some of the = people are arguing that SDES is worse than unencrypted traffic.=20 A real good starting point to the conversation would be agreeing about = the fundamental differences - in my mind the largest difference is that = in DTLS-SRTP, the attacker has to be able to modify the SDP to MITM the = media while in SDES the attacker only needs to see the SDP to MITM the = media.=20 > On Jul 27, 2021, at 5:09 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Jul 27, 2021 at 4:08 PM John Mattsson = > wrote: > westhawk thp@westhawk.co.uk wrote: >=20 > =20 >=20 > >> On 26 Jul 2021, at 23:30, Kirsty P = = >wrote: > >>=20 > >> SDP Security Descriptions is NOT RECOMMENDED and Historic: = consensus was >sub-optimal. There was support for revisiting the space = currently standardised >by SDP, but not on direction (whether to do a = deprecation with/without >replacement). Future paths suggested included: = mmusic, a new WG, more work >required for it to be ready, or a BoF (said = in chat) to vet the idea further. > >My sense is that there was a rough consensus around a goal to make it = possible >to deprecate SDES - but the required steps were unclear. > =20 >=20 > Yes, looking at the Jabber log there was quite strong support for the = goal of deprecating SDES: >=20 > =20 >=20 > Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft = is a good idea and promote it to full standard toda >=20 >=20 > This was maybe slightly sarcastic but for avoidance of doubt, I = strongly support this work . >=20 > -Ekr >=20 > Martin Thomson: now that I see John presenting this, I have to wonder: = why didn't this deprecation happen before? > Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - = I assumed that was that ;) > Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? > Sean Turner: +1 to what ekr said > Rich Salz: +1 also >=20 > =20 >=20 > =20 >=20 > Regarding the next required steps I agree with Pete. Let=E2=80=99s = charter. >=20 > =20 >=20 > Ben Kaduk: So is this dispatch to BoF, or straight to WG? >=20 > Pete Resnick: @ben: Sounds like this discussion has done the = equivalent of BoFing. Charter. >=20 > =20 >=20 > Cheers, >=20 > John >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_0ED83293-A0FB-4BEE-886A-ABD545A4A94F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The jabber chat = certainly does not represent the room in any WG I have been in. I do not = think the slides represent an accurate summary of the what we are trying = to achieve by deprecating SDES or what we would need to do get there and = thus don=E2=80=99t lead to a useful input on what to do next or where to = dispatch it. 

As I said at the meeting, I am in favor of discussing and = solving the problems we need to sort out to have a viable replacement. = It is pretty hard to have a conversation about that in 10 minutes when = some of the people are arguing that SDES is worse than unencrypted = traffic. 

A= real good starting point to the conversation would be agreeing about = the fundamental differences - in my mind the largest difference is that = in DTLS-SRTP, the attacker has to be able to modify the SDP to MITM the = media while in SDES the attacker only needs to see the SDP to MITM the = media. 


On Jul 27, 2021, at 5:09 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:



On Tue, Jul 27, 2021 at 4:08 PM John = Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:

westhawk thp@westhawk.co.uk wrote:

 

>> On 26 =
Jul 2021, at 23:30, Kirsty P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP =
Security Descriptions is NOT RECOMMENDED and Historic: consensus was =
>sub-optimal. There was =
support for revisiting the space currently standardised >by SDP, but not on direction =
(whether to do a deprecation with/without >replacement). Future paths suggested included: =
mmusic, a new WG, more work >required for it to be ready, or a BoF (said in =
chat) to vet the idea further.
>My sense is =
that there was a rough consensus around a goal to make it possible >to deprecate SDES - but the =
required steps were unclear.

 

Yes, looking at the Jabber log there was quite strong support = for the goal of deprecating SDES:

 

Eric Rescorla: Let's all just agree that this (Mattson's = SDES) draft is a good idea and promote it to full standard toda


This was maybe slightly sarcastic but = for avoidance of doubt, I strongly support this work .

-Ekr

Martin Thomson: now that I see John presenting this, I have to wonder: = why didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I = assumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

 

 

Regarding the next = required steps I agree with Pete. Let=E2=80=99s charter.

 

Ben Kaduk: So is this dispatch to BoF, or straight = to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. = Charter.

 

Cheers,

John

=
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_0ED83293-A0FB-4BEE-886A-ABD545A4A94F-- From nobody Wed Jul 28 07:06:35 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB83A11D5 for ; Wed, 28 Jul 2021 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp_rtDzzoBGs for ; Wed, 28 Jul 2021 07:06:27 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00044.outbound.protection.outlook.com [40.107.0.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5003A11D4 for ; Wed, 28 Jul 2021 07:06:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NjRgRANdMppy9Zm/8XkGzmnUuYigxYLV3OBO3cVYg099nuhQjyjAgjoh1bZ6tLybtS0IVw2MBfmm4IOKnzz2wBJrSRZ/5xV+a48xSfM4l4EDJa11LYi5mgK+RaLeCH4ltAti+LUd3oqLlKuUF3Z76dMTjc5HglxNRrYp8ux4fvMUJVNoLKlnLfFGH2OyrCsMDQIkzA92CxlLut5ztenkQkMZG9SPnewfIe3WO4PIMjs45QId8kQZKaLgGWQlDh56ZVWcp3uHL/7cvM80+ZfsPoyWbcNtRXEmorb5htfyLmGpZrJurMw0B5cO+L+ZFo9LV6k2BXAgJX+dEFhFobbFLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TFBenhGLHC868e0KU9rgViTZ2hIsrWbhEqd9nOA86vY=; b=nkCkS0n+KuhS9Z36PTsvB8Ahq6pUQaoeWwRUjZK4DvZLncXt0p8G3eSGxIhrSrc6uMvSMfJv8NpITlZ8p3a5GviLOH8kQvAfesnvVqfk0YwTL3t8xwPRMUjovFq61uDpeKKqzUMDLai1NQyLSDi8Grl7RtaBz/1myK80JlnDcSx3iqYEr+aGntVCLjvqPHJsBMTPOB28n5jWPjSdx5kR8HRNMZJYIjoMtSjRqD1WCK68nedBal1b+3mXN/ArpTd97xwZzEh1RwFj7dwWnO1yhjAehDYve577d68+nRlFXL1W8CHYacsZWYjESCWi3QErkfiip03RQJWVMWxg0938sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TFBenhGLHC868e0KU9rgViTZ2hIsrWbhEqd9nOA86vY=; b=oKYI38C8xNrFw1T8xn86ictUaB8aiOrrmuBFqAwPOk4A5+1axICCVrrRJNP+o/NINdv4EjXYBXyl6EGKYrKW/YJ/n83otMHVjFDUEktmqaC8O3VRVe6vqSR3POEezZY5Ec7yVWI73j3TQ/8h3u2Jhp9NDksZLg7J4+ot1SPqG80= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2828.eurprd07.prod.outlook.com (2603:10a6:3:4e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.12; Wed, 28 Jul 2021 14:06:24 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b%5]) with mapi id 15.20.4373.018; Wed, 28 Jul 2021 14:06:24 +0000 From: John Mattsson To: "dispatch@ietf.org" Thread-Topic: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes Thread-Index: AQHXg7f+VAt6vk/Y70iD7lj2ik2zfA== Date: Wed, 28 Jul 2021 14:06:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a86ebfc6-78ed-452f-0caf-08d951d0e23a x-ms-traffictypediagnostic: HE1PR0701MB2828: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SY42P+ze5h8mPn+nvd/4M71QD1elSdoPQddD0/qJODcWK9uNQlJRdy+R0w4QPDpyTShA3lpCqV5SYfK+/5zBjjBcgpUyTuD5fEOWNauIsji7dDOMrFlGMisxJZBIU3LKVqqXuRgy7rMQ/vDM1+iT9w+3IWlPXdT5+x/bVARG1PE3s/+XUMzhwxv8ZTmcyPML8eTUqWfs9R1kLloK8FIpAkf5bhwBDQ0TDLUGfZEzu7STxq69G7eWrPt6HklGJPziPY5psl4FvDeW108FCwF+vhjOJ/SSvrLcra2WY4rdqAkTeUFUIuo3CWtMEjWf2fJtFXT0wiqjHXd2vlGhDpjbF4Zby+dFCbYaYfb4rCbpxLNQ1UiSSrSzDx3VVU0yHANXwoZvzfU908JxewxGv8l/vPQ2g+6IZZk4ZdgthBT1Wrv6MRrPH6hQDa56zyLp4t1G1TlRkyHl27YddXFnXCzwk7CfEOuJ5KFjU5lxLQZ6hv/OPtV2cTCInwWvqoKm5k8eHirCrMez07nlrl6OuS/fcSjeNhRf9iiJFUq4MHzqkoyMnMO7OW/0PK0Sl+gFBHM95O8luC9jGmg7HxEZYA6QxGnM+NvpnXq3TfK5EVO2KTO6yYI5miwmRnt9uUz4uWnROHEUegR1wuxNGLkR/afb4OzDvfv9xpmigAlNOkLZEUEGhQb6NvQmrpsO8BOe1BODwJ7XMHDepgp3anVtFv4+vw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(83380400001)(55016002)(9686003)(8936002)(33656002)(7696005)(8676002)(76116006)(66476007)(66556008)(64756008)(66446008)(122000001)(38100700002)(86362001)(2906002)(38070700005)(26005)(66946007)(6916009)(5660300002)(316002)(44832011)(52536014)(71200400001)(508600001)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PZ2i1RvU4+MyBd1FLY+U98JwTn4Bj4tyUWoLQllbwVPQGFCxrBD5U+GZwm5E?= =?us-ascii?Q?Rqzex7ieNEyN2P3+r/Wvx5UPlj6AtWq6g+kmO67Bzn11d6ZNOV4xzpCOwFw6?= =?us-ascii?Q?VpXxVport8ONxVy+zDKGJBrTDht1oP4c/+fypVh3nv/QJokAkiMVyV4lb5q/?= =?us-ascii?Q?7lCyKP9dHXJfU/hWcoYlq8gOiFbEgt0gUZXr6oMOboH2PPe6vGhre1tqQ8lC?= =?us-ascii?Q?/crQM7BVzog+tNWQRiTXt7xiX6rhT3D2l73xN7BpV6A89YuPtA9llDgTcoe2?= =?us-ascii?Q?q4dF1DNppRuyCUiQhD0dXJEwAu3M07lt14ChlP3FfkMgQ+EH6b3vNziGft0n?= =?us-ascii?Q?j3pqzSxuEZqjpdYixuQ/CD2jqGfmsbBvRMiwspTYMzzNj0OkBescuAFKS1XP?= =?us-ascii?Q?U+toMuOmlq0SMtjfLpYtGHYsie4euuXvepS65bak39yQYUA0G6zove1OsWDl?= =?us-ascii?Q?/pSz3Cs5kbLhFhG/LNuN88coQMR6Vc4cOlv5Ji3hqoXK6aJluQM6RyU6p6i2?= =?us-ascii?Q?D/bmiOO+nAWP73cJ2oVtpP3Z49OnZQlaj3JL7PclMn43dL76JZgUYsu8Uu42?= =?us-ascii?Q?VmPbxk2j5c4K275fEl862AQ0OCQUiZBJIcNCM0fZZkSXV4Z7hUJx99/lPgmQ?= =?us-ascii?Q?/nNPxr843D95fXMlQeacMytWKxgIs1/0ePdqwMTWAVS1dJ+y/QtxMh3R+/Am?= =?us-ascii?Q?RUWBWO1BDXVeNsL7vVV+73k3/qELHrvxJKkAhd6AKprFOBLD6t6i5AS9nnJc?= =?us-ascii?Q?O9ROr6/8UIT5vAqBpfPBbnhtVVDrNWlBTsePvMhOqOWGPn4TQoKSEA+QX0oh?= =?us-ascii?Q?QpeKkr3rplKZoPBi6JIhri7mfelwYNCwNc8uvBuZG7ysLl78EJ/vSevATtl2?= =?us-ascii?Q?9hUmAtM1j8ESnb5m3sPaJNOzrNSGz5SIw35NrHJju611gVUS+8JLM01gn3FN?= =?us-ascii?Q?jqoIw6uUzvonEpcWFdUo0ePQ2+yZA7BEp2EC3jbdmxknmlozC+sH038DkW5y?= =?us-ascii?Q?32h6hpbRbkWC2UN8T/QLuFgXkIU8Jd8SylaEPWs2r8k1KzjtAu2AOGwXhNwU?= =?us-ascii?Q?u5jqfR/60LZHsWpUwRMfCY3eZM0CO1An8snK5Uz62unDTVrjY2ncOkjaEcB7?= =?us-ascii?Q?x0ly+kUG/DSSm6CPX2lMZrKEKp58oxkrgjXVoS1FjYJ+El6Jq2kXS6KCMU4o?= =?us-ascii?Q?vie/inmCGpCK2GIXVFGRS03eLDOgtkRc+c1LEpegIzITk1mU2UfjTWV6yov+?= =?us-ascii?Q?Wx/n83lKB4msueUN8D2xtoTBzOV8GhPNkEfqpPxkedEh4MH7NoiTd3uSfKrC?= =?us-ascii?Q?Kgekl2dqDhkxfQAuKyoj5/oMoL92IIWfeDdhrFJOPuasKw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30501CC4FFC0449B0140CF3D89EA9HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a86ebfc6-78ed-452f-0caf-08d951d0e23a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 14:06:23.8629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DxCUXcBd2H3ZRGXJ8IYaE1pyonhvljvvZ23dUxnvIdb6DcRiGlDOjdi5hs7g+d6ptrcvx2+dvD/JqVkQAQf4HQxKbthp7btkHPPGJgsN1nc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2828 Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 14:06:33 -0000 --_000_HE1PR0701MB30501CC4FFC0449B0140CF3D89EA9HE1PR0701MB3050_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen Jennings wrote: > when some of the people are arguing that SDES is worse than unencrypted t= raffic. I don't think stating that SDES gives a false sense of security is strange = at all. To quote what US government recently stated about TLS 1.0 and 1.1: = "Using obsolete encryption provides a false sense of security because it ma= y look as though sensitive data is protected, even though it really is not.= " I would say that RFC 4568 is on the same level or worse. > A real good starting point to the conversation would be agreeing about th= e fundamental differences > - in my mind the largest difference is that in DTLS-SRTP, the attacker ha= s to be able to modify > the SDP to MITM the media while in SDES the attacker only needs to see th= e SDP to MITM the media. If we can agree on the goal of starting work on enabling long-term deprecat= ion of SDES, I don't see that much use in detailing the security weaknesses= of SDES for different deployments. The curent draft and the presentation c= ontains a litterature study, I would suggest removing most of that instead = of spending too much time expanding it. > I am in favor of discussing and solving the problems we need to sort out = to have a viable replacement. I agree. Roman suggested to create a new WG for discussions and to develop = alternatives. I think that is a good way forward. A WG would be a good plac= e for discussions. Based on yours and Bernards comments, I agree that RFC 4= 568 can likely not be depracated right now. --_000_HE1PR0701MB30501CC4FFC0449B0140CF3D89EA9HE1PR0701MB3050_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cullen Je= nnings <fluffy@iii.ca> wrote:

 

> when= some of the people are arguing that SDES is worse than unencrypted traffic= .

&nbs= p;

I don't t= hink stating that SDES gives a false sense of security is strange at all. T= o quote what US government recently stated about TLS 1.0 and 1.1: "Usi= ng obsolete encryption provides a false sense of security because it may look as though sensitive data is protected, eve= n though it really is not." I would say that RFC 4568 is on the same l= evel or worse.

&nbs= p;

&nbs= p;

> A re= al good starting point to the conversation would be agreeing about the fund= amental differences

> - in= my mind the largest difference is that in DTLS-SRTP, the attacker has to b= e able to modify

> the = SDP to MITM the media while in SDES the attacker only needs to see the SDP = to MITM the media.

&nbs= p;

If we can= agree on the goal of starting work on enabling long-term deprecation of SD= ES, I don't see that much use in detailing the security weaknesses of SDES = for different deployments. The curent draft and the presentation contains a litterature study, I would suggest r= emoving most of that instead of spending too much time expanding it.

&nbs= p;

&nbs= p;

> I am= in favor of discussing and solving the problems we need to sort out to hav= e a viable replacement.

&nbs= p;

I agree. = Roman suggested to create a new WG for discussions and to develop alternati= ves. I think that is a good way forward. A WG would be a good place for dis= cussions. Based on yours and Bernards comments, I agree that RFC 4568 can likely not be depracated right now.

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

--_000_HE1PR0701MB30501CC4FFC0449B0140CF3D89EA9HE1PR0701MB3050_-- From nobody Wed Jul 28 07:34:13 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC383A12E1 for ; Wed, 28 Jul 2021 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5qoNPX8q9nL for ; Wed, 28 Jul 2021 07:34:07 -0700 (PDT) Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3513A12DA for ; Wed, 28 Jul 2021 07:34:06 -0700 (PDT) Received: (qmail 14700 invoked from network); 28 Jul 2021 14:33:59 -0000 X-APM-Out-ID: 16274828391469 X-APM-Authkey: 255286/0(159927/0) 1260 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 28 Jul 2021 14:33:59 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4044880F25 for ; Wed, 28 Jul 2021 15:33:59 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UjFbpCNOg6RT for ; Wed, 28 Jul 2021 15:33:59 +0100 (BST) Received: from phage-rock.fritz.box (p2e5a58d4.dip0.t-ipconnect.de [46.90.88.212]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 24FF880A83 for ; Wed, 28 Jul 2021 15:33:59 +0100 (BST) From: westhawk Content-Type: multipart/alternative; boundary="Apple-Mail=_4BECB06B-C4AE-4F76-8593-B62082924FBB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 28 Jul 2021 16:33:52 +0200 References: <63B7ABE0-A546-4354-A2FB-002CC22D50BB@iii.ca> To: "dispatch@ietf.org" In-Reply-To: <63B7ABE0-A546-4354-A2FB-002CC22D50BB@iii.ca> Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 14:34:12 -0000 --Apple-Mail=_4BECB06B-C4AE-4F76-8593-B62082924FBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jul 2021, at 06:13, Cullen Jennings wrote: >=20 > As I said at the meeting, I am in favor of discussing and solving the = problems we need to sort out to have a viable replacement. I didn=E2=80=99t hear any criteria for judging a replacement=E2=80=99s = viablility . I did hear "carriers won=E2=80=99t move from SDES=E2=80=9D and =E2=80=9CTh= e Queen uses SDES=E2=80=9D (paraphrased) It seems unlikely any replacement can overcome those two objections.=20 Tim. --Apple-Mail=_4BECB06B-C4AE-4F76-8593-B62082924FBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jul 2021, at 06:13, Cullen Jennings <fluffy@iii.ca> = wrote:

As I said at the meeting, I am = in favor of discussing and solving the problems we need to sort out to = have a viable replacement.

I didn=E2=80=99t hear any criteria for = judging  a replacement=E2=80=99s viablility .
I = did hear "carriers won=E2=80=99t move from SDES=E2=80=9D and =E2=80=9CThe = Queen uses SDES=E2=80=9D (paraphrased)
It seems = unlikely any replacement can overcome those two = objections. 

Tim.




= --Apple-Mail=_4BECB06B-C4AE-4F76-8593-B62082924FBB-- From nobody Wed Jul 28 10:26:26 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35753A192A for ; Wed, 28 Jul 2021 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htje3GHSmx43 for ; Wed, 28 Jul 2021 10:26:20 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9333A192E for ; Wed, 28 Jul 2021 10:26:19 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id 184so3011361qkh.1 for ; Wed, 28 Jul 2021 10:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JXThm+3TytaPxZ3+/98vLWjfBHBTHWbxKatz74ZD3cg=; b=FiNY9l71Q+619EY2W2ODMk+FR4uYGERiItRyd3aRPnlK4DO0dFO10rBNhibCkhZFhH pmnpg05n+3wOYYdtboePP7dOa7M84bGh2rZvFzpGKatuYKIUN4Zm61Q/KPM6NjyOgQIg Ge0ZkOHyBnQwzQ5q0cvLZPNj8YYm6VYK6sSHwrk+hCuXTGapI+b29iPs9ScnwguNMKyC bDa6WWVXhGPb2i6MrrZD/v74qIFmJkv+pnXB/ekm6Kh3nkiq4OmuP190ARjQ2HXJJOYc v2JVKTNyBRzqkzQ0lZjRGHOnXvLON+9sQBPs8L34iwcxPd6KrCxkY24X4sT3UCtrhDaX hYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JXThm+3TytaPxZ3+/98vLWjfBHBTHWbxKatz74ZD3cg=; b=BpDPKRLvRhCmWKf1KLjT4z3ogEf/Unlv048BUgJEZM+EY8eE3YwE3I+IFfo+CkAye7 +yqw7X4f/JwQqIMUxAU5CTeoYapTMAfrVbgiZE1/h21oTgvPs9zGZtNCEKNAeJM4BiVb 9k9XkNIWRjhtLpivTCAP3/TbQLG2iUVmv1XscqDtMheERCsGcBti1mZvcR9O06asJnRR 0LkwfybX83DX8jOCqk00uX1Uo9OR7jiSaU5KqvdbOmWwY/Q9Vo8PNI4v4FoqJW5OBw4Z t9s1b9Tzdi0a9U3cFW0vfmjrMwFWWbdtl50qBZOrUbfWLBUhbOKUo1lsD70vjxhP7l2+ pEew== X-Gm-Message-State: AOAM531/ZTq1pO67I5EtjTxnAQXLAomXxV/aHbW/ZXCiidmEYZwzANc9 HdgP1oqKiep5eU1roKxsZXx9KDFoKDK1UY/ZPYcv7c4rLWYREw== X-Google-Smtp-Source: ABdhPJwxupbkKTL0yVWj4ezw0Shotiz9VQlbz5ACndeBo/osgFgw9zR4grvKF6dMChOmE43rgh/1LlbsCllYLGCi/VE= X-Received: by 2002:a37:aa57:: with SMTP id t84mr723305qke.371.1627493177953; Wed, 28 Jul 2021 10:26:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 28 Jul 2021 13:26:06 -0400 Message-ID: To: John Mattsson Cc: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf2be505c8324805" Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 17:26:25 -0000 --000000000000bf2be505c8324805 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I hate sending symmetric keys around as much as the next person. But we should be pragmatic here. The situation with SDES is unlike the situation with a bunch of the other deprecations we have done recently (SSLv3, TLS 1.0). There, the protocol was broken, in the sense that it does not provide the guarantees that it is supposed to provide. Here, SDES still does what it says on the label, just like it always has; we=E2=80=99re just increasingly grumpy about that model= and there are somewhat better alternatives. Note =E2=80=9Csomewhat=E2=80=9D =E2=80=94 DTLS-SRTP is only better than SDE= S to the extent that the certificates in the DTLS exchange are verified independent of the signaling path. If you rely only on the fingerprint in SDP for authentication, then an SDP-path entity can swap out fingerprints to intercept get keys just as well as with SDES. (At best, this swaps an active for a passive attack, which is not nothing, but not a huge step.) We do have mechanisms for such verification, but they=E2=80=99re not widely deployed. All of which tells me that there's not an urgent need for action here. SDES is not a looming threat to the Internet. In the many deployments where it is used, it still does what it claims to do, and people have accommodated that into their broader system models. Even if there were to be a mass migration to DTLS-SRTP, the actual security benefit for all that work would be fairly minor until we do a lot more work to solve the authentication problems. So if folks want to make a bigger, scarier warning label to put on SDES to guide people away from it, sure, fine. But it doesn=E2=80=99t seem like a = blaring red warning light is called for. In terms of this document, the content is probably mostly OK if we reframe it in that light. Obsoleting SDES and marking it Historic, though, is over the top; it will just create unnecessary consternation. --Richard On Tue, Jul 27, 2021 at 7:08 PM John Mattsson wrote: > westhawk thp@westhawk.co.uk wrote: > > > > >> On 26 Jul 2021, at 23:30, Kirsty P <<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org>> >wrote: > > >> > > >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus w= as >sub-optimal. There was support for revisiting the space currently stand= ardised >by SDP, but not on direction (whether to do a deprecation with/wit= hout >replacement). Future paths suggested included: mmusic, a new WG, more= work >required for it to be ready, or a BoF (said in chat) to vet the idea= further. > > >My sense is that there was a rough consensus around a goal to make it po= ssible >to deprecate SDES - but the required steps were unclear. > > > > Yes, looking at the Jabber log there was quite strong support for the goa= l > of deprecating SDES: > > > > Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a > good idea and promote it to full standard toda > Martin Thomson: now that I see John presenting this, I have to wonder: wh= y > didn't this deprecation happen before? > Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I > assumed that was that ;) > Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? > Sean Turner: +1 to what ekr said > Rich Salz: +1 also > > > > > > Regarding the next required steps I agree with Pete. Let=E2=80=99s charte= r. > > > > Ben Kaduk: So is this dispatch to BoF, or straight to WG? > > Pete Resnick: @ben: Sounds like this discussion has done the equivalent > of BoFing. Charter. > > > > Cheers, > > John > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000bf2be505c8324805 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hate sending symmetric keys around as much as the next p= erson.=C2=A0 But we should be pragmatic here.

The situation with SDE= S is unlike the situation with a bunch of the other deprecations we have do= ne recently (SSLv3, TLS 1.0).=C2=A0 There, the protocol was broken, in the = sense that it does not provide the guarantees that it is supposed to provid= e.=C2=A0 Here, SDES still does what it says on the label, just like it alwa= ys has; we=E2=80=99re just increasingly grumpy about that model and there a= re somewhat better alternatives.

Note =E2=80=9Csomewhat=E2=80=9D =E2= =80=94 DTLS-SRTP is only better than SDES to the extent that the certificat= es in the DTLS exchange are verified independent of the signaling path.=C2= =A0 If you rely only on the fingerprint in SDP for authentication, then an = SDP-path entity can swap out fingerprints to intercept get keys just as wel= l as with SDES.=C2=A0 (At best, this swaps an active for a passive attack, = which is not nothing, but not a huge step.)=C2=A0 We do have mechanisms for= such verification, but they=E2=80=99re not widely deployed.

All of = which tells me that there's not an urgent need for action here.=C2=A0 S= DES is not a looming threat to the Internet.=C2=A0 In the many deployments = where it is used, it still does what it claims to do, and people have accom= modated that into their broader system models.=C2=A0 Even if there were to = be a mass migration to DTLS-SRTP, the actual security benefit for all that = work would be fairly minor until we do a lot more work to solve the authent= ication problems.

So if folks want to make a bigger, scarier warning= label to put on SDES to guide people away from it, sure, fine.=C2=A0 But i= t doesn=E2=80=99t seem like a blaring red warning light is called for.=C2= =A0 In terms of this document, the content is probably mostly OK if we refr= ame it in that light.=C2=A0 Obsoleting SDES and marking it Historic, though= , is over the top; it will just create unnecessary consternation. =C2=A0
--Richard

On Tue, Jul 27, 2021 at 7:08 PM John Mattsson <john.matt= sson=3D40ericsson.com@dmar= c.ietf.org> wrote:

westhawk thp@westhawk.co.uk wrote:

=C2=A0

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

=C2=A0

Yes, looking at the Jabber log = there was quite strong support for the goal of deprecating SDES:<= /u>

=C2=A0

Eric Rescorla: Let's all just agree that this = (Mattson's SDES) draft is a good idea and promote it to full standard t= oda
Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

=C2=A0

=C2=A0

Regarding the next required ste= ps I agree with Pete. Let=E2=80=99s charter.

=C2=A0

Ben Kaduk: So is this dispatch to BoF, or straight to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Chart= er.

=C2=A0

Cheers,

John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000bf2be505c8324805-- From nobody Wed Jul 28 10:32:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04F83A197C for ; Wed, 28 Jul 2021 10:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nctAi9NxoMeS for ; Wed, 28 Jul 2021 10:32:45 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3B63A1976 for ; Wed, 28 Jul 2021 10:32:45 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id a13so3837475iol.5 for ; Wed, 28 Jul 2021 10:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R+5tmT7JTcIPwlNieFx86frEm1n/iY8kUbjS0xE5oXk=; b=VBBye2EYvDx7cAsVrmmWYSA327Uaa26ig1XnXdR1FdGE/h496m6NqzZN5jMbaRa7on fh+ztIsnOZYAZD5g+Nl7v0bM4eC17Pby1IpSFPB7bJfIUILhMsnJkFvlDpn6Nr31X8Hv WNhNRmEA8cJo2ZQuojsbcsPWinopZ8cBhbMJgDKexyCODmkhDv2YT0HRLXJBMwQKvtXX y3K+ARDE+lIKHyA7EUAdDPRyXxbe5zTba0DJN8bbVzwz/H8hgcqrybgq1o2yo879/SXH ZRiC8hZMQZ0qkcCFXPZJLYN+uHCrGKi66bTVUOKZvSgxD5Q37NRIDYBp/G41E/gBRmsi pXdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R+5tmT7JTcIPwlNieFx86frEm1n/iY8kUbjS0xE5oXk=; b=QfgBhBrb7mJ60mGa5C6Q5mfBbZ5+OiDXp+Hcl6PysAKZYFd1OQ+hV7HbQfNQbcpA6t RJ4Zx5NcZoQeUkYCeYhyJwD1vjQcAuCXQOhELvsm0Tl2QIyn6EGxjskuhX+k5iLB2WG1 609x66CIezFmFabW19rbcjd4QfMT/m8pRKDquQHHKXwdaFlqX4FUv47abMxBdUa3+Y+6 11fyV0JLqIFa+2PKZbbyPYi7cuHrKwMWJa2+YzE5mvMqSCgGWWmgWCGlJ1LLKs31Ms4Y 3VQdY2ZUSCxIGD3hBMlB385DF9enfb0NnNwYOyK15WYw0dLV/1HiT/iYti7kPmij46IS lcYA== X-Gm-Message-State: AOAM531hZc75SwFUG5qYw/0KNoG9PIibMq2dq/mIPelqyefaKezTLh76 AST3/CPmPy3k5tZTfdtpwEwhJ1k9csX3OXvHKtXiTkFcqFiOdA== X-Google-Smtp-Source: ABdhPJyGHs5ptpbn3uVcbr1VE0XmF1Kj5VbDnLRUGuqmYwoSjtQ9uF4YRvDw4QJp/LCzQQuc1eFRcYyZUxoPIAVcKe8= X-Received: by 2002:a05:6602:2491:: with SMTP id g17mr492969ioe.98.1627493564433; Wed, 28 Jul 2021 10:32:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 28 Jul 2021 10:32:08 -0700 Message-ID: To: Richard Barnes Cc: John Mattsson , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c861bf05c8325f5b" Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 17:32:51 -0000 --000000000000c861bf05c8325f5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 28, 2021 at 10:26 AM Richard Barnes wrote: > I hate sending symmetric keys around as much as the next person. But we > should be pragmatic here. > > The situation with SDES is unlike the situation with a bunch of the other > deprecations we have done recently (SSLv3, TLS 1.0). There, the protocol > was broken, in the sense that it does not provide the guarantees that it = is > supposed to provide. Here, SDES still does what it says on the label, ju= st > like it always has; we=E2=80=99re just increasingly grumpy about that mod= el and > there are somewhat better alternatives. > > Note =E2=80=9Csomewhat=E2=80=9D =E2=80=94 DTLS-SRTP is only better than S= DES to the extent that > the certificates in the DTLS exchange are verified independent of the > signaling path. If you rely only on the fingerprint in SDP for > authentication, then an SDP-path entity can swap out fingerprints to > intercept get keys just as well as with SDES. (At best, this swaps an > active for a passive attack, which is not nothing, but not a huge step.) > Well, we don't really have a definition for "huge", but: 1. I don't think swapping a passive attack for an active attack is trivial. After all, that's much of the premise of 7258. 2. It's not just a matter of "passive attack" but rather of the fact that SDES turns any logs/debugging/traffic monitoring/etc. that contains the SDP into toxic waste that has to be carefully guarded. > So if folks want to make a bigger, scarier warning label to put on SDES t= o > guide people away from it, sure, fine. But it doesn=E2=80=99t seem like = a blaring > red warning light is called for. In terms of this document, the content = is > probably mostly OK if we reframe it in that light. Obsoleting SDES and > marking it Historic, though, is over the top; it will just create > unnecessary consternation. > I'm not really following your argument here. We all agree that (1) SDES is bad (2) We have better alternatives in the form of DTLS-SRTP and (eventually) MLS-SRTP. So, precisely what harm is it doing to tell people that and that they shouldn't use SDES in favor of that. "consternation" is not a real harm. -Ekr > --Richard > > On Tue, Jul 27, 2021 at 7:08 PM John Mattsson 40ericsson.com@dmarc.ietf.org> wrote: > >> westhawk thp@westhawk.co.uk wrote: >> >> >> >> >> On 26 Jul 2021, at 23:30, Kirsty P <<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org>> >wrote: >> >> >> >> >> >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus = was >sub-optimal. There was support for revisiting the space currently stan= dardised >by SDP, but not on direction (whether to do a deprecation with/wi= thout >replacement). Future paths suggested included: mmusic, a new WG, mor= e work >required for it to be ready, or a BoF (said in chat) to vet the ide= a further. >> >> >My sense is that there was a rough consensus around a goal to make it p= ossible >to deprecate SDES - but the required steps were unclear. >> >> >> >> Yes, looking at the Jabber log there was quite strong support for the >> goal of deprecating SDES: >> >> >> >> Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is = a >> good idea and promote it to full standard toda >> Martin Thomson: now that I see John presenting this, I have to wonder: >> why didn't this deprecation happen before? >> Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I >> assumed that was that ;) >> Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? >> Sean Turner: +1 to what ekr said >> Rich Salz: +1 also >> >> >> >> >> >> Regarding the next required steps I agree with Pete. Let=E2=80=99s chart= er. >> >> >> >> Ben Kaduk: So is this dispatch to BoF, or straight to WG? >> >> Pete Resnick: @ben: Sounds like this discussion has done the equivalent >> of BoFing. Charter. >> >> >> >> Cheers, >> >> John >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000c861bf05c8325f5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 28, 2021 at 10:26 AM Rich= ard Barnes <rlb@ipv.sx> wrote:
<= /div>
I h= ate sending symmetric keys around as much as the next person.=C2=A0 But we = should be pragmatic here.

The situation with SDES is unlike the situ= ation with a bunch of the other deprecations we have done recently (SSLv3, = TLS 1.0).=C2=A0 There, the protocol was broken, in the sense that it does n= ot provide the guarantees that it is supposed to provide.=C2=A0 Here, SDES = still does what it says on the label, just like it always has; we=E2=80=99r= e just increasingly grumpy about that model and there are somewhat better a= lternatives.

Note =E2=80=9Csomewhat=E2=80=9D =E2=80=94 DTLS-SRTP is = only better than SDES to the extent that the certificates in the DTLS excha= nge are verified independent of the signaling path.=C2=A0 If you rely only = on the fingerprint in SDP for authentication, then an SDP-path entity can s= wap out fingerprints to intercept get keys just as well as with SDES.=C2=A0= (At best, this swaps an active for a passive attack, which is not nothing,= but not a huge step.)=C2=A0

Well, we= don't really have a definition for "huge", but:
1. I don't think swapping a passive attack for an active a= ttack is trivial. After all, that's much of the premise of 7258.
<= div>2. It's not just a matter of "passive attack" but rather = of the fact that SDES turns any logs/debugging/traffic monitoring/etc. that= contains the SDP into toxic waste that has to be carefully guarded.



So if folks want to make a bigger, scarier war= ning label to put on SDES to guide people away from it, sure, fine.=C2=A0 B= ut it doesn=E2=80=99t seem like a blaring red warning light is called for.= =C2=A0 In terms of this document, the content is probably mostly OK if we r= eframe it in that light.=C2=A0 Obsoleting SDES and marking it Historic, tho= ugh, is over the top; it will just create unnecessary consternation. =C2=A0=

I'm not really following you= r argument here. We all agree that (1) SDES is bad (2) We have better alter= natives in the form of DTLS-SRTP and (eventually) MLS-SRTP. So, precisely w= hat harm is it doing to tell people that and that they shouldn't use SD= ES in favor of that. "consternation" is not a real harm.

-Ekr


--Richard

On Tue, Jul 27, 2021 at= 7:08 PM John Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wr= ote:

westhawk thp@westhawk.co.uk wrote:

=C2=A0

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

=C2=A0

Yes, looking at the Jabber log = there was quite strong support for the goal of deprecating SDES:<= /u>

=C2=A0

Eric Rescorla: Let's all just agree that this = (Mattson's SDES) draft is a good idea and promote it to full standard t= oda
Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

=C2=A0

=C2=A0

Regarding the next required ste= ps I agree with Pete. Let=E2=80=99s charter.

=C2=A0

Ben Kaduk: So is this dispatch to BoF, or straight to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Chart= er.

=C2=A0

Cheers,

John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000c861bf05c8325f5b-- From nobody Wed Jul 28 10:59:37 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B19E3A0C3E for ; Wed, 28 Jul 2021 10:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwp5McNkvlau for ; Wed, 28 Jul 2021 10:59:24 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC933A1A66 for ; Wed, 28 Jul 2021 10:59:23 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id d9so1957261qty.12 for ; Wed, 28 Jul 2021 10:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9+L6PdEN/QDr2AVVnQP7nigSvU5aZAB32oBaSknr6E4=; b=FPCRJHAjCCutn2JVLWsqKe0dt0uNsn3HqeZvmgoRFDsI/jQVQOpXr0yvh8Cn2zckoJ zDwep42d8cuRXCszczLCYxocLRTq3wjUBcw1PTEZwuEHHFFv8hjBOUphAbzsrDQMB2IK CKAlVIIJxcVZ9Y3YX3q5kMzzBAXcZgnIcshgcLfMUAqKZnO4qld6kjyKi34MdmzRwEeC vTbiCjBeQrYr3InB35IrncGEfej0kkBbaBYS9ib0A+eYGpXYhJPvonb9gNfUmAZyq6nG I7q9tnrnV/nB+tWEuUaiPJG0X9diOxnkjfjHejF/jM4ncvXOQdxqiHftN06L3JJqmqaU 9FeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9+L6PdEN/QDr2AVVnQP7nigSvU5aZAB32oBaSknr6E4=; b=bcg1P67l+MiTahtnEGSqlX1a9jphS4i/0dVUKuZhKAmIjN83fYePgvfrIAFE1zaCCb 9X4gqCNmkkNlhxhqffoyuIrF9ybJE4WJ3ewTw/6zILHmtPRYZN6qCd5HA3Z/v3W2qNYB 3fULTgq06Ro8gHzXtnHTxAQhtgqqydvo6CteM43pYLmwjtmzGU+KUR3iDq9sFY4FZsfh XnKaREB3m3J3Aq/VdHNmKYHiJEtDhOuDzbJn7mlrrEh3QK15pS1b111XVvzw+uvtK7w8 wkBI5rpIhkBPWJgi/ccX/qnHOo7FS/OT4RSbYg42HrBGvBkbKXngjZ42ySVonkBQfceb V1DA== X-Gm-Message-State: AOAM5313NbCYcpQjp8/e96pIeYWsQBqupw39NitEw28rtZ+k+dv5/NqM kOC3CeHrdu0FTv7FrMaxARy4rXWAgOpOv3RxKb28CvG5U0g= X-Google-Smtp-Source: ABdhPJzBm0ONa3HngYAalZCorZAg24GFFEoiJ0xy1/k48corg17ZZn7SR6KJdLvoHeKC2p1ly9C37vm12FBiUHSFC/Y= X-Received: by 2002:ac8:6e9c:: with SMTP id c28mr748977qtv.84.1627495161313; Wed, 28 Jul 2021 10:59:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 28 Jul 2021 13:59:08 -0400 Message-ID: To: Eric Rescorla Cc: John Mattsson , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6d53f05c832be3e" Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 17:59:37 -0000 --000000000000f6d53f05c832be3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 28, 2021 at 1:32 PM Eric Rescorla wrote: > > >> So if folks want to make a bigger, scarier warning label to put on SDES >> to guide people away from it, sure, fine. But it doesn=E2=80=99t seem l= ike a >> blaring red warning light is called for. In terms of this document, the >> content is probably mostly OK if we reframe it in that light. Obsoletin= g >> SDES and marking it Historic, though, is over the top; it will just crea= te >> unnecessary consternation. >> > > I'm not really following your argument here. We all agree that (1) SDES i= s > bad (2) We have better alternatives in the form of DTLS-SRTP and > (eventually) MLS-SRTP. So, precisely what harm is it doing to tell people > that and that they shouldn't use SDES in favor of that. "consternation" i= s > not a real harm. > We agree with regard to the future. What are operators of existing systems using SDES supposed to take away from this? This is not like say the SSLv3 deprecation where we had new data (POODLE) that changed the posture of these systems. Systems based on SDES are as secure / insecure as they ever were. So what I'm worried about is (a) the IETF looking alarmist for marking a bunch of things insecure that are actually fine, and (b) to the degree the deprecation is taken seriously, creating a bunch of work to upgrade from SDES to a flavor of DTLS-SRTP that is not enough better to merit the effort. --Richard > > -Ekr > > >> --Richard >> >> On Tue, Jul 27, 2021 at 7:08 PM John Mattsson > 40ericsson.com@dmarc.ietf.org> wrote: >> >>> westhawk thp@westhawk.co.uk wrote: >>> >>> >>> >>> >> On 26 Jul 2021, at 23:30, Kirsty P <<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org>> >wrote: >>> >>> >> >>> >>> >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus= was >sub-optimal. There was support for revisiting the space currently sta= ndardised >by SDP, but not on direction (whether to do a deprecation with/w= ithout >replacement). Future paths suggested included: mmusic, a new WG, mo= re work >required for it to be ready, or a BoF (said in chat) to vet the id= ea further. >>> >>> >My sense is that there was a rough consensus around a goal to make it = possible >to deprecate SDES - but the required steps were unclear. >>> >>> >>> >>> Yes, looking at the Jabber log there was quite strong support for the >>> goal of deprecating SDES: >>> >>> >>> >>> Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is >>> a good idea and promote it to full standard toda >>> Martin Thomson: now that I see John presenting this, I have to wonder: >>> why didn't this deprecation happen before? >>> Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - = I >>> assumed that was that ;) >>> Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? >>> Sean Turner: +1 to what ekr said >>> Rich Salz: +1 also >>> >>> >>> >>> >>> >>> Regarding the next required steps I agree with Pete. Let=E2=80=99s char= ter. >>> >>> >>> >>> Ben Kaduk: So is this dispatch to BoF, or straight to WG? >>> >>> Pete Resnick: @ben: Sounds like this discussion has done the equivalent >>> of BoFing. Charter. >>> >>> >>> >>> Cheers, >>> >>> John >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --000000000000f6d53f05c832be3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 28, 2021 at 1:32 PM Eric Resc= orla <ekr@rtfm.com> wrote:


So if folks want to make a= bigger, scarier warning label to put on SDES to guide people away from it,= sure, fine.=C2=A0 But it doesn=E2=80=99t seem like a blaring red warning l= ight is called for.=C2=A0 In terms of this document, the content is probabl= y mostly OK if we reframe it in that light.=C2=A0 Obsoleting SDES and marki= ng it Historic, though, is over the top; it will just create unnecessary co= nsternation. =C2=A0

I'm not r= eally following your argument here. We all agree that (1) SDES is bad (2) W= e have better alternatives in the form of DTLS-SRTP and (eventually) MLS-SR= TP. So, precisely what harm is it doing to tell people that and that they s= houldn't use SDES in favor of that. "consternation" is not a = real harm.

We agree w= ith regard to the future.

What are operators = of existing systems using SDES supposed to take away from this?=C2=A0 This = is not like say the SSLv3 deprecation where we had new data (POODLE) that c= hanged the posture of these systems.=C2=A0 Systems based on SDES are as sec= ure / insecure as they ever were.=C2=A0 So what I'm worried about is (a= ) the IETF looking alarmist for marking a bunch of things insecure that are= actually fine, and (b) to the degree the deprecation is taken seriously, c= reating a bunch of work to upgrade from SDES to a flavor of DTLS-SRTP that = is not enough better to merit the effort.

--Richar= d

=C2=A0

-Ekr


--Richard

On Tue, Jul 27, 2021 at 7:= 08 PM John Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote= :

westhawk thp@westhawk.co.uk wrote:

=C2=A0

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

=C2=A0

Yes, looking at the Jabber log = there was quite strong support for the goal of deprecating SDES:<= /u>

=C2=A0

Eric Rescorla: Let's all just agree that this = (Mattson's SDES) draft is a good idea and promote it to full standard t= oda
Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

=C2=A0

=C2=A0

Regarding the next required ste= ps I agree with Pete. Let=E2=80=99s charter.

=C2=A0

Ben Kaduk: So is this dispatch to BoF, or straight to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Chart= er.

=C2=A0

Cheers,

John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000f6d53f05c832be3e-- From nobody Wed Jul 28 11:47:43 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1FE3A1BB5 for ; Wed, 28 Jul 2021 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFi5SkCi5O6p for ; Wed, 28 Jul 2021 11:47:36 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40062.outbound.protection.outlook.com [40.107.4.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5383A1BB4 for ; Wed, 28 Jul 2021 11:47:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iuo4Hgs1ACdC4qxUEgZrBNeyUYKdLT4LMFY2mn240DbWUwIjqPIEXfqrwJv5sl2meSiEzEvIUM4ofc6THUbbo/R9vG6ASq2BehAOcvLh+omvoB6J3a3iNjc3Ghvnp0q3jvQ9dSgArgTLQA8EPyeBUhJ+uO+QduGQDsUP9M65uubhZUtjJSwNX4kBRU5jtSjwMlNBaDzZ1RX23s4dD7SswrQiVWV8yBRGILdDHrCEk+GPIP5g/cBYYqimTSw96UGLeueaLtcm+Wjk6wA616YZUidtWXaCFAsIEvUhkawr3pTTUw2fXgJcUG4vINxTF4O6Ksoswkp7ilRi4IWoG/Z7vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ElPihQm5Y1A8zcPfauOOvXjwwwiXWW6QUD4OcaeTtmY=; b=BpjKnUlMDlNNmbEBOgmJ6DgPvH6NSfqJ2xekn2sEKEtLS/U0yZKAx0FWgwnEB47EUo7Bu7TYdU5YiLWbErdleLa+fCvz2l4DOBshregjoPCHjl+BFOL+MBMcr5wry+f/UevczXdcCSIvmAkOiZZUOrUMZ0AmTJQ18ZnN08BOzuxpVXbloofSiZ+aObtknLfXeA5vxzZhOnE3nNci+7ZJKS4P1OURIIPcCemifaJLb+cWIwUsxSnk4qEeCJ0NQYIOrrCPwcJEmRe1OYm3ljkkd/WmbokDFootVYCuZiyQDreVR1iGA0E4sqF6n8XPeeBCs9Z4UoV0xht2O8CXeQ1v4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ElPihQm5Y1A8zcPfauOOvXjwwwiXWW6QUD4OcaeTtmY=; b=Wa58S0f4LXcc6vDNsjufjMR6dgd8WKUNl3GqLViXo9M2HnFpwOemhsYAosC5o0o1tmoOHf0etmyvxjoC3M0Y8jWjkxpcqqTsl17sNx61ylSYj8WW4LFUD7xlgyhoE9+uZPGzgFcaMpEbqyWrMw4ZfpvRLLsAoxnrxmiw/2H6nrs= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2091.eurprd07.prod.outlook.com (2603:10a6:3:21::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.14; Wed, 28 Jul 2021 18:47:31 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::4999:ec50:d084:341b%5]) with mapi id 15.20.4373.018; Wed, 28 Jul 2021 18:47:31 +0000 From: John Mattsson To: Richard Barnes CC: "dispatch@ietf.org" Thread-Topic: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes Thread-Index: AQHXgzpb6iflqBZmeUGEzWRA3H1WeatYpNYAgAAV80g= Date: Wed, 28 Jul 2021 18:47:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 95d4c77a-7198-47c4-3718-08d951f827c2 x-ms-traffictypediagnostic: HE1PR0701MB2091: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 71ahcBy1MXPyOtkHo2j9+jraTzMv49InzgB2MRj6onqTwuTHVdcu80YhQEIkzNMxZeIxcsv+zIf25LRK7ysAkp0DFngEdn0W9RUUGJ5261tvVNnVlnsBUhlJ6ZoRiKid95WY/A8Pd+AWpY7VdMueL0AleMXMEd0EAB1roAFxVC52eWaAi59gQVp7TB7e78JcBG8G061orWr/coQGKIlTtGxFD4+WsTAgQGUltYsb5gu0bdi4k3hqNS4aLJS+Cw8aXwabHI4s3FzEky1GN99AsHokaXGMqYALY8cyOo1f+RWy4gJKXuLXC15LBtWk8U6uOk7u/FMP2QtLtQ1WO/cgLj3NpUoA1raNCxlTpYBZTUm5xiwLmMl+oa8ac0NzcuhblSw2uwHAPLtB+Bv9NvJP44DgtUd0ZC/PK7oZIvuuGX624EejdXGWRrP+1+EUeU4Y9vSGgsuvBJmNvP0TqewIKQDvvmojxu9AH0eJ1VcMjacW8BTn7LkAlBVyqBrAqwD9jYMZZDz2r0hr39Vy1aIX686SkCxILU8DLjC/jqpA4E1ZOfO06isEwdEY2XPDhy8CoiKDCTiInaKZx+epumbpxuznSjSF89MlVqCJwAIjlxZyaVACMLMkjhA/N5kvH7oJx66iz3O7AlhdjZ5WCO5VMrmRUgMEki4k42a1FjrGT9AztB/upG/f+7wbRESbdC1uQWpVIFvOL8bSC045rC2E+g+jAYDZMQ3xfCx59RhwhH0ORZrnkOUDz4sERKkiGZXvLu40naTyMyjHi5c1IaihVLjVAdPn61nwSt6SgW3lXjE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(166002)(83380400001)(86362001)(64756008)(6916009)(8936002)(7696005)(2906002)(38070700005)(44832011)(316002)(38100700002)(508600001)(66446008)(4326008)(186003)(53546011)(9686003)(5660300002)(66946007)(66476007)(66556008)(122000001)(52536014)(33656002)(71200400001)(966005)(55016002)(76116006)(66574015)(8676002)(26005)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?YmP7GokJ7XTvS4v56w1OQboty8Xh0XKOIl5/GzyblmcCq334k87B5TGs?= =?Windows-1252?Q?NkMw1ebuunVJdQdiK5A2FQyWAI4A4C2YQxMs7xJjCVBd3hncyjVJCyv/?= =?Windows-1252?Q?WqwYZ8C5xPg2Dbohgh5ihM8OO1DqdC+7FHp/5ivsSVxGR4aJKsuRdD/Z?= =?Windows-1252?Q?kHfzaadGGy71m2bHPDd63TWzyHrLBQYyA9B46Z6GrQbgDTsrprwnHRt+?= =?Windows-1252?Q?UDZMES5HOiBvaJP2KS/DAaceO3paeStXhdGHKvUBnep7psacXXLAZgsN?= =?Windows-1252?Q?ngjESkmsDXw2yKSy5l1P9r86eR4P9aT1apbQzhSX5ba4AHccr4dwNb7n?= =?Windows-1252?Q?2n+r1ewctdrtFFjbQg4AehdYV05nhbcsnZWyyVoB9VI0GWamlXKVmuSp?= =?Windows-1252?Q?S5FDrV+FxBJzIkOpDlYrsPxWpCDnIm5hIzlIxai6Xx0kqHoEWVAZrbJP?= =?Windows-1252?Q?7MYgfWlPnMgYDQdOd0BD7kNtdhdXGwyyQIOV0+qYbXjffR7IeTbjRH5k?= =?Windows-1252?Q?EJCeKUvJIbQ8KgBRsvY7mfkToGddPU9l42Z3zvbHWid7wrhrD71eIcL/?= =?Windows-1252?Q?UVBBhAcqi/EPz/pc4QtuzOEgY/ytjl9kNL+uxqffKAGsZkWmZChH+5fd?= =?Windows-1252?Q?bGbGp4cNjKTXwBtCZdkCbwzB4vNfD/qEd7qd+Tbt4ASr0Scvfen8KcC8?= =?Windows-1252?Q?lEtyITcVqgp7cqT/oaDkhLB+Ab/tGUl7Vm2vsQscBr0wRzxr3tdZFHeA?= =?Windows-1252?Q?vtkwWn/bOVxG+h37E8/mIKFvvj7ISfVuhme2VVDC9ZxlvIlVOe7rsgFi?= =?Windows-1252?Q?/hZZWHeeRvTxOoDbRK8ECjB4MtWAjlFyojLPn+OZK616zwZgze1qTixX?= =?Windows-1252?Q?A06t0VCwzsR5g04E4WVfS+CtFkPdR+T+ps7z8Q1wGuhowBXYp67uGCYj?= =?Windows-1252?Q?R7Ck1gaiBiE0uw4EH3VFS1xcqsFlXyrY3nvGhHrdpjxQgE0SFHXY1Tj6?= =?Windows-1252?Q?DJq6R2qkwLhFmBF7ElZaCiMflZAONFhZExfGOawqui7sIvsmuDT6Z9mh?= =?Windows-1252?Q?sAJfZYbyijheMC2PpCwG79PNNgOn+4W9FH2k6OE8UN5TGEfzzW3dynbA?= =?Windows-1252?Q?KMmWHQBbv4duWWZ3VJKHKk9OcC8PsSdPVoYxOmJIlkCYQQJ1rDZe5QCD?= =?Windows-1252?Q?MS2VUPZOJgs19DD5kh8qmnFB3F9zcGjgVv/RQ7fet4tCStnzDrpN/vkx?= =?Windows-1252?Q?2DFRSF0wSAduzXntRmd9sCfWCbM/BFbWWlmOOO6ALQDVz3IPvHvICnyk?= =?Windows-1252?Q?4Z0rGJVN6vsS6eC0GlHacMgpmTBpoLk6bqZ2hxl6k/IfsFUxuvR4v/1r?= =?Windows-1252?Q?pn6HmXiACFSZxoYdJRwx4xPqSB2lzoxYv7UhDPMbgtUENVWjdNePmwsj?= =?Windows-1252?Q?GWOXkGfiRRlBLEApuryoag=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050C7A46B70BF76CE2F811789EA9HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95d4c77a-7198-47c4-3718-08d951f827c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 18:47:30.9105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ClfCyDrXK9r4exyng/3xYbHcwKXeAPTqprsYYiJW7RsSBwtDBE2zbX8W7UJSS0LaPfDoZekYlIr2+ggc3InkzHqHl5gQYyTyGArJXFhUT9Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2091 Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 18:47:42 -0000 --_000_HE1PR0701MB3050C7A46B70BF76CE2F811789EA9HE1PR0701MB3050_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richard Barnes wrote: > I hate sending symmetric keys around as much as the next person. But we = should be pragmatic here. I think the NOT RECOMMENDED suggestion on the table is quite pragmatic. The= suggestions here are much softer than the RFC 8996: "MUST NOT negotiate TL= S 1.1". > Here, SDES still does what it says on the label I don't think that is true. SDES is labeled as an IETF proposed standard. I= t might barely have met the requirements for that when it was published, bu= t it certainly does not anymore. While SDES is as insecure as it always has= been, the distance between SDES and what is considered acceptable security= has grown big. -John From: Richard Barnes Date: Wednesday, 28 July 2021 at 19:26 To: John Mattsson Cc: dispatch@ietf.org Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes an= d draft minutes I hate sending symmetric keys around as much as the next person. But we sh= ould be pragmatic here. The situation with SDES is unlike the situation with a bunch of the other d= eprecations we have done recently (SSLv3, TLS 1.0). There, the protocol wa= s broken, in the sense that it does not provide the guarantees that it is s= upposed to provide. Here, SDES still does what it says on the label, just = like it always has; we=92re just increasingly grumpy about that model and t= here are somewhat better alternatives. Note =93somewhat=94 =97 DTLS-SRTP is only better than SDES to the extent th= at the certificates in the DTLS exchange are verified independent of the si= gnaling path. If you rely only on the fingerprint in SDP for authenticatio= n, then an SDP-path entity can swap out fingerprints to intercept get keys = just as well as with SDES. (At best, this swaps an active for a passive at= tack, which is not nothing, but not a huge step.) We do have mechanisms fo= r such verification, but they=92re not widely deployed. All of which tells me that there's not an urgent need for action here. SDE= S is not a looming threat to the Internet. In the many deployments where i= t is used, it still does what it claims to do, and people have accommodated= that into their broader system models. Even if there were to be a mass mi= gration to DTLS-SRTP, the actual security benefit for all that work would b= e fairly minor until we do a lot more work to solve the authentication prob= lems. So if folks want to make a bigger, scarier warning label to put on SDES to = guide people away from it, sure, fine. But it doesn=92t seem like a blarin= g red warning light is called for. In terms of this document, the content = is probably mostly OK if we reframe it in that light. Obsoleting SDES and = marking it Historic, though, is over the top; it will just create unnecessa= ry consternation. --Richard On Tue, Jul 27, 2021 at 7:08 PM John Mattsson > wrote: westhawk thp@westhawk.co.uk wrote: >> On 26 Jul 2021, at 23:30, Kirsty P >wrote: >> >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was= >sub-optimal. There was support for revisiting the space currently standar= dised >by SDP, but not on direction (whether to do a deprecation with/witho= ut >replacement). Future paths suggested included: mmusic, a new WG, more w= ork >required for it to be ready, or a BoF (said in chat) to vet the idea f= urther. >My sense is that there was a rough consensus around a goal to make it poss= ible >to deprecate SDES - but the required steps were unclear. Yes, looking at the Jabber log there was quite strong support for the goal = of deprecating SDES: Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a g= ood idea and promote it to full standard toda Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before? Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;) Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? Sean Turner: +1 to what ekr said Rich Salz: +1 also Regarding the next required steps I agree with Pete. Let=92s charter. Ben Kaduk: So is this dispatch to BoF, or straight to WG? Pete Resnick: @ben: Sounds like this discussion has done the equivalent of = BoFing. Charter. Cheers, John _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_HE1PR0701MB3050C7A46B70BF76CE2F811789EA9HE1PR0701MB3050_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Richard Barnes <rlb@ipv.sx&g= t; wrote:=

 

> I hate sending symmetric k= eys around as much as the next person.  But we should be pragmatic her= e.

 

I think the NOT RECOMMENDED sug= gestion on the table is quite pragmatic. The suggestions here are much soft= er than the RFC 8996: "MUST NOT negotiate TLS 1.1".

 

 

> Here, SDES still does what= it says on the label

 

I don't think that is true. SDE= S is labeled as an IETF proposed standard. It might barely have met the req= uirements for that when it was published, but it certainly does not anymore= . While SDES is as insecure as it always has been, the distance between SDES and what is considered acceptable secu= rity has grown big.

 

-John

 

From: Richard Barnes <rlb@ipv.sx>
Date: Wednesday, 28 July 2021 at 19:26
To: John Mattsson <john.mattsson@ericsson.com>
Cc: dispatch@ietf.org <dispatch@ietf.org>
Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outc= omes and draft minutes

I hate sending symmetri= c keys around as much as the next person.  But we should be pragmatic = here.

The situation with SDES is unlike the situation with a bunch of the other d= eprecations we have done recently (SSLv3, TLS 1.0).  There, the protoc= ol was broken, in the sense that it does not provide the guarantees that it= is supposed to provide.  Here, SDES still does what it says on the label, just like it always has; we=92re jus= t increasingly grumpy about that model and there are somewhat better altern= atives.

Note =93somewhat=94 =97 DTLS-SRTP is only better than SDES to the extent th= at the certificates in the DTLS exchange are verified independent of the si= gnaling path.  If you rely only on the fingerprint in SDP for authenti= cation, then an SDP-path entity can swap out fingerprints to intercept get keys just as well as with SDES.  (At be= st, this swaps an active for a passive attack, which is not nothing, but no= t a huge step.)  We do have mechanisms for such verification, but they= =92re not widely deployed.

All of which tells me that there's not an urgent need for action here. = ; SDES is not a looming threat to the Internet.  In the many deploymen= ts where it is used, it still does what it claims to do, and people have ac= commodated that into their broader system models.  Even if there were to be a mass migration to DTLS-SRTP, the = actual security benefit for all that work would be fairly minor until we do= a lot more work to solve the authentication problems.

So if folks want to make a bigger, scarier warning label to put on SDES to = guide people away from it, sure, fine.  But it doesn=92t seem like a b= laring red warning light is called for.  In terms of this document, th= e content is probably mostly OK if we reframe it in that light.  Obsoleting SDES and marking it Historic, though, i= s over the top; it will just create unnecessary consternation.  

--Richard

 

On Tue, Jul 27, 2021 at= 7:08 PM John Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:

westhawk thp@westha= wk.co.uk wrote:

 

>> On 2=
6 Jul 2021, at 23:30, Kirsty P <Kirsty.p=3D40ncsc.gov.=
uk@dmarc.ietf.org> >wrote:
>> 

>> SDP =
Security Descriptions is NOT RECOMMENDED and Historic: consensus was >sub-optimal. There was support for revisiting the=
 space currently standardised >by SDP, but n=
ot on direction (whether to do a deprecation with/without >replacement). Future paths suggested included: mmusic, a new=
 WG, more work >required for it to be ready,=
 or a BoF (said in chat) to vet the idea further.


>My sense =
is that there was a rough consensus around a goal to make it possible >to deprecate SDES - but the required steps were =
unclear.



 



Yes, looking at the Jabber log there was quite strong =
support for the goal of deprecating SDES:



 




 



 



Regarding the next required steps I agree with Pete. L=
et=92s charter.



 



Ben Kaduk:
So is this dispatch to BoF, or straight to WG?



: @ben: Sounds like this
 discussion has done the equivalent of BoFing. Charter.



 



Cheers,



John

_______________________= ________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_HE1PR0701MB3050C7A46B70BF76CE2F811789EA9HE1PR0701MB3050_-- From nobody Wed Jul 28 12:04:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607BF3A1C17 for ; Wed, 28 Jul 2021 12:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE7NyEhYARbu for ; Wed, 28 Jul 2021 12:04:51 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076E03A1C1C for ; Wed, 28 Jul 2021 12:03:57 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id h18so3445914ilc.5 for ; Wed, 28 Jul 2021 12:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qxD1yVVmLL9kWDtBKCuB1d8SKECB0tdVykLomoML9+g=; b=DJkkzixkoSgBGlv6vwSlw2zwmfm+lQER1nkwJUM4Hm+2LYcgmIPEe1Va/0cSmVYgx8 ny5hv2JfgG5MPl9vWVd9I1uAGNniPpLWdV2oDatVYll2Q7T6/JMS4FrR7Ed2Bmaqbs3a +14FXZt6sW9AqmtKWW209O4o2o2n/kyZCOVsp+F2EnrTQd8GHVnnhMULN1mpLuhJey4q d3J7mxJjGfyrNmIuij5P+weDN13MNFXy2qEZfcDVYzuYLWasW+1fYextjDdwKmzqzw+F eZcNGvEs7kQ7ZH3AS3Xu3H0BjU369ucusHKf0rvaJs7D1Jxilzxp8bixlPr/nALMXkBj +xtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qxD1yVVmLL9kWDtBKCuB1d8SKECB0tdVykLomoML9+g=; b=mrqrqHxVQEiMbXFhRlyxGff+XnJsERoz+Akwl06bQ8RcIEiV54Bl7IfoxsRRheFqtj 25z/ZE4x1fyw/1YppibhGF+bSmNMn9tNdVnRukQWF5pFFMouzE916pGporPRW3QNKM03 HgNzL3CDYcXbdRV//gPKMLSwSxmt5YJaLxsuC1/VZqNqEkGHbafHkfQt1PpH5ZLbNJTV O7ADkF/tcnPFNuPSLAS4///jUTX5arem/LdkZeJnGEvmgLcOotuZc33yba/qf7WAdCQy MkbNbvpa5B4EebG++WAp1SRLEgkaQ5bAiQjHnsUjHpQokkhBM07mCCqvoVdtVWI81G5a e9hg== X-Gm-Message-State: AOAM530yKBs5RdMYsRiGiGShI1eJYrA0ZI2l1s85wdWlkDNuv88qcst/ OOQ8c3zrhkZFGKysxK9rtyZWgzu7A2+l7nc2JZDWdzDTzNV3mA== X-Google-Smtp-Source: ABdhPJx+pC1Y7Hwt6Ttb188tMh2iqIjJUbRfRRfFGGv4oaeSnk6hWTUkYfyOwL13XFMydmohv6+1puv+L+mURxtPmXg= X-Received: by 2002:a05:6e02:13d3:: with SMTP id v19mr855429ilj.167.1627499035371; Wed, 28 Jul 2021 12:03:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 28 Jul 2021 12:03:19 -0700 Message-ID: To: Richard Barnes Cc: John Mattsson , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e04c2705c833a5fc" Archived-At: Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 19:04:57 -0000 --000000000000e04c2705c833a5fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 28, 2021 at 10:59 AM Richard Barnes wrote: > On Wed, Jul 28, 2021 at 1:32 PM Eric Rescorla wrote: > >> >> >>> So if folks want to make a bigger, scarier warning label to put on SDES >>> to guide people away from it, sure, fine. But it doesn=E2=80=99t seem = like a >>> blaring red warning light is called for. In terms of this document, th= e >>> content is probably mostly OK if we reframe it in that light. Obsoleti= ng >>> SDES and marking it Historic, though, is over the top; it will just cre= ate >>> unnecessary consternation. >>> >> >> I'm not really following your argument here. We all agree that (1) SDES >> is bad (2) We have better alternatives in the form of DTLS-SRTP and >> (eventually) MLS-SRTP. So, precisely what harm is it doing to tell peopl= e >> that and that they shouldn't use SDES in favor of that. "consternation" = is >> not a real harm. >> > > We agree with regard to the future. > > What are operators of existing systems using SDES supposed to take away > from this? This is not like say the SSLv3 deprecation where we had new > data (POODLE) that changed the posture of these systems. Systems based o= n > SDES are as secure / insecure as they ever were. > What's changed is (1) a clearer appreciation of the threat model and (2) more widespread availability of better technologies. So what I'm worried about is (a) the IETF looking alarmist for marking a > bunch of things insecure that are actually fine, > The point, as John has ably documented, is that they're not fine. and (b) to the degree the deprecation is taken seriously, creating a bunch > of work to upgrade from SDES to a flavor of DTLS-SRTP that is not enough > better to merit the effort. > It seems to me that replacing SDES with DTLS-SRTP (or, I guess, MLS-SRTP) is precisely the intended outcome here. -Ekr > > --Richard > > > >> >> -Ekr >> >> >>> --Richard >>> >>> On Tue, Jul 27, 2021 at 7:08 PM John Mattsson >> 40ericsson.com@dmarc.ietf.org> wrote: >>> >>>> westhawk thp@westhawk.co.uk wrote: >>>> >>>> >>>> >>>> >> On 26 Jul 2021, at 23:30, Kirsty P <<Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org>> >wrote: >>>> >>>> >> >>>> >>>> >> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensu= s was >sub-optimal. There was support for revisiting the space currently st= andardised >by SDP, but not on direction (whether to do a deprecation with/= without >replacement). Future paths suggested included: mmusic, a new WG, m= ore work >required for it to be ready, or a BoF (said in chat) to vet the i= dea further. >>>> >>>> >My sense is that there was a rough consensus around a goal to make it= possible >to deprecate SDES - but the required steps were unclear. >>>> >>>> >>>> >>>> Yes, looking at the Jabber log there was quite strong support for the >>>> goal of deprecating SDES: >>>> >>>> >>>> >>>> Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft i= s >>>> a good idea and promote it to full standard toda >>>> Martin Thomson: now that I see John presenting this, I have to wonder: >>>> why didn't this deprecation happen before? >>>> Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - >>>> I assumed that was that ;) >>>> Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"? >>>> Sean Turner: +1 to what ekr said >>>> Rich Salz: +1 also >>>> >>>> >>>> >>>> >>>> >>>> Regarding the next required steps I agree with Pete. Let=E2=80=99s cha= rter. >>>> >>>> >>>> >>>> Ben Kaduk: So is this dispatch to BoF, or straight to WG? >>>> >>>> Pete Resnick: @ben: Sounds like this discussion has done the >>>> equivalent of BoFing. Charter. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> John >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> --000000000000e04c2705c833a5fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 28, 2021 at 10:59 AM Rich= ard Barnes <rlb@ipv.sx> wrote:


So if folk= s want to make a bigger, scarier warning label to put on SDES to guide peop= le away from it, sure, fine.=C2=A0 But it doesn=E2=80=99t seem like a blari= ng red warning light is called for.=C2=A0 In terms of this document, the co= ntent is probably mostly OK if we reframe it in that light.=C2=A0 Obsoletin= g SDES and marking it Historic, though, is over the top; it will just creat= e unnecessary consternation. =C2=A0

I'm not really following your argument here. We all agree that (1) S= DES is bad (2) We have better alternatives in the form of DTLS-SRTP and (ev= entually) MLS-SRTP. So, precisely what harm is it doing to tell people that= and that they shouldn't use SDES in favor of that. "consternation= " is not a real harm.

We agree with regard to the future.

Wha= t are operators of existing systems using SDES supposed to take away from t= his?=C2=A0 This is not like say the SSLv3 deprecation where we had new data= (POODLE) that changed the posture of these systems.=C2=A0 Systems based on= SDES are as secure / insecure as they ever were.=C2=A0
<= /blockquote>

What's changed is (1) a clearer appreci= ation of the threat model and (2) more widespread availability of better te= chnologies.


So w= hat I'm worried about is (a) the IETF looking alarmist for marking a bu= nch of things insecure that are actually fine,

The point, as John has ably documented, is that they= 're not fine.


and (b) to the degree the deprecation is taken seriously, creating a bunc= h of work to upgrade from SDES to a flavor of DTLS-SRTP that is not enough = better to merit the effort.

It seems to me that replacing SDES with DTLS-SRTP (or, I guess, MLS-SRTP= ) is precisely the intended outcome here.

-Ekr=


=C2=A0

--Richard

=C2=A0

-Ekr


--Richard<= /div>
O= n Tue, Jul 27, 2021 at 7:08 PM John Mattsson <john.mattsson=3D40ericsson.com@dma= rc.ietf.org> wrote:

westhawk thp@westhawk.co.uk wrote:

=C2=A0

>> On 26 Jul 2021, at 23:30, Kirsty =
P <Kirsty.p=3D40ncsc.gov.uk@dmarc.ietf.org> >wrote:
>> 
>> SDP Security Descriptions is NOT =
RECOMMENDED and Historic: consensus was >sub=
-optimal. There was support for revisiting the space currently standardised=
 >by SDP, but not on direction (whether to d=
o a deprecation with/without >replacement). =
Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to v=
et the idea further.
>My sense is that there was a rough con=
sensus around a goal to make it possible >to=
 deprecate SDES - but the required steps were unclear.

=C2=A0

Yes, looking at the Jabber log = there was quite strong support for the goal of deprecating SDES:<= /u>

=C2=A0

Eric Rescorla: Let's all just agree that this = (Mattson's SDES) draft is a good idea and promote it to full standard t= oda
Martin Thomson: now that I see John presenting this, I have to wonder: why = didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I as= sumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT&quo= t;?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

=C2=A0

=C2=A0

Regarding the next required ste= ps I agree with Pete. Let=E2=80=99s charter.

=C2=A0

Ben Kaduk: So is this dispatch to BoF, or straight to WG?

Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Chart= er.

=C2=A0

Cheers,

John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000e04c2705c833a5fc--