From nobody Tue Apr 4 02:51:51 2017 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 A50E71295E7 for ; Tue, 4 Apr 2017 02:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 x6x_jAzgnoEp for ; Tue, 4 Apr 2017 02:51:39 -0700 (PDT) Received: from mail3.informatica.it (mail3.informatica.it [151.99.189.163]) by ietfa.amsl.com (Postfix) with ESMTP id C781C129517 for ; Tue, 4 Apr 2017 02:51:38 -0700 (PDT) To: dispatch@ietf.org References: From: Federico Santandrea Message-ID: Date: Tue, 4 Apr 2017 11:51:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-GatewayId: federico.santandrea=2.522837320016076132561703@diennea.com Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:51:43 -0000 I'd suggest: "bugs in DNS provisioning software" -> "limits in some DNS provisioning software". On 30/03/2017 21:37, John R Levine wrote: > 1024 bit signatures are common, longer signatures are not because bugs in > DNS provisioning software prevent publishing longer keys as DNS TXT > records. -- Federico From nobody Tue Apr 4 09:19:47 2017 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 5209F128DE5 for ; Tue, 4 Apr 2017 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H6LYE1pMDueb for ; Tue, 4 Apr 2017 09:19:43 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03241200C1 for ; Tue, 4 Apr 2017 09:19:43 -0700 (PDT) Received: (qmail 59804 invoked from network); 4 Apr 2017 16:19:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Apr 2017 16:19:39 -0000 Date: 4 Apr 2017 16:19:17 -0000 Message-ID: <20170404161917.37759.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org Cc: federico.santandrea@diennea.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:19:45 -0000 In article you write: >I'd suggest: > >"bugs in DNS provisioning software" -> > "limits in some DNS provisioning software". I'd say that if provisioning software claims to handle TXT records but only handles a single string, that's a bug. I realize it's a bug that is not likely to get fixed any time soon, but bugs can be like that. R's, John From nobody Wed Apr 5 10:51:51 2017 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 4443D126C7A; Wed, 5 Apr 2017 10:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 l5fIjc0cbbVL; Wed, 5 Apr 2017 10:51:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 BD93D129489; Wed, 5 Apr 2017 10:51:34 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-e2-58e52ea4057b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id F1.7B.26215.4AE25E85; Wed, 5 Apr 2017 19:51:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.158]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Wed, 5 Apr 2017 19:50:45 +0200 From: Christer Holmberg To: "dispatch@ietf.org" CC: "dispatch-chairs@ietf.org" Thread-Topic: IETF#98: DISPATCH notes (Christer) Thread-Index: AdKuPYjm0P2dXnbzRgGLm88hRt1wOA== Date: Wed, 5 Apr 2017 17:50:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB4C512@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB4C512ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7t+4SvacRBo07NSz2vn7KYrF00gJW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlLJ83naVgz0nGit9tLcwNjBPWM3YxcnJICJhITJnQ BGRzcQgJrGeU2Nb6hg0kISSwmFHi5XbpLkYODjYBC4nuf9ogYREBbYmjq7qYQWxmAUuJf8tP gJULA8VnrrzPBlFjIPFnz24WCFtP4s7iLWBxFgEVieuT9rKD2LwCvhJz+5+A2YwCYhLfT61h gpgpLnHryXwmiNsEJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0R9vsTq86/ZIGYKSpyc+YRlAqPQ LCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLU7KTTcy0kstykwu Ls7P08tLLdnECIyPg1t+G+xgfPnc8RCjAAejEg9vwo8nEUKsiWXFlbmHGCU4mJVEePepPo0Q 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1OqgXHSAztV6SUn Fux8a89dIZRiwubIWVO+5I6Roc6jDPP2ghkJCaKeha9PNeZsrpsgufu7yT+b5Qd4hG4sPiD2 76l1nu3OuTNrn208pPpJSpw92uzBp7b6C1uVMpbdPrhN/NwchpaAhTMXu3JFWiUWsf264a+9 WpiL8eXTgvSql55XOI+JvAiTs1diKc5INNRiLipOBABoezFviwIAAA== Archived-At: Subject: [dispatch] IETF#98: DISPATCH notes (Christer) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:51:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB4C512ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the DISPATCH session. Regards, Christer ------------------------- Topic: Path MTU Discovery (PMTUD) for RTP/RTCP Presenter: Marc Petit-Huguenin Draft: draft-petithuguenin-dispatch-rtp-pmtud-00 What is it? - Defines the usage of the for RTP/RTCP path discovery using the P= MTUD protocol. Presentation in a nutshell? - The following questions/issues were presented: - How to uniquely identify RTP/RTCP packets? - How to signal support/usage of the mechanism in SDP? - What are the ICE impacts? What did people say? - Most of the discussion was about why ICE can't be used instead. Ok, so what next? - Figure out how to do this on the ICE layer rather than on the RT= P layer. Then, IF there are use-cases where RTP would be more feasible they= can be looked at. However, currently no such use-cases have been identifie= d. Topic: Web Linking Presenter: Mark Nottingham Draft: draft-nottingham-rfc5988bis-04 What is it? - A way to indicate the relationships between resources on the Web= and the type of those relationships. Presentation in a nutshell? - The presenter indicated that there are currently no open issues = in the draft, but that some minor stuff still has to be done, related to re= ferences, terminology, incorporation of errata, ABNF, etc... What did people say? - Most of the discussion was of administrative nature. Is a bis ne= eded, and/or shall the registry be updated (not covered in the current draf= t). - It was indicated that a registry change would require a BoF, as = it is outside the current scope of the ART area. - It was discussed whether the specification would be progressed a= s AD sponsored, or whether a new WG would be needed. People didn't seem to = think a new WG would be necessary. Ok, so what next? - Discussions regarding where the work would take place will take = place on the DISPATCH list. Topic: Location Parameter for the SIP Reason Header Field Presenter: Roland Jesske Draft: draft-jesske-dispatch-reason-loc-q850-00.txt What is it? - Adds a location value parameter to the Reason header field reaso= n-extension parameter, so that the location value can be interworked from t= he PSTN. Presentation in a nutshell? - The use-case where the new information would be needed was prese= nted. What did people say? - There was a question whether the Reason header field in an non-2= 00 SIP response would traverse proxies. Indicated that Reason header fields= do tend to traverse proxies. - It was indicated that the work would fit the SIPCORE WG charter. Ok, so what next? - The draft will be dispatched to the SIPCORE WG. SIPCORE will the= n decide whether to adopt the draft. Topic: Cryptographic Update to DKIM Presenter: John Levine Draft: draft-levine-dcrup-dkim-crypto-00 What is it? - Adds a new DKIM algorithm (ECHD), which has a shorter key size t= han RSA for similar level of security. - Adds the possibility to store the key hash, rather than the key,= in DNS, and include the key in the signature. Presentation in a nutshell? - Deployed DNS configuration software places a limit on key sizes,= because the software only handles a single 256 octet string in a single TX= T record, and RSA keys longer than 1024 bits don't fit in 256 octets. - Two alternatives were presented: - 1. Define usage of a new algorithm, with smaller keys. - 2. Put a fixed size key hash (instead of the key itself) in the DNS,= and put the associated public key in the signature. What did people say? - There was a preference for placing the key hash in the DNS. Then= , if people in addition also want to update the algorithm, that can be done= too. - It was indicated that there are IPR(s) associated with publishin= g a key hash in DNS. - It was discussed where the work would be done. The CURDLE WG was= suggested. It was indicated that the CURDLE WG is very narrowly scoped, an= d that a new WG would be preferred. Ok, so what next? - A short proposed charter for a mini WG will be written, sent on = the list, and the ADs will decided what can be done and where. --_000_7594FB04B1934943A5C02806D1A2204B4CB4C512ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my notes from the DISPATCH session.

 

Regards,

 

Christer

 

-------------------------

 

Topic:       &= nbsp;          Path MTU Discov= ery (PMTUD) for RTP/RTCP

Presenter:      &nb= sp;   Marc Petit-Huguenin

Draft:       &= nbsp;          draft-petithugu= enin-dispatch-rtp-pmtud-00

 

What is it?

 

-     &= nbsp;    Defines the usage of the for RTP/RTCP path discover= y using the PMTUD protocol.

 

Presentation in a nutshell?

 

-     &= nbsp;    The following questions/issues were presented:=

 

-     &= nbsp;    How to uniquely identify RTP/RTCP packets?

-     &= nbsp;    How to signal support/usage of the mechanism in SDP= ?

-     &= nbsp;    What are the ICE impacts?

 

What did people say?

 

-     &= nbsp;    Most of the discussion was about why ICE can't be u= sed instead.

 

Ok, so what next?

 

-     &= nbsp;    Figure out how to do this on the ICE layer rather t= han on the RTP layer. Then, IF there are use-cases where RTP would be more = feasible they can be looked at. However, currently no such use-cases have b= een identified.

 

 

Topic:       &= nbsp;          Web Linking

Presenter:      &nb= sp;   Mark Nottingham

Draft:       &= nbsp;          draft-nottingha= m-rfc5988bis-04

 

What is it?

 

-     &= nbsp;    A way to indicate the relationships between resourc= es on the Web and the type of those relationships.

 

Presentation in a nutshell?

 

-     &= nbsp;    The presenter indicated that there are currently no= open issues in the draft, but that some minor stuff still has to be done, = related to references, terminology, incorporation of errata, ABNF, etc...

 

What did people say?

 

-     &= nbsp;    Most of the discussion was of administrative nature= . Is a bis needed, and/or shall the registry be updated (not covered in the= current draft).

-     &= nbsp;    It was indicated that a registry change would requi= re a BoF, as it is outside the current scope of the ART area.

-     &= nbsp;    It was discussed whether the specification would be= progressed as AD sponsored, or whether a new WG would be needed. People di= dn't seem to think a new WG would be necessary.

 

Ok, so what next?

 

-     &= nbsp;    Discussions regarding where the work would take pla= ce will take place on the DISPATCH list.

 

 

Topic:       &= nbsp;          Location Parame= ter for the SIP Reason Header Field

Presenter:      &nb= sp;   Roland Jesske

Draft:       &= nbsp;          draft-jesske-di= spatch-reason-loc-q850-00.txt

 

What is it?

 

-     &= nbsp;    Adds a location value parameter to the Reason heade= r field reason-extension parameter, so that the location value can be inter= worked from the PSTN.

 

Presentation in a nutshell?

 

-     &= nbsp;    The use-case where the new information would be nee= ded was presented.

 

What did people say?

 

-     &= nbsp;    There was a question whether the Reason header fiel= d in an non-200 SIP response would traverse proxies. Indicated that Reason = header fields do tend to traverse proxies.

-     &= nbsp;    It was indicated that the work would fit the SIPCOR= E WG charter.

 

Ok, so what next?

 

-     &= nbsp;    The draft will be dispatched to the SIPCORE WG. SIP= CORE will then decide whether to adopt the draft.

 

 

Topic:        =           Cryptographic Update= to DKIM

Presenter:       &n= bsp;  John Levine

Draft:       &= nbsp;          draft-levine-dc= rup-dkim-crypto-00

 

What is it?

 

-     &= nbsp;    Adds a new DKIM algorithm (ECHD), which has a short= er key size than RSA for similar level of security.

-     &= nbsp;    Adds the possibility to store the key hash, rather = than the key, in DNS, and include the key in the signature.

 

Presentation in a nutshell?

 

-     &= nbsp;    Deployed DNS configuration software places a limit = on key sizes, because the software only handles a single 256 octet string i= n a single TXT record, and RSA keys longer than 1024 bits don't fit in 256 = octets.

 

-     &= nbsp;    Two alternatives were presented:

-   &nbs= p;  1. Define usage of a new algorithm, with smaller keys.<= /p>

-   &nbs= p;  2. Put a fixed size key hash (instead of the key itself) in the DN= S, and put the associated public key in the signature.

 

What did people say?

 

-     &= nbsp;    There was a preference for placing the key hash in = the DNS. Then, if people in addition also want to update the algorithm, tha= t can be done too.

-     &= nbsp;    It was indicated that there are IPR(s) associated w= ith publishing a key hash in DNS.

-     &= nbsp;    It was discussed where the work would be done. The = CURDLE WG was suggested. It was indicated that the CURDLE WG is very narrow= ly scoped, and that a new WG would be preferred.

 

Ok, so what next?

 

-     &= nbsp;    A short proposed charter for a mini WG will be writ= ten, sent on the list, and the ADs will decided what can be done and where.=

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4CB4C512ESESSMB109erics_-- From nobody Wed Apr 5 16:29:02 2017 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 3B395126D85; Wed, 5 Apr 2017 16:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 JfBMUk1DktUM; Wed, 5 Apr 2017 16:28:57 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 86CBE126E01; Wed, 5 Apr 2017 16:28:56 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id r45so23945807qte.3; Wed, 05 Apr 2017 16:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fTsRhITOB2NTprRXUa6IHN6q6FgqFY99nTaEAqRi0HM=; b=WElBQHovhkwyV8M0wPR3X6ESMWSphiwpWCglI9y6fX0eYG59UQHUEHU22JnxC6FVkM +HhdE+9CYedvOEx4xUjWS1ALKly6bzyN2ZAdJGFpYVteMldloC2bPM4UXwRkUpY861R/ ck0Tb7MeBBzxH/BHvoQvYqYEgm5RbD9c6S1x5QOsNIZqSxM1xatjF7AKLYFQse65OfHO ehWMn/x4p+SFww4lCngmLKTj/X/LuJH9AUgg0h6re357XbGH87tFL2ftSb4g811rgYvy 4phgIP3wAVzU3A+D7fNxSfqlykTLlX7jVxT4h48DhhOVjcRszq8c/16EGu9T2LmYVaEi oX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fTsRhITOB2NTprRXUa6IHN6q6FgqFY99nTaEAqRi0HM=; b=NIAKU8cgAsh5Jy4DbDX6OWLyMEH9b7n6Sj9fAyLGgCDyVYOcExiFsX5SVS//WWDQTb zdNh1NqSrV3qCTYlt+XYmBQb92NpWCWIjCfkIH4HLaqnp2CMCIt/I/78Hj3AgSiVBf2i AgJsfcZdVokcM+CAjKFHsPerYPjRU4Xea8Zt6i52eWgj/73cOuO4KI44je3hPTR9SMZd BCj99oBTzs5y9bkkWxirhVSNaTTQmUgkxB53LvskkeU8BiHqqtst+tOTZAkLtWwGum17 D3yYDHEE7gnqX4J/xulmQZxKSQztzBgLER3ThvWlQoRsw06qsMFOJHpb1OjGV8stWtkR PePg== X-Gm-Message-State: AFeK/H3/QsFvLE+nArLgBPyv4Q0/OeSAE6NMPe1U8SrLqxcz8niRNjbU6DzcoLKPXpAF2bIh4JH9PAhvOo4MTQ== X-Received: by 10.237.48.37 with SMTP id 34mr31174200qte.117.1491434935587; Wed, 05 Apr 2017 16:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.101 with HTTP; Wed, 5 Apr 2017 16:28:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB4C512@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB4C512@ESESSMB109.ericsson.se> From: Mary Barnes Date: Wed, 5 Apr 2017 18:28:54 -0500 Message-ID: To: Christer Holmberg Cc: "dispatch@ietf.org" , "dispatch-chairs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0c9bbe8a9a2e054c73c132 Archived-At: Subject: Re: [dispatch] IETF#98: DISPATCH notes (Christer) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 23:29:00 -0000 --94eb2c0c9bbe8a9a2e054c73c132 Content-Type: text/plain; charset=UTF-8 Thanks! On Wed, Apr 5, 2017 at 12:50 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Below are my notes from the DISPATCH session. > > > > Regards, > > > > Christer > > > > ------------------------- > > > > *Topic: Path MTU Discovery (PMTUD) for RTP/RTCP* > > *Presenter: Marc Petit-Huguenin* > > *Draft: draft-petithuguenin-dispatch-rtp-pmtud-00* > > > > What is it? > > > > - Defines the usage of the for RTP/RTCP path discovery using the > PMTUD protocol. > > > > Presentation in a nutshell? > > > > - The following questions/issues were presented: > > > > - How to uniquely identify RTP/RTCP packets? > > - How to signal support/usage of the mechanism in SDP? > > - What are the ICE impacts? > > > > What did people say? > > > > - Most of the discussion was about why ICE can't be used instead. > > > > Ok, so what next? > > > > - Figure out how to do this on the ICE layer rather than on the > RTP layer. Then, IF there are use-cases where RTP would be more feasible > they can be looked at. However, currently no such use-cases have been > identified. > > > > > > *Topic: Web Linking* > > *Presenter: Mark Nottingham* > > *Draft: draft-nottingham-rfc5988bis-04* > > > > What is it? > > > > - A way to indicate the relationships between resources on the > Web and the type of those relationships. > > > > Presentation in a nutshell? > > > > - The presenter indicated that there are currently no open > issues in the draft, but that some minor stuff still has to be done, > related to references, terminology, incorporation of errata, ABNF, etc... > > > > What did people say? > > > > - Most of the discussion was of administrative nature. Is a bis > needed, and/or shall the registry be updated (not covered in the current > draft). > > - It was indicated that a registry change would require a BoF, > as it is outside the current scope of the ART area. > > - It was discussed whether the specification would be progressed > as AD sponsored, or whether a new WG would be needed. People didn't seem to > think a new WG would be necessary. > > > > Ok, so what next? > > > > - Discussions regarding where the work would take place will > take place on the DISPATCH list. > > > > > > *Topic: Location Parameter for the SIP Reason Header > Field* > > *Presenter: Roland Jesske* > > *Draft: draft-jesske-dispatch-reason-loc-q850-00.txt* > > > > What is it? > > > > - Adds a location value parameter to the Reason header field > reason-extension parameter, so that the location value can be interworked > from the PSTN. > > > > Presentation in a nutshell? > > > > - The use-case where the new information would be needed was > presented. > > > > What did people say? > > > > - There was a question whether the Reason header field in an > non-200 SIP response would traverse proxies. Indicated that Reason header > fields do tend to traverse proxies. > > - It was indicated that the work would fit the SIPCORE WG > charter. > > > > Ok, so what next? > > > > - The draft will be dispatched to the SIPCORE WG. SIPCORE will > then decide whether to adopt the draft. > > > > > > *Topic: Cryptographic Update to DKIM* > > *Presenter: John Levine* > > *Draft: draft-levine-dcrup-dkim-crypto-00* > > > > What is it? > > > > - Adds a new DKIM algorithm (ECHD), which has a shorter key size > than RSA for similar level of security. > > - Adds the possibility to store the key hash, rather than the > key, in DNS, and include the key in the signature. > > > > Presentation in a nutshell? > > > > - Deployed DNS configuration software places a limit on key > sizes, because the software only handles a single 256 octet string in a > single TXT record, and RSA keys longer than 1024 bits don't fit in 256 > octets. > > > > - Two alternatives were presented: > > - 1. Define usage of a new algorithm, with smaller keys. > > - 2. Put a fixed size key hash (instead of the key itself) in the > DNS, and put the associated public key in the signature. > > > > What did people say? > > > > - There was a preference for placing the key hash in the DNS. > Then, if people in addition also want to update the algorithm, that can be > done too. > > - It was indicated that there are IPR(s) associated with > publishing a key hash in DNS. > > - It was discussed where the work would be done. The CURDLE WG > was suggested. It was indicated that the CURDLE WG is very narrowly scoped, > and that a new WG would be preferred. > > > > Ok, so what next? > > > > - A short proposed charter for a mini WG will be written, sent > on the list, and the ADs will decided what can be done and where. > > > > > --94eb2c0c9bbe8a9a2e054c73c132 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks!

On Wed, Apr 5, 2017 at 12:50 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Below are my notes from the DISPATCH session.=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

-------------------------

=C2=A0

Topic:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Path MTU Disco= very (PMTUD) for RTP/RTCP

Presenter:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Marc Petit-Huguenin

Draft:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-petithug= uenin-dispatch-rtp-pmtud-00

=C2=A0

What is it?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Defines the usage of the for RTP/RTCP path discovery u= sing the PMTUD protocol.

=C2=A0

Presentation in a nutshell?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The following questions/issues were presented:<= u>

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 How to uniquely identify RTP/RTCP packets?

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 How to signal support/usage of the mechanism in SDP?

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 What are the ICE impacts?

=C2=A0

What did people say?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Most of the discussion was about why ICE can't be = used instead.

=C2=A0

Ok, so what next?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Figure out how to do this on the ICE layer rather than= on the RTP layer. Then, IF there are use-cases where RTP would be more fea= sible they can be looked at. However, currently no such use-cases have been= identified.

=C2=A0

=C2=A0

Topic:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Web Linking=

Presenter:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Mark Nottingham

Draft:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-nottingh= am-rfc5988bis-04

=C2=A0

What is it?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 A way to indicate the relationships between resources = on the Web and the type of those relationships.

=C2=A0

Presentation in a nutshell?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The presenter indicated that there are currently no op= en issues in the draft, but that some minor stuff still has to be done, rel= ated to references, terminology, incorporation of errata, ABNF, etc...

=C2=A0

What did people say?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Most of the discussion was of administrative nature. I= s a bis needed, and/or shall the registry be updated (not covered in the cu= rrent draft).

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It was indicated that a registry change would require = a BoF, as it is outside the current scope of the ART area.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It was discussed whether the specification would be pr= ogressed as AD sponsored, or whether a new WG would be needed. People didn&= #39;t seem to think a new WG would be necessary.

=C2=A0

Ok, so what next?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Discussions regarding where the work would take place = will take place on the DISPATCH list.

=C2=A0

=C2=A0

Topic:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Location Param= eter for the SIP Reason Header Field

Presenter:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Roland Jesske

Draft:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-jesske-d= ispatch-reason-loc-q850-00.txt

=C2=A0

What is it?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Adds a location value parameter to the Reason header f= ield reason-extension parameter, so that the location value can be interwor= ked from the PSTN.

=C2=A0

Presentation in a nutshell?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The use-case where the new information would be needed= was presented.

=C2=A0

What did people say?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 There was a question whether the Reason header field i= n an non-200 SIP response would traverse proxies. Indicated that Reason hea= der fields do tend to traverse proxies.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It was indicated that the work would fit the SIPCORE W= G charter.

=C2=A0

Ok, so what next?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The draft will be dispatched to the SIPCORE WG. SIPCOR= E will then decide whether to adopt the draft.

=C2=A0

=C2=A0

Topic: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cryptographic Update= to DKIM

Presenter: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 John Levine

Draft:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-levine-d= crup-dkim-crypto-00

=C2=A0

What is it?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Adds a new DKIM algorithm (ECHD), which has a shorter = key size than RSA for similar level of security.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Adds the possibility to store the key hash, rather tha= n the key, in DNS, and include the key in the signature.

=C2=A0

Presentation in a nutshell?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Deployed DNS configuration software places a limit on = key sizes, because the software only handles a single 256 octet string in a= single TXT record, and RSA keys longer than 1024 bits don't fit in 256= octets.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Two alternatives were presented:

-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 1. Define usage of a new algorithm, with smaller keys.<= /u>

-=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 2. Put a fixed size key hash (instead of the key itself) in the D= NS, and put the associated public key in the signature.

=C2=A0

What did people say?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 There was a preference for placing the key hash in the= DNS. Then, if people in addition also want to update the algorithm, that c= an be done too.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It was indicated that there are IPR(s) associated with= publishing a key hash in DNS.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 It was discussed where the work would be done. The CUR= DLE WG was suggested. It was indicated that the CURDLE WG is very narrowly = scoped, and that a new WG would be preferred.

=C2=A0

Ok, so what next?

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 A short proposed charter for a mini WG will be written= , sent on the list, and the ADs will decided what can be done and where.=

=C2=A0

=C2=A0


--94eb2c0c9bbe8a9a2e054c73c132-- From nobody Thu Apr 6 16:32:46 2017 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 2B49A1296AC for ; Thu, 6 Apr 2017 16:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yl8uAt1ow_CQ for ; Thu, 6 Apr 2017 16:32:42 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1A81296A5 for ; Thu, 6 Apr 2017 16:32:41 -0700 (PDT) Received: (qmail 28597 invoked from network); 6 Apr 2017 23:32:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Apr 2017 23:32:36 -0000 Date: 6 Apr 2017 23:32:14 -0000 Message-ID: <20170406233214.47717.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org Cc: johnl@taugh.com In-Reply-To: <20170404161917.37759.qmail@ary.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.2 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 23:32:44 -0000 Scott Rose submitted this draft with suggested new algorithms for DCRUP. --- snippo --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-srose-dkim-ecc-00.txt Pages : 6 Date : 2017-04-06 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-srose-dkim-ecc-00.txt Pages : 6 Date : 2017-04-06 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-srose-dkim-ecc-00.txt Pages : 6 Date : 2017-04-06 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-srose-dkim-ecc-00.txt Pages : 6 Date : 2017-04-06 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-srose-dkim-ecc-00.txt Pages : 6 Date : 2017-04-06 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 7 09:36:27 2017 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 8BEFD124282 for ; Fri, 7 Apr 2017 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=R8hYljOe; dkim=pass (1536-bit key) header.d=taugh.com header.b=KF0Z5vZe 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 VnUAcyQQ7dZm for ; Fri, 7 Apr 2017 09:36:23 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0404512944A for ; Fri, 7 Apr 2017 09:36:22 -0700 (PDT) Received: (qmail 1183 invoked from network); 7 Apr 2017 16:36:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=493.58e7c002.k1704; bh=8Z7mh56mhQPsXcEOmdv6TCLuxZjof7k+vmrG71KWkO0=; b=R8hYljOeOn5m25capwcGs9M37zr7uR1kWQ/PT2drAsEpq+hshVph5j4NN4F+kzE2YvJPhjI/TI1wZ0UbrsoT+0D9rLM7V+IboQ+poNipg9FPdRhcUSYfrMb93fFmY2DesaOxM5hYEZE7WriKXUbUK6o4UMZImeqwefexwYWaOl3UhkxI+OlBYrKgxrtkDvY11yrq9Fd/D87OW8n5cU9zF6Brt7eD8zYxcNq/VyGvUwe/5f3a6rskLIeSNHxA8rez DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=493.58e7c002.k1704; bh=8Z7mh56mhQPsXcEOmdv6TCLuxZjof7k+vmrG71KWkO0=; b=KF0Z5vZe/pf5Zp4WL5yZ+ohBFBn+1rymESxTxT+dz/uBwlvPzkApXXIeTmHPxjK5A+MC48gdEP9h+Jjz8YVZ/ElPoTl1/qPLXH5nsHTrUqkvmavz7n/bSFDpYNuJGJaulxQvmo8ipVB55mE2mgRdEZQfMHHEmX3zv11HJJG0gvKAb75N8/rxrHB3i/l1XAbDEtGTvipvy/DRAqM5zfEUWdICmnsrl3+0WwrWZKc35LhTHzMbdn9FCDABdCvYKDnn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Apr 2017 16:36:18 -0000 Date: 7 Apr 2017 12:36:18 -0400 Message-ID: From: "John R Levine" To: "DISPATCH list" In-Reply-To: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dispatch] Proposed charter for DCRUP v0.3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:36:26 -0000 One last twiddle, make it clear we can deprecate obsolete signing algorithms. I have in mind SHA-1 and RSA-512. Assuming people are happy with this, what's the next step? R's, John ----------- The DKIM Crypto Update (DCRUP) working groupkin is chartered to update DKIM to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DCRUP will consider three types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements including deprecating obsolete algorithms, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS. It will limit itself to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. From nobody Fri Apr 7 09:42:11 2017 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 4D6C7129543 for ; Fri, 7 Apr 2017 09:41:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9UnMmdadtirn for ; Fri, 7 Apr 2017 09:41:57 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 0C9051294E0 for ; Fri, 7 Apr 2017 09:41:57 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id j9so13636216ywj.3 for ; Fri, 07 Apr 2017 09:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XdLe9z+EM+5ju2FoFvVfBWGSK9XqeO3b/lQlGwkLK8Y=; b=Gqh/ZULygxNARzbbTTFQAgAVOFVu1nUKvfkotydQOpQ9uQ2fQY4T85bwcbRlNMTSlt Z6yYnRA7uM7Dw3IAEn6F31Oun9BatFP3QhZJn70WbSC2DbqwCf65LDttbyCYBSMCMEFE SCLOTQBTusT9uhRzzNiq20hCYsszXs4TLMigoBafHAyDvLrozUWNpVGvQomQMUiErXGt BW1fomGm78GBQQzq1LFP8sjRpseRfTo4fZknihUCoG48QxWGgDCJXVZCRS6qmEw/fTT8 TojUD/8GoHDzMjQYK559RMfawyjliHOKTZgIYoSc4lk3DeD/zeQ3RtoXQieHKCQODXaP GOQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XdLe9z+EM+5ju2FoFvVfBWGSK9XqeO3b/lQlGwkLK8Y=; b=X+fzAIIV0WtbUM5QeuNhJJId5Ni3+bSIrdVQyBTsvztqV3X4GB20TGtA0gMfpYCMiq o7AlCLFAI3c5VaAvh1nLeCDqKfSmmNGzVCTZRMhBIYBnyQ/XANEUflFelcpx3OjtjcWH o5vOfdN63sGePnqQg7p3o1fRLFzrV6ZdS9jfIV+0td08Mn6TB/dzftqTJ8SRSLjfJKLl /wESWwPqTfv2EjEr1IBN+kQf7w4U1ULqnIGOzSYs3Ef7fnnNwNz/HBC/fLxuqhVLf+ZM HwqG32lXjjSV8mLmTCU43UYphdVS7SzRiBnCZNogQJVQqQp2Q7/gMHGunStnMxjERlDS w9mg== X-Gm-Message-State: AN3rC/7vWs5ZWqsI23K7TQ5JkwzirY5SRvwQk5EKVv6N1ME1l6t4s88LSkusmmZpk15CuywEPvFOIkeGvqguJg== X-Received: by 10.13.250.129 with SMTP id k123mr3174699ywf.276.1491583316133; Fri, 07 Apr 2017 09:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 7 Apr 2017 09:41:15 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Apr 2017 09:41:15 -0700 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: multipart/alternative; boundary=94eb2c080a1cb61fbe054c964d3f Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:41:59 -0000 --94eb2c080a1cb61fbe054c964d3f Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 9:36 AM, John R Levine wrote: > One last twiddle, make it clear we can deprecate obsolete signing > algorithms. I have in mind SHA-1 and RSA-512. > > Assuming people are happy with this, what's the next step? > > R's, > John > > ----------- > > The DKIM Crypto Update (DCRUP) working groupkin is chartered to update > DKIM to handle more modern cryptographic algorithms and key sizes. DKIM > (RFC 6376) signatures include a tag that identifies the hash algorithm and > signing algorithm used in the signature. The only current algorithm is RSA, > with advice that signing keys should be between 1024 and 2048 bits. While > 1024 bit signatures are common, longer signatures are not because bugs in > DNS provisioning software prevent publishing longer keys as DNS TXT > records. > > DCRUP will consider three types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, changes to key strength > advice and requirements including deprecating obsolete algorithms, and new > public key forms, such as putting the public key in the signature and a > hash of the key in the DNS. It will limit itself to existing implemented > algorithms and key forms. Can you clarify "implemented" here? Do you just mean "in wide use by IETF or otherwise"? -Ekr Other changes to DKIM, such as new message canonicalization schemes, are > out of scope. The WG will as far as possible avoid changes incompatible > with deployed DKIM signers and verifiers. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --94eb2c080a1cb61fbe054c964d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 9:36 AM, John R Levine <johnl@taugh.com> wrote:
One last twiddle, make it cl= ear we can deprecate obsolete signing algorithms.=C2=A0 I have in mind SHA-= 1 and RSA-512.

Assuming people are happy with this, what's the next step?

R's,
John

-----------

The DKIM Crypto Update (DCRUP) working groupkin is chartered to update
DKIM to handle more modern cryptographic algorithms and key sizes. DKIM
(RFC 6376) signatures include a tag that identifies the hash algorithm and<= br> signing algorithm used in the signature. The only current algorithm is RSA,=
with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records= .

DCRUP will consider three types of changes to DKIM: additional signing algo= rithms such as those based on elliptic curves, changes to key strength advi= ce and requirements including deprecating obsolete algorithms, and new publ= ic key forms, such as putting the public key in the signature and a hash of= the key in the DNS.=C2=A0 It will limit itself to existing implemented alg= orithms and key forms.

Can you clarify &quo= t;implemented" here? Do you just mean "in wide use by IETF or oth= erwise"?

-Ekr



Other changes to DKIM, s= uch as new message canonicalization schemes, are out of scope.=C2=A0 The WG= will as far as possible avoid changes incompatible with deployed DKIM sign= ers and verifiers.

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

--94eb2c080a1cb61fbe054c964d3f-- From nobody Fri Apr 7 09:51:57 2017 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 6986A12952E for ; Fri, 7 Apr 2017 09:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ZHp3v/Uy; dkim=pass (1536-bit key) header.d=taugh.com header.b=f+K0vQ5M 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 X915p8Ia8TaD for ; Fri, 7 Apr 2017 09:51:53 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76973129528 for ; Fri, 7 Apr 2017 09:51:53 -0700 (PDT) Received: (qmail 3987 invoked from network); 7 Apr 2017 16:51:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f76.58e7c3a3.k1704; bh=bGCpdpetg98FprFzZOi3Jwcj9xOEoCPV0CxBD/oNwF4=; b=ZHp3v/Uyvw+HeBHnLA7vsOJ3yGaGdkoLqv1hfNuK2Cee/qAWHG/6PmBppqwSzRdjo5vWgPkmCSXzuEpUpsxHfYV4Hl8gdI9l8S/5MzuaIU2thsR2XZWMV4XgHFv9T6yotpiGhVAsYpdOJT2SPuVNZJjh6lUgw7vcygdtvw09n72kFH/Oh0PZo0JgNI6KLZ5nPCVMGbLAAfTFB1ORXg9BIM3e6j2sL13IdhNXcqTxNh/acTwU2kjf7YC0FUdfPlbs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f76.58e7c3a3.k1704; bh=bGCpdpetg98FprFzZOi3Jwcj9xOEoCPV0CxBD/oNwF4=; b=f+K0vQ5MnAa924MlR3PSepgXStHz90EId9hU7vOUwYDM/ng68Bw5IIt5GpwP8Aj5o1UHGpUcAKsr5wN8DSHQ7LiQtd/zPTUxHnhwas5wWmBYbYMymPykuekyhbZoI3fN1nAHHW11bNnJ7YNekHWElgd0kRBQ9CSC3mxT8HMGgB2b6JAmca2ueV6MjziZaSWoXQ/Skd7m2mHMsL37VXdzuvPjizfJ4lM63QZN/3bcavcYFQjW5kdG/YSW/tTxxGIN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Apr 2017 16:51:37 -0000 Date: 7 Apr 2017 12:51:36 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: "DISPATCH list" In-Reply-To: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:51:55 -0000 >> hash of the key in the DNS. It will limit itself to existing implemented >> algorithms and key forms. > > Can you clarify "implemented" here? Do you just mean "in wide use by IETF > or otherwise"? That's essentially what I had in mind. Freely available high quality imeplmentations would be nice. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 7 09:54:25 2017 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 DD58D129514 for ; Fri, 7 Apr 2017 09:54:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cbgDF4rxUFhH for ; Fri, 7 Apr 2017 09:54:20 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 D2E0E12942F for ; Fri, 7 Apr 2017 09:54:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id d191so37205483ywe.2 for ; Fri, 07 Apr 2017 09:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FDMIIaHF1eTTb+YsIBV9oOT+KF8XavdRNIU7N51hhI4=; b=MtwXnYZK62wpQ1DVfvF8I75zpYolrypAZg8xLppTa62BmnpCFHP6jwfUHH0p2JbnX5 5ycEjsk/mDB84z/PDF2ARr2eP8OyXFPbgGxlNOCLOnOBM8iurfYGYO29+c1MWK2nLaU0 9KV3XJWhMw3P44B5MIaRxOZ2eZrguUSsDFRQOYwhim2LFU+K++qOQMoY5y4ID4e5xyCR jL2DxySY/a9CJLxKQJaUObSQw+2LnM0H/Vl52Cslg1Lf7mcfcrpYI6STzrDyohy+lR8e TFW2U0BfMK694mthGwHsHWyM+X3N2hOkIYEicY5Hz8o4Zwee7zI2TFR2h/7d3yIDm5YT HM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FDMIIaHF1eTTb+YsIBV9oOT+KF8XavdRNIU7N51hhI4=; b=izOKS2RuMNsqQd47miTnjEF5GOw7VNKT9YW0wDFJI2jj8jwlRxEvQ0JqZqzDRk2OMm xTtBFF3sWuz3hXuuo/glygwWoz1i+fy9JoFz5jO3rz13RFR+Mit+7lPO9KRV+jk89QqK SnKp3NsWwcvdcplPK/TJ2SjWxJ+UDUGhHZ615tZtSv9Ur3R25yyHB0YMhKrjlw9r6QCm qad/uIvr5zS8KZawC+tgOkKcCHLEUVzUE/YULTSbw231GAhvlyYzDVVnSpObg64matBn Iqq5m6kunsheVkT8pdMLLFqW8oamfP4fvbt8Z4LLwc+5ZSXHRv/JQOS488rrefRP0q4k 2Ssw== X-Gm-Message-State: AFeK/H3XEgloOQJqLPRtv202ipf1ozF+wh879Xtv8CXakGLqqmW3eXUphlh03tM3qOWP2iX03B4y0kVZsgjo8A== X-Received: by 10.13.240.199 with SMTP id z190mr27069938ywe.125.1491584059015; Fri, 07 Apr 2017 09:54:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 7 Apr 2017 09:53:38 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Apr 2017 09:53:38 -0700 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: multipart/alternative; boundary=94eb2c03380cfdb5de054c9679ff Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 16:54:22 -0000 --94eb2c03380cfdb5de054c9679ff Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 9:51 AM, John R Levine wrote: > hash of the key in the DNS. It will limit itself to existing implemented >>> algorithms and key forms. >>> >> >> Can you clarify "implemented" here? Do you just mean "in wide use by IETF >> or otherwise"? >> > > That's essentially what I had in mind. Freely available high quality > imeplmentations would be nice. > The only reason I mentioned this is that one might think that this meant "implemented in DKIM". Do you think "limit itself to algorithms and key forms generally in use in the IETF"? would be clearer? -Ekr > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --94eb2c03380cfdb5de054c9679ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 9:51 AM, John R Levine <johnl@taugh.com> wrote:
hash of the key in the DNS.=C2=A0 It will limit itself to existing implemen= ted
algorithms and key forms.

Can you clarify "implemented" here? Do you just mean "in wid= e use by IETF
or otherwise"?

That's essentially what I had in mind.=C2=A0 Freely available high qual= ity imeplmentations would be nice.

The = only reason I mentioned this is that one might think that this meant
<= div>"implemented in DKIM". Do you think "limit itself to alg= orithms and
key forms generally in use in the IETF"? would b= e clearer?

-Ekr
=C2=A0

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--94eb2c03380cfdb5de054c9679ff-- From nobody Fri Apr 7 10:06:43 2017 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 D1BA412951B for ; Fri, 7 Apr 2017 10:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Dtkfnjtc; dkim=pass (1536-bit key) header.d=taugh.com header.b=R9PB3A1j 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 YVWMZufunkau for ; Fri, 7 Apr 2017 10:06:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A982F1296C9 for ; Fri, 7 Apr 2017 10:06:28 -0700 (PDT) Received: (qmail 6288 invoked from network); 7 Apr 2017 17:06:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=186a.58e7c70b.k1704; bh=JhFaqdblD0RRbOvoN17btOtzsHUc6LKSog7y6w1nTx8=; b=DtkfnjtcbIDhJpTtvztBWwl5yZdYmOrIw5dMFxQxvIC9CyZP4+SXpff7GAH7bS57/y0oX+q4U5KA822caSHJBdoIuQHkIbUu/vTzwGnXz/zALHuSibOkRbM2EwZM2uo+DZjuNOEDbtF/wEGGPOB7Q0BbbUffE5H5P8UAP5Aw/0B+zz00iSVf1WvfptSWzfDzNrwEK/hDp43MwN2kTce8MK3uSSjYPkW21Obe7X0fshFjtW+y76H4DWwJE7JyZVRu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=186a.58e7c70b.k1704; bh=JhFaqdblD0RRbOvoN17btOtzsHUc6LKSog7y6w1nTx8=; b=R9PB3A1jySSOCBB694F/sQaS73ttwU6jvGO2mR9XjWWO2x2DpDZ+C+FwtTsJR6CB/+CIH3FOSwu6uX6BkblJFi4AYUjX01/lgHM/knlRA++ppbvDlB3LvOuTpN2YPIEwljINWi+DOT2IsS1dpyBA6i9E/REcL6Ai/9ke7rtMXdFoHjTbJD+m3JioKBZVx0dAX0iQ+hX5FXPOFFnWTrNnBiTufwufAPGvmzx3eb1xUSl1gpRwTkmp/wkY6lsucWkP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Apr 2017 17:06:12 -0000 Date: 7 Apr 2017 13:06:12 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: "DISPATCH list" In-Reply-To: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP v0.3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:06:41 -0000 > The only reason I mentioned this is that one might think that this meant > "implemented in DKIM". Do you think "limit itself to algorithms and > key forms generally in use in the IETF"? would be clearer? Sure, why not. R's, John From nobody Thu Apr 13 05:01:03 2017 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 6B5D8129426 for ; Thu, 13 Apr 2017 05:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=yandex.ru 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 9HbkW4E-9Nao for ; Thu, 13 Apr 2017 05:00:58 -0700 (PDT) Received: from forward8m.cmail.yandex.net (forward8m.cmail.yandex.net [5.255.216.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A9F131592 for ; Thu, 13 Apr 2017 05:00:58 -0700 (PDT) Received: from mxback11j.mail.yandex.net (mxback11j.mail.yandex.net [IPv6:2a02:6b8:0:1619::84]) by forward8m.cmail.yandex.net (Yandex) with ESMTP id D453B212A1 for ; Thu, 13 Apr 2017 15:00:55 +0300 (MSK) Received: from web50j.yandex.ru (web50j.yandex.ru [5.45.198.200]) by mxback11j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id En3wfKpARQ-0mdieBDq; Thu, 13 Apr 2017 15:00:49 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1492084849; bh=aBNSH+l7+Epw2C0XRineVNwcjtt8/1ik4MkKP9XjWAc=; h=From:To:Subject:Message-Id:Date; b=A6Lh1zqvjdmqAxzsEYKTH+qOtLUQq78LowzbFg6umDKaVdZZKalFpvbcjBYDTMeog 7/z+P8/6NLQ7lIU1hdV5/ApXdDPed1tMSoL3ycevc60muW+tAWWKWKWP2HgCv0yKlt yEyrwjjXibTpmdZaMGH4SAz1SsZ+UCE4QsAnLyMM= Authentication-Results: mxback11j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web50j.yandex.ru with HTTP; Thu, 13 Apr 2017 15:00:48 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 Message-Id: <3901081492084848@web50j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 13 Apr 2017 17:00:48 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: [dispatch] draft-tveretin-dispatch-l2tp-sdp-02 & for draft-tveretin-dispatch-remote-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 12:01:02 -0000 Hello All! Finally, I re-uploaded both my I-Ds. For the first I-D, I followed my own notes to make SIP self-sufficient. So I reordered few paragraphs. I believe it should be DISPATCH'ed to the MMUSIC. I did no changes to the second I-D. I believe it should be DISPATCH'ed to the SIPCORE, as new methods are really core-level change. Sorry to Dale. But I think it's weird to put a reference into an I-D to another I-D unless they are really connected. Regards, Anton. A new version of I-D, draft-tveretin-dispatch-l2tp-sdp-02.txt has been successfully submitted by Anton Tveretin and posted to the IETF repository. Name: draft-tveretin-dispatch-l2tp-sdp Revision: 02 Title: Session Description Protocol Support for Tunnels (L2TP) Document date: 2017-04-10 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-tveretin-dispatch-l2tp-sdp-02.txt Status: https://datatracker.ietf.org/doc/draft-tveretin-dispatch-l2tp-sdp/ Htmlized: https://tools.ietf.org/html/draft-tveretin-dispatch-l2tp-sdp-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-tveretin-dispatch-l2tp-sdp-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-tveretin-dispatch-l2tp-sdp-02 Abstract: This document registeres new media type (application/l2tp) to be used with SDP, and clarifies procedure to be used by peers for L2TP tunnels. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat A new version of I-D, draft-tveretin-dispatch-remote-03.txt has been successfully submitted by Anton Tveretin and posted to the IETF repository. Name: draft-tveretin-dispatch-remote Revision: 03 Title: Remote Call Control and Call Pick-up in SIP Document date: 2017-04-10 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-03.txt Status: https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/ Htmlized: https://tools.ietf.org/html/draft-tveretin-dispatch-remote-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-tveretin-dispatch-remote-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-tveretin-dispatch-remote-03 Abstract: This memo defines a mechanism by which a SIP user agent could inspect calls at another user agent, and control a call, including picking up for itself. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 18 15:46:05 2017 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 5DC861314D9 for ; Tue, 18 Apr 2017 15:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 ZY0jJzCzNWIc for ; Tue, 18 Apr 2017 15:46:02 -0700 (PDT) Received: from smtp104.iad3a.emailsrvr.com (smtp104.iad3a.emailsrvr.com [173.203.187.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 B8C8E1314D7 for ; Tue, 18 Apr 2017 15:46:00 -0700 (PDT) Received: from smtp38.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp38.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3A2BB593B; Tue, 18 Apr 2017 18:45:57 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp38.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E337C5919; Tue, 18 Apr 2017 18:45:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.109.110] (184-23-135-130.dedicated.static.sonic.net [184.23.135.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Tue, 18 Apr 2017 18:45:57 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <3901081492084848@web50j.yandex.ru> Date: Tue, 18 Apr 2017 15:45:55 -0700 Cc: DISPATCH list Content-Transfer-Encoding: quoted-printable Message-Id: <06E84CA0-C47C-4735-BC6C-DA335601B780@iii.ca> References: <3901081492084848@web50j.yandex.ru> To: Anton Tveretin X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] draft-tveretin-dispatch-l2tp-sdp-02 & for draft-tveretin-dispatch-remote-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 22:46:04 -0000 It will be good to see some discussion of this. I know in the past there = had been some concerns about expanding the scope of SIP for setting up = things other than user media connections.=20 > On Apr 13, 2017, at 5:00 AM, Anton Tveretin = wrote: >=20 > Hello All! > Finally, I re-uploaded both my I-Ds. > For the first I-D, I followed my own notes to make SIP = self-sufficient. So I reordered few paragraphs. > I believe it should be DISPATCH'ed to the MMUSIC. > I did no changes to the second I-D. I believe it should be DISPATCH'ed = to the SIPCORE, as new methods are really core-level change. > Sorry to Dale. But I think it's weird to put a reference into an I-D = to another I-D unless they are really connected. > Regards, > Anton. >=20 >=20 > A new version of I-D, draft-tveretin-dispatch-l2tp-sdp-02.txt > has been successfully submitted by Anton Tveretin and posted to the > IETF repository. >=20 > Name: draft-tveretin-dispatch-l2tp-sdp > Revision: 02 > Title: Session Description Protocol Support for Tunnels (L2TP) > Document date: 2017-04-10 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-tveretin-dispatch-l2tp-sdp-02.t= xt > Status: = https://datatracker.ietf.org/doc/draft-tveretin-dispatch-l2tp-sdp/ > Htmlized: = https://tools.ietf.org/html/draft-tveretin-dispatch-l2tp-sdp-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tveretin-dispatch-l2tp-sdp-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tveretin-dispatch-l2tp-sdp-02 >=20 > Abstract: > This document registeres new media type (application/l2tp) to be = used > with SDP, and clarifies procedure to be used by peers for L2TP > tunnels. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > A new version of I-D, draft-tveretin-dispatch-remote-03.txt > has been successfully submitted by Anton Tveretin and posted to the > IETF repository. >=20 > Name: draft-tveretin-dispatch-remote > Revision: 03 > Title: Remote Call Control and Call Pick-up in SIP > Document date: 2017-04-10 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-03.txt= > Status: = https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/ > Htmlized: = https://tools.ietf.org/html/draft-tveretin-dispatch-remote-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tveretin-dispatch-remote-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tveretin-dispatch-remote-03 >=20 > Abstract: > This memo defines a mechanism by which a SIP user agent could = inspect > calls at another user agent, and control a call, including picking = up > for itself. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch