From nobody Wed Mar 1 10:01: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 BD3D31294A9 for ; Wed, 1 Mar 2017 10:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 EKDHPg1rEaJx for ; Wed, 1 Mar 2017 10:01:04 -0800 (PST) Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (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 0008D129638 for ; Wed, 1 Mar 2017 10:01:03 -0800 (PST) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2E344252DC; Wed, 1 Mar 2017 13:00:58 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E01C125178; Wed, 1 Mar 2017 13:00:56 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 01 Mar 2017 13:00:58 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> Date: Wed, 1 Mar 2017 11:00:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> References: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.3259) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] draft-petithuguenin-ice-pmtud-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:01:11 -0000 So it seems like this would be in scope for TRAM. Would it make sense to = just send it there or do you think we should consider other places for = it? > On Feb 18, 2017, at 4:46 PM, Marc Petit-Huguenin = wrote: >=20 > Dear Dispatch, >=20 > I would like 5 minutes to present draft-petithuguenin-ice-pmtud-00 = (not yet published) during the dispatch session. This draft started = with the ICE specific stuff that was removed from = draft-ietf-tram-stun-pmtud-02, with the goal of defining a usage of = stun-pmtud to discover the Path MTU for an RTP/RTCP session. >=20 > Thanks. >=20 > --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Mar 2 05:20:56 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 10430129538 for ; Thu, 2 Mar 2017 05:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 m0qpvt6UBVW3 for ; Thu, 2 Mar 2017 05:20:53 -0800 (PST) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F06129464 for ; Thu, 2 Mar 2017 05:20:53 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:ec66:81fa:c7ba:cc3d] (unknown [IPv6:2601:648:8301:730f:ec66:81fa:c7ba:cc3d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 01534AE7A5; Thu, 2 Mar 2017 14:20:50 +0100 (CET) To: Cullen Jennings References: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> From: Marc Petit-Huguenin Message-ID: <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> Date: Thu, 2 Mar 2017 05:20:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bl5aSiEctWJAvKHwRWhS5r5g0ei434VlG" Archived-At: Cc: DISPATCH Subject: Re: [dispatch] draft-petithuguenin-ice-pmtud-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 13:20:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Bl5aSiEctWJAvKHwRWhS5r5g0ei434VlG Content-Type: multipart/mixed; boundary="7LTmbwQILDHWq7LdSmPpwWbpSS5wg2qHE"; protected-headers="v1" From: Marc Petit-Huguenin To: Cullen Jennings Cc: DISPATCH Message-ID: <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> Subject: Re: [dispatch] draft-petithuguenin-ice-pmtud-00 References: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> In-Reply-To: <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> --7LTmbwQILDHWq7LdSmPpwWbpSS5wg2qHE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/01/2017 10:00 AM, Cullen Jennings wrote: >=20 > So it seems like this would be in scope for TRAM. Would it make sense t= o just send it there or do you think we should consider other places for = it? The subject of this draft is "How to do PMTUD with RTP" aka "how much vid= eo can I safely stuff in an RTP packet". Using STUN as the mechanism to = discover the MTU in the path of the RTP packets is not central to this di= scussion, but as a transport to collect the packets identifiers (i.e. to = implement RFC 4821). So it could be AVTCore (or whatever it will be call= ed after it reabsorbs payload and avtext). We will also need a way to si= gnal that an endpoint supports that feature and that's a new SDP attribut= e. So it could be MMUSIC. But maybe getting a larger Path MTU could be = used to prioritize ICE. So it could be in the ICE WG. But at the end th= e only people who will probably care about this stuff are RTCWeb peple, n= ot SIP people. So maybe WebRTC. Hence going to Dispatch to figure that = out. >=20 >=20 >> On Feb 18, 2017, at 4:46 PM, Marc Petit-Huguenin wr= ote: >> >> Dear Dispatch, >> >> I would like 5 minutes to present draft-petithuguenin-ice-pmtud-00 (no= t yet published) during the dispatch session. This draft started with th= e ICE specific stuff that was removed from draft-ietf-tram-stun-pmtud-02,= with the goal of defining a usage of stun-pmtud to discover the Path MTU= for an RTP/RTCP session. >> >> Thanks. >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --7LTmbwQILDHWq7LdSmPpwWbpSS5wg2qHE-- --Bl5aSiEctWJAvKHwRWhS5r5g0ei434VlG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAli4HDEACgkQKcRFldZq fsQAsw//RZh8oFOlemfir19gkYyyg9CkqMI4bgLdHMiqFe4wSaZb2eb/1m8vGfpp r/Gb8oAGAGBru5kQ7J71/qpcf0xPGWD0Wp+DkSDw5080QX8HMC6HbKuE45p5Ms48 ODnraF2nvk21icKhOEEyv5NNu06Qwjm9XS549d6iW3tLHanEOm6Hu+F6B8hzljSq UPuNiHEoDM2BeU5fxUyiPgkbhqW2LwMTrdthckR5GuMTADd5OTfNRB+CsleWvqRd UJokW1SHb21NYgeAT3MsRftHhtirQSE1qM53LDi3Uw4LPBmyEfLaCaD7bRm3wp0e ItCrH0OV58HFzqW6wAFmKigH2eVBp7CKP7PrZptjOplAf8AeOuBqQfViT/G5WcGi QXP2Hf2Tj1FNoEDdGAce3CX6lLKzC03YpU3w7FpeudrV7F6vYW1R9J6qNig9Cpne QnWafQ1xycawOOLjfkfoqNspK8qD3SAZE7iNk3QM+HDGi3ZbAyNVPzB2G15QIkU9 QuS0px2x6lk78ezYI4jXink57u+AIYxl9KIp7GbY8XERwcpE9vF2XMeQQ2OMpZnv zJ6w7Jmq4egTy90lyG9/fmFaj2gJwfo3NQ51uSxgeqXN4qRVEPrtLt7VbbeCvNm7 BRrJL6WlVTCBKdAunpeY3TT+ALmng/Ta3HOv5pLZqbGUTzF98HU= =ugQJ -----END PGP SIGNATURE----- --Bl5aSiEctWJAvKHwRWhS5r5g0ei434VlG-- From nobody Fri Mar 3 03:14:19 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 D00341294C6 for ; Fri, 3 Mar 2017 03:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=nokia.onmicrosoft.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 1kXvSbiDri_y for ; Fri, 3 Mar 2017 03:14:14 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0131.outbound.protection.outlook.com [104.47.1.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA6C129687 for ; Fri, 3 Mar 2017 03:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7XcoJiSkmPl1A6kT1AisLFH+JNmj9lR5jyOVFZIrazo=; b=CcMNlmTsj1TXLeirE6B9foQ9N9p7PKoVLFXNM3JnDFwwKDIZxfpPFmTal3tUNdUCB0N/MozjblQvmeu6oSuCJXFv1yCVTBHF8W8QoUIvY3vW+JM4nNVxIMkAoVvVMXslmai2b+w8p4TExHfAnaG9H+v2CZcquWh9PKCDDCY8koc= Received: from HE1PR0701MB2395.eurprd07.prod.outlook.com (10.168.128.14) by HE1PR0701MB2395.eurprd07.prod.outlook.com (10.168.128.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 11:14:11 +0000 Received: from HE1PR0701MB2395.eurprd07.prod.outlook.com ([10.168.128.14]) by HE1PR0701MB2395.eurprd07.prod.outlook.com ([10.168.128.14]) with mapi id 15.01.0947.012; Fri, 3 Mar 2017 11:14:11 +0000 From: "Belling, Thomas (Nokia - DE/Munich)" To: "dispatch@ietf.org" , "R.Jesske@telekom.de" Thread-Topic: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Thread-Index: AQHSkcuWWZ3iyBmJ80KThILpoEfaSKF+hkAAgAAB9oCABG5tkA== Date: Fri, 3 Mar 2017 11:14:11 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C8BD8B@VOEXM31W.internal.vodafone.com>, <27469_1488290665_58B58369_27469_5953_1_8B970F90C584EA4E97D5BAAC9172DBB81C92401C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1F0BB3B0-C521-4059-9573-A8EC80CB16DC@att.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C94D94@VOEXM31W.internal.vodafone.com> Accept-Language: de-DE, 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=nokia.com; x-originating-ip: [131.228.32.183] x-ms-office365-filtering-correlation-id: ca19b6f9-2f17-4448-060b-08d462266b77 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0701MB2395; x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2395; 7:v/X91aNxDKBrqcyEVfoGfZudeJOU0ij3vG+eSvFPoGqMZj0AAjOgF/vBdAd0FrQIKqhx8sfOad9j48oxCI8mjzndf8CWl8OGl8Gto+Fx3GB5bxNFMupFojN4nZb/wNJKNsVRWZRmvqbImjqMpmTLeT6UlqSs/Auhe9/mJACyy/FloXFPA8mAn7xtcV9DNMM7/QuHem8B+72Y7jEDKeee7Xf85GnvgpyNxHoWlozSh+34gJFiHbFwcEsLc/IEjoOCsUPBRHIKMRa3sWtMMRolTaF0vbWC9B0VIOHyHNOCjIMQP0X6FsOV5TBmJTtDcGooFyOzR3XqfVvbJDsXAJ6UxQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(97927398514766)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:HE1PR0701MB2395; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2395; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39450400003)(39840400002)(39860400002)(39410400002)(24454002)(252514010)(377454003)(53754006)(66066001)(122556002)(236005)(7906003)(55016002)(93886004)(92566002)(33656002)(77096006)(54896002)(9686003)(6306002)(99286003)(53936002)(3660700001)(230783001)(2906002)(50986999)(6436002)(25786008)(229853002)(76176999)(2900100001)(606005)(3280700002)(6506006)(54356999)(81166006)(3846002)(106116001)(102836003)(38730400002)(189998001)(7736002)(2950100002)(6116002)(8676002)(790700001)(2501003)(86362001)(6246003)(5890100001)(74316002)(5660300001)(575784001)(7696004)(8936002)(325944008)(53546006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2395; H:HE1PR0701MB2395.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2395BEEC5F78D0DE221A9757922B0HE1PR0701MB2395_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 11:14:11.5652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2395 Archived-At: Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:14:17 -0000 --_000_HE1PR0701MB2395BEEC5F78D0DE221A9757922B0HE1PR0701MB2395_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Roland I understand that the motivation of the work is to provide interworking for= the ISUP Cause location parameter, and the suggested values in the draft a= lso provide a 1-to-1 mapping. This is fine for me as there are use cases wh= ere not only the ISUP cause itself, but also the location could be of inter= est, e.g. to distinguish between Network Determined User Busy and Used Dete= rmined User Busy (NDUB/UDUB). It also feels natural to extent the SIP reaso= n header for that purpose which was originally designed to transport ISUP c= ause values (although it also has other usages, and the wording in the scop= e of the draft could be updated a bit accordingly) To avoid confusion about the semantics and purpose of the new parameter, I = would suggest to clarify this in the following manner: - Change the title of the draft to "ISUP Cause Location Parameter = for the SIP Reason Header Field" - Call the parameter "isup-cause-location" - Improve the wording in the scope a bit to clarify that the reaso= n header can also be used to transport other Reasons than ISUP causes, but = the new parameter is only applicable in combination with ISUP causes. Thomas ---------------------------------- Dr. Thomas Belling 3GPP Standardisation NOKIA Networks Nokia Solutions and Networks Management International GmbH Gesch=E4ftsleitung / Board of Directors: Andreas Sauer, Stephanie Werner Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 198081 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter= , Vodafone Group Sent: Tuesday, February 28, 2017 4:18 PM To: DOLLY, MARTIN C ; marianne.mohali@orange.com Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 you are right Marianne, my mistake Rgds, Peter From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTI= N C Sent: 28 February 2017 15:11 To: marianne.mohali@orange.com Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00 I support as well Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" > wrote: Hi All, I support this Internet-Draft to progress in IETF. I suggest to have some text to refer to RFC 6432 to ease the knowledge of t= he background and the usage of the Reason header field in error responses. = I can help to provide some text. On Peter's comment, I think it is correct to have "location=3DLN" in the ex= ample as the new parameter syntax is resp-location =3D "l= ocation" EQUAL string Best Regards, Marianne De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Dawes, Peter= , Vodafone Group Envoy=E9 : mardi 21 f=E9vrier 2017 13:11 =C0 : dispatch@ietf.org Objet : [dispatch] draft-jesske-dispatch-reason-loc-q850-00 Hi All, I have read through draft-jesske-dispatch-reason-loc-q850-00 and I think it= is clearly written and useful. One comment, I think the example in clause = 5 should say "resp-location=3DLN" instead of "location=3DLN". Regards, Peter ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ dispatch mailing list dispatch@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dispatch&d=3DDQICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw= 7ItG0r2g&m=3D9y5R3pOq5Oz0unZ73c_Z6ifowd5txi2vvpvlY7MtzoY&s=3DJGQJ2uxeZGcN3W= dhemtyHXnm2Iy-OSng_l27WUYpOlI&e=3D --_000_HE1PR0701MB2395BEEC5F78D0DE221A9757922B0HE1PR0701MB2395_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Roland

 

I understand that the motivatio= n of the work is to provide interworking for the ISUP Cause location parame= ter, and the suggested values in the draft also provide a 1-to-1 mapping. T= his is fine for me as there are use cases where not only the ISUP cause itself, but also the location could be= of interest, e.g. to distinguish between Network Determined User Bus= y and Used Determined User Busy (NDUB/UDUB). It also feels natural to exten= t the SIP reason header for that purpose which was originally designed to t= ransport ISUP cause values (although it also has other usages, and the wording in the scope of the draft could = be updated a bit accordingly)

 

To avoid confusion about the se= mantics and purpose of the new parameter, I would suggest to clarify this i= n the following manner:

-          C= hange the title of the draft to “ISUP Cause Location Parameter for th= e SIP Reason Header Field”

-          C= all the parameter ”isup-cause-location”

-          I= mprove the wording in the scope a bit to clarify that the reason header can= also be used to transport other Reasons than ISUP causes, but the new parameter is only applicable in combination with = ISUP causes.

 

Thomas

 

 

----------------------------------
Dr. Thomas = Belling

3GPP Stand= ardisation

NOKIA Networ= ks

 <= /span>

 <= /span>

Nokia Solutions and Networks Management International GmbH
Gesch=E4ftsleitung / Board of Di= rectors: Andreas Sauer, Stephanie Werner
Sitz der Gesellschaft: M=FCnchen= / Registered office: Munich
Registergericht: M=FCnchen / Com= mercial registry: Munich, HRB 198081

 <= /o:p>

 

 

 

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dawes, Peter, Vodafone Group
Sent: Tuesday, February 28, 2017 4:18 PM
To: DOLLY, MARTIN C <md3135@att.com>; marianne.mohali@orange.c= om
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00

 

you are= right Marianne, my mistake

&n= bsp;

Rgds,

Peter

&n= bsp;

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: 28 February 2017 15:11
To: marianne.mohali@or= ange.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-jesske-dispatch-reason-loc-q850-00

 

= I support as well

Martin C. Dolly

Lead Member of Technical Staff<= o:p>

Core & Government/Regulator= y Standards

AT&T

Cell: +1.609.903.3360

Email: md3135@att.com

 

=
On Feb 28, 2017, at 9:04 AM, "marianne.mohali@orange.com" <marianne.mohali@orange.com> wrote:

Hi All,=

 <= /span>

I suppo= rt this Internet-Draft to progress in IETF.

 <= /span>

I sugge= st to have some text to refer to RFC 6432 to ease the knowledge of the back= ground and the usage of the Reason header field in error responses. I can h= elp to provide some text.

 <= /span>

On Peter’s comment, I think it is correct to have &=
quot;location=3DLN" in the example=
 as the new parameter syntax is       &n=
bsp;       resp-location    =
=3D  "location" EQUAL string

 <= /span>

Best Re= gards,

Mariann= e

 <= /span>

 <= /span>

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_HE1PR0701MB2395BEEC5F78D0DE221A9757922B0HE1PR0701MB2395_-- From nobody Fri Mar 3 15:59:11 2017 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 67B1A1299E3; Fri, 3 Mar 2017 15:55:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532936.15846.12666230276175860265.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:29 -0800 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 98 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:29 -0000 Dear Cullen Jennings, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (1:30:00) Monday, Morning Session I 0900-1130 Room Name: Zurich A size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Cullen Jennings Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: appsawg core clue bfcpbis avtext avtcore apparea dbound ecrit insipid mmusic netvc payload rmcat rtcweb sipcore stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap People who must be present: Alexey Melnikov Mary Barnes Ben Campbell Cullen Jennings Murray Kucherawy Resources Requested: Meetecho support in room Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Fri Mar 10 09:01: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 D2EB3129687 for ; Fri, 10 Mar 2017 09:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 fl4EW_z-rdA7 for ; Fri, 10 Mar 2017 09:01:48 -0800 (PST) Received: from smtp128.dfw.emailsrvr.com (smtp128.dfw.emailsrvr.com [67.192.241.128]) (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 0290E129690 for ; Fri, 10 Mar 2017 09:01:48 -0800 (PST) Received: from smtp29.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 891124028F; Fri, 10 Mar 2017 12:01:47 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 32DDC401F8; Fri, 10 Mar 2017 12:01:47 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 10 Mar 2017 12:01:47 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 10 Mar 2017 10:01:46 -0700 Message-Id: <61608CE4-72DC-41F4-BDD5-5DD262181C7B@iii.ca> To: DISPATCH X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [dispatch] Draft DISPATCH Agenda IETF98 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:01:49 -0000 DISPATCH Agenda IETF 98 v2 Status Update * introduce new AD BOF Update * Update on important BOFs or new WG you need to know about ICE PMTUD * draft-petithuguenin-ice-pmtud - 10 min (Marc) * discussion - 10 min (everyone) Web Linking (Revision of 5988) * draft-nottingham-rfc5988bis and charter - 10 min (Mark) * discussion - 20 min (everyone) DKIM * brief summary of problem - 10 min (John) * discussion - 20 min (everyone) Q850 Reason Location * draft-jesske-dispatch-reason-loc-q850 - 10 min (Roland) * discussion - 10 min ( everyone) Area Meeting Topics / Open Mic ( 5 min time permitting) * email chairs if you have something that is critical to go here From nobody Sun Mar 12 14:29:12 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 A7E011293DA; Sun, 12 Mar 2017 14:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 P8pVoWCXDuKG; Sun, 12 Mar 2017 14:29:10 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D46126DFB; Sun, 12 Mar 2017 14:29:10 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id CB7B8160346; Sun, 12 Mar 2017 22:29:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id AEE86C0057; Sun, 12 Mar 2017 22:29:08 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Sun, 12 Mar 2017 22:29:08 +0100 From: To: "dispatch@ietf.org" Thread-Topic: Moving draft-mohali-dispatch-originating-cdiv-parameter-03 to SIPCORE Thread-Index: AdKbd0z5Y6WQuz9PRjik2qkb9xtjcA== Date: Sun, 12 Mar 2017 21:29:08 +0000 Message-ID: <30799_1489354148_58C5BDA4_30799_13854_1_8B970F90C584EA4E97D5BAAC9172DBB81C935C5C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch-chairs@ietf.org" Subject: [dispatch] Moving draft-mohali-dispatch-originating-cdiv-parameter-03 to SIPCORE X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:29:11 -0000 Hi, FYI, based on ADs and Chairs guidance, this draft draft-mohali-dispatch-ori= ginating-cdiv-parameter-03 has been moved to SIPCORE following the new char= ter of sipcore WG. The new I-D is draft-mohali-sipcore-originating-cdiv-parameter-00. https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-= parameter-00.txt Thanks to DISPATCH for the feedbacks. Best regards, Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Mar 13 06:22: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 9AD551295EE for ; Mon, 13 Mar 2017 06:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, 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 YGAgGvEQ_PAP for ; Mon, 13 Mar 2017 06:22:21 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCB5129610 for ; Mon, 13 Mar 2017 06:22:20 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:cca5:d340:c44b:ae82] (unknown [IPv6:2601:648:8301:730f:cca5:d340:c44b:ae82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8E6CEAEB2F; Mon, 13 Mar 2017 14:22:18 +0100 (CET) To: Cullen Jennings References: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> From: Marc Petit-Huguenin Message-ID: <97b83f0a-ee55-5f58-8f29-2f48adaee89e@acm.org> Date: Mon, 13 Mar 2017 06:22:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0qvofldjOwMF62QvWxPfP1tHU5J2WfdxG" Archived-At: Cc: DISPATCH Subject: [dispatch] draft-petithuguenin-dispatch-rtp-pmtud-00 [was Re: draft-petithuguenin-ice-pmtud-00] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:22:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0qvofldjOwMF62QvWxPfP1tHU5J2WfdxG Content-Type: multipart/mixed; boundary="HdQKPO35nAgslua7rXsmPFqU65EIWMpbV"; protected-headers="v1" From: Marc Petit-Huguenin To: Cullen Jennings Cc: DISPATCH Message-ID: <97b83f0a-ee55-5f58-8f29-2f48adaee89e@acm.org> Subject: draft-petithuguenin-dispatch-rtp-pmtud-00 [was Re: [dispatch] draft-petithuguenin-ice-pmtud-00] References: <56353963-c569-711d-c891-7ae901c81cd7@acm.org> <599BE47B-FB71-4D44-A218-D61186D77F89@iii.ca> <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> In-Reply-To: <38cb0611-d307-ab24-1019-747fdcb3765c@acm.org> --HdQKPO35nAgslua7rXsmPFqU65EIWMpbV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just submitted the draft: https://datatracker.ietf.org/doc/draft-petith= uguenin-dispatch-rtp-pmtud/ Comments are welcome. Cullen, you may want to update the DISPATCH agenda with the new name of t= he draft. Thanks. On 03/02/2017 05:20 AM, Marc Petit-Huguenin wrote: > On 03/01/2017 10:00 AM, Cullen Jennings wrote: >> >> So it seems like this would be in scope for TRAM. Would it make sense = to just send it there or do you think we should consider other places for= it? >=20 > The subject of this draft is "How to do PMTUD with RTP" aka "how much v= ideo can I safely stuff in an RTP packet". Using STUN as the mechanism t= o discover the MTU in the path of the RTP packets is not central to this = discussion, but as a transport to collect the packets identifiers (i.e. t= o implement RFC 4821). So it could be AVTCore (or whatever it will be ca= lled after it reabsorbs payload and avtext). We will also need a way to = signal that an endpoint supports that feature and that's a new SDP attrib= ute. So it could be MMUSIC. But maybe getting a larger Path MTU could b= e used to prioritize ICE. So it could be in the ICE WG. But at the end = the only people who will probably care about this stuff are RTCWeb peple,= not SIP people. So maybe WebRTC. Hence going to Dispatch to figure tha= t out. >=20 >> >> >>> On Feb 18, 2017, at 4:46 PM, Marc Petit-Huguenin w= rote: >>> >>> Dear Dispatch, >>> >>> I would like 5 minutes to present draft-petithuguenin-ice-pmtud-00 (n= ot yet published) during the dispatch session. This draft started with t= he ICE specific stuff that was removed from draft-ietf-tram-stun-pmtud-02= , with the goal of defining a usage of stun-pmtud to discover the Path MT= U for an RTP/RTCP session. >>> >>> Thanks. >>> >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --HdQKPO35nAgslua7rXsmPFqU65EIWMpbV-- --0qvofldjOwMF62QvWxPfP1tHU5J2WfdxG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAljGnQkACgkQKcRFldZq fsRE5w/+OElMDpd2zNbhzSarz3V1vQvf1kD+1Kfy+zoqWY1S9/5Yd3dnOrvlPExv kEuHX80BQOB2ZIGjaaQTp1Rd1JWqPIm6gX6MmxNv2tNvtJUPkT4ef+rlUeMkj9QK F2K6Bar6O91FPboElNCkYVrX+yZGsvmX+rcwYxTxmF7qQ6BQvsNFWNzE3KxHPTXb bKIaD3nnP+fpEj793fHqkySpQWNSBNwYSQ06sU8ZM+O8VSf1sRs77gXss4FYvaGZ 3kbghdXdCghKx74eRZun76sGZoopEVvx2LO8jEC3eZ4fcVQ2/KIfdGWmvMhrznEW GMUfMMMANMcOVn0Q7v/clPdTuMga4Dk5A0I7EJns3PBN8KKBx6i1KJ7zjx9PpRAN kqXBoyWyMBm8sZks7Upb4LoOYNh6XqLHDpTKG8949gdaCDDjKQLuQQw/wUqrEWgD LFh+CoRX2cW6odBq7f3RW8DqsOWZYNwycXi/ojASBoRBE1j6gII9EZqxOA2bx0U3 UYVAWZPtJAJJCDFyOxe0VVrtgbZX5Ll9WGU6ZPyB1aarcsrzdXHPzozcyHVIZOIx 1A4iBMw/YJK9zI/0x0U0sVu7q4YowFxsGvIuJCAKDf9It3Wo6/Wobz/xVkt0+LFC QIV0Ophvs3OnUjyI3pkAy3y0Sp3VaIhAv4CYgfxcqY9o19Y/XzE= =7vxx -----END PGP SIGNATURE----- --0qvofldjOwMF62QvWxPfP1tHU5J2WfdxG-- From nobody Sun Mar 19 13:38:40 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 7027F126DFB for ; Sun, 19 Mar 2017 13:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 2URpt-m7Fj0o for ; Sun, 19 Mar 2017 13:38:36 -0700 (PDT) Received: from forward12j.cmail.yandex.net (forward12j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::b2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2BC126C83 for ; Sun, 19 Mar 2017 13:38:35 -0700 (PDT) Received: from mxback2o.mail.yandex.net (mxback2o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1c]) by forward12j.cmail.yandex.net (Yandex) with ESMTP id 21EB020E6A; Sun, 19 Mar 2017 23:38:32 +0300 (MSK) Received: from web30g.yandex.ru (web30g.yandex.ru [95.108.253.239]) by mxback2o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 2s5n3oegWt-cVb8SR7t; Sun, 19 Mar 2017 23:38:31 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1489955911; bh=m2N85HimdCo1fC9h0peWDYKP8zQ63hvCq+EEBEQ8Qs8=; h=From:To:Subject:Message-Id:Date; b=FWo6V6Y5YeCQggiQ0ebxL+s2kV4iQTMBxk53JRGDJg/8rP7hIpT0SaLQQKJc+HmTu 7s8GNSTUzKM48qqiuN6U3MDDLHx4iIA+YEh0iPMuZaVZX7YS7KlEZNCOPauoBHbwuc cHdHwEpR67tEOzsjYRUc5qCuuE8P31tNTG2qXGcs= Authentication-Results: mxback2o.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web30g.yandex.ru with HTTP; Sun, 19 Mar 2017 23:38:31 +0300 From: Anton Tveretin To: DISPATCH list , "R.Jesske@telekom.de" , "Belling, Thomas (Nokia - DE/Munich)" MIME-Version: 1.0 Message-Id: <3049011489955911@web30g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 20 Mar 2017 01:38:31 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] draft-resske-dispatch-reason-loc-q850-00 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: Sun, 19 Mar 2017 20:38:39 -0000 Hello All, Currently, this I-D gives an impression that SS7 is the only telephony, and SIP by itself is some useless crap :) Terms "private network", "local", "remote" etc. are clearly applicable to SIP networks. So I suggest: 1. Explain these terms somewhere in the I-D rather than just refer to ITU. Note somewhat "these terms are consistent with Q.850". 2. Remove all references to the ITU from the abstract. BTW my own I-Ds suffered from similar problem, interworking first, then SIP-only. Regards, Anton. From nobody Mon Mar 20 02:34:19 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 9206A129874 for ; Mon, 20 Mar 2017 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 y69geCKsE_FK for ; Mon, 20 Mar 2017 02:34:15 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0106.outbound.protection.outlook.com [104.47.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA62D12985F for ; Mon, 20 Mar 2017 02:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JVkF3NjEBal0ExPhMxZcMb6xq/mW3+U4Ndjx2lX6e7c=; b=emMrfXf+IgcQGtUk1NypISZu6RxnJzQXIVMzJ345tNbRl0lHDt7ZJj6nBB05vTaPAT1v2TJVwJO1ZN++SBKuKpOfi1Vm15glv2766kNQPEOQ9708fOcEULpfbzwU4QeGbShudQcfPkvCVxOj1GXEqGduCjJpBaIqixpL2+1nPN4= Received: from HE1PR0701MB2395.eurprd07.prod.outlook.com (10.168.128.14) by HE1PR0701MB2395.eurprd07.prod.outlook.com (10.168.128.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 09:34:03 +0000 Received: from HE1PR0701MB2395.eurprd07.prod.outlook.com ([10.168.128.14]) by HE1PR0701MB2395.eurprd07.prod.outlook.com ([10.168.128.14]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 09:34:03 +0000 From: "Belling, Thomas (Nokia - DE/Munich)" To: Anton Tveretin , DISPATCH list , "R.Jesske@telekom.de" Thread-Topic: draft-resske-dispatch-reason-loc-q850-00 Thread-Index: AQHSoPDHNseHuVdJpEaO9tG5Ck8bCKGddH1g Date: Mon, 20 Mar 2017 09:34:03 +0000 Message-ID: References: <3049011489955911@web30g.yandex.ru> In-Reply-To: <3049011489955911@web30g.yandex.ru> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yandex.ru; dkim=none (message not signed) header.d=none;yandex.ru; dmarc=none action=none header.from=nokia.com; x-originating-ip: [131.228.32.175] x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2395; 7:+VvTHfYE3rB9q0vv1qcptCwdxYdFECizEFmMVTbWw4yjkVSd9DFcz1yEaIQQIxyWrgYM7ngvH+h34E/5kXxcs3Ny6XhCVnwpHsCdr2VtDHOiarD2i9Lb9u3fjBvT+uyn5bJ5NKeI4FjX+zN8iciikq3cSfQbSfgWqhPveDVw6yQRPAqZbsAhb8he1QVQ0byqgzcQW5bqLEUS/fMVnHnjO/TbVGa6uOBVwrVoMhdec9fXEKQ+4P2SN6lN6pdO6PMbIDAEAE9frRuwCMTYUCRrBnBcEH3gwhSpdPiIMtVpKdMbgnRk6PXNMzqyNEsv68wigExih9Lm8U4UuagLdFH7fw== x-ms-office365-filtering-correlation-id: 69b140bc-2b2f-4916-73bd-08d46f743f43 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:HE1PR0701MB2395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(144735808701293); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:HE1PR0701MB2395; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2395; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39860400002)(39850400002)(39450400003)(13464003)(377454003)(53754006)(6436002)(6246003)(77096006)(53546008)(38730400002)(102836003)(3846002)(6506006)(122556002)(55016002)(7696004)(99286003)(2950100002)(86362001)(3660700001)(76176999)(50986999)(54356999)(3280700002)(2501003)(25786008)(2906002)(6116002)(229853002)(9686003)(53936002)(33656002)(5660300001)(74316002)(8676002)(8936002)(81166006)(2900100001)(230783001)(305945005)(66066001)(7736002)(189998001)(23180200002)(563744003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2395; H:HE1PR0701MB2395.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 09:34:03.1074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2395 Archived-At: Subject: Re: [dispatch] draft-resske-dispatch-reason-loc-q850-00 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: Mon, 20 Mar 2017 09:34:18 -0000 Dear Anton, Why would you remove ITU from the abstract? The intention is only to encapsulate the ISUP cause location, and this shou= ld be clearly stated in the abstract. And ISUP is defined by ITU-T ... I would not expect that SIP clients send this, only IWFs. But we still need to achieve that the semantics are clear. Regards, Thomas -----Original Message----- From: Anton Tveretin [mailto:tveretinas@yandex.ru]=20 Sent: Sunday, March 19, 2017 9:39 PM To: DISPATCH list ; R.Jesske@telekom.de; Belling, Thomas= (Nokia - DE/Munich) Subject: Re: draft-resske-dispatch-reason-loc-q850-00 Hello All, Currently, this I-D gives an impression that SS7 is the only telephony, and= SIP by itself is some useless crap :) Terms "private network", "local", "r= emote" etc. are clearly applicable to SIP networks. So I suggest: 1. Explain these terms somewhere in the I-D rather than just refer to ITU. = Note somewhat "these terms are consistent with Q.850". 2. Remove all references to the ITU from the abstract. BTW my own I-Ds suffered from similar problem, interworking first, then SIP= -only. Regards, Anton. From nobody Mon Mar 20 20:20:59 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 AEEAB127698; Mon, 20 Mar 2017 20:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 ZYsrc8mqoa1O; Mon, 20 Mar 2017 20:20:57 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 B750D120725; Mon, 20 Mar 2017 20:20:56 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 1so125948408qkl.3; Mon, 20 Mar 2017 20:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kiGFvghBsJMNRyGONl+4caM1Z1GuOdItRVYC95XafhU=; b=nK5f+mJoCNrncMOgGiYljAkMaXqYD+oc7T1NKdi0FGJwHI8E7EOjcZgawbWdVx9ZJa bRzg0D4AR0ZnRfEbR0ANQQeMj8d/sLwE+O2tKU3Jl3qx4jOcsk88hkqXZ7UwHiDGrZ5M IxitaFLj6iS3lMnr+XixB/GxzaDYKM3SgaPUIOzMJMW13TQISuwO0v8gg8w1oZLSspR6 a18L9QOctCuFy9QoweuWapIdVsJBlMRqyZEWNGJd7iqpQONw/C/l+CMhswfAycZqHVFC 5q1PTGQfhfVh7+6Un3JnoCG3U2nJBD1KI/x9PKwlIPsDCgwes7fgn8AQjoNxE/v+Ud9C EKCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kiGFvghBsJMNRyGONl+4caM1Z1GuOdItRVYC95XafhU=; b=Vx/TdZlDBZ40lVimO5siewclNzE10IMopYSurMZvsqVczSNYQyvBDn2H6jh+uJ+tbz HlyMSXcS07n97uDewQ1egxmeebI6dX7BTn/Vobf1O3FY0Ttbquo5laC2wW+1NboYA8Yg kE3MRlzHkWcPjjTfT+1A1C/NxgjbhW7QsstLZUHm1F739I/0dwORL/6XrvZJnewAbnMf f6d2U8KxA+AC/rFhVijXgpHz9zHu0nZOkAV3shIX755Z11zR+yE7I08Ky63B9KMWAfzr e5ITrh+OuePGgpzbk2rVRPDEwYu3cOH6s9Eotzou1oSbfgIB90wYE1TrM4Roht88LrLi I9vA== X-Gm-Message-State: AFeK/H2C8osAeGJ5t4d7g3zIaH2bRS3Peyxe8QFOy552rcOYa51yG7NFXGUpByFrx0MoswpbTSVevCf7ctQukg== X-Received: by 10.233.237.20 with SMTP id c20mr29899182qkg.144.1490066455741; Mon, 20 Mar 2017 20:20:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 20 Mar 2017 20:20:55 -0700 (PDT) From: Martin Thomson Date: Tue, 21 Mar 2017 14:20:55 +1100 Message-ID: To: DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 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, 21 Mar 2017 03:20:59 -0000 This draft would appear to be firmly in the MMUSIC working group remit. I note that the ICE working group defines mechanisms for ICE, and MMUSIC defines SDP. Since this really only uses a mechanism that is defined in TRAM, the only new protocol pieces here are some SDP, which MMUSIC is good at. I see that this is a new -00 draft, so maybe it's just too new to have been discussed. Was it rejected from those groups? On the details, ice-options is a better place to signal this. Drop the abominable x- prefix at the same time. From nobody Mon Mar 20 20:32:29 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 6370B12945E for ; Mon, 20 Mar 2017 20:32:28 -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 (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 GdQH02tOgoBT for ; Mon, 20 Mar 2017 20:32:27 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 EFB7D127698 for ; Mon, 20 Mar 2017 20:32:26 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p64so126156075qke.1 for ; Mon, 20 Mar 2017 20:32:26 -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=ltygavsIuk4uW6E4Sid0CLWNseIOOTh+oRalz7an6eQ=; b=UpS2ACSFOZRBp8TASFDRsO3sPULRdtMN5h6mt+OJc7A/VxyzqX4oMfs7WKkw4EBd0O IZ2vrxEmDbsyKeXHDBpIzv2p1HPNVorvr+4SzBvFja9LeKJUAa9zKwQuFwWHWZGOD08O wZ5dpmJ3hK1rC0K2CQVw3MrWqgJkyFxy3/cPPAJXRLEUEPSqwvBabN77BtA1EvmgWyND DYLjjuBY1SMv497jNUHuybfc3OuX/mEttEnq+KLM9WUaZiP22NhrotcK9yXuccP/g0tE L7eRGkPn8YNEKm0zfn5hgNDpGXM52VNeoZhgEtyme1MIgVpC6iwp1RHNZi42DZ2EdJYd dsrw== 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=ltygavsIuk4uW6E4Sid0CLWNseIOOTh+oRalz7an6eQ=; b=ek6rKR2VBjNWw7wTmXJzvxDEB/NG7FmteeUSCQCowcKD1cFzcA57jSJA4YWpE+zHmQ A07zzfFckVh/A3qXXz3b8w9w68Mu730/paDuPMQhzg96Hreqf7VApCE8/Rga+8sOgcdL MGarHRHNtwB9eVM5Sz+ndy1aBbUOAQmFd0FkYjBuDsPQZdC9Vf7GWtJ1zZvCRG3fiWSn gZz5xQuwTpIxUfP5RyvFQSucHjJKTeW5o/PgpRCNY+rTIQo/bfgoTSgG26FjSBuRu1M+ 13avVLIkbiFvMpBGeSRziP3a98rC4Zj0jxl8Ky+sVmPDWpvfZLO40P0vy4UB00lRtOzF +cDA== X-Gm-Message-State: AFeK/H2Rz/Xb+hif5vq0AY+vCA89Sw0nk3ROM2du6BTy6e6vY6iJbuReQlFauWNYpT5TLElKCjEeR+5IgFw1dg== X-Received: by 10.55.93.68 with SMTP id r65mr27192034qkb.68.1490067146148; Mon, 20 Mar 2017 20:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 20 Mar 2017 20:32:25 -0700 (PDT) In-Reply-To: <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> From: Martin Thomson Date: Tue, 21 Mar 2017 14:32:25 +1100 Message-ID: To: Cullen Jennings Cc: John Levine , DISPATCH list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 21 Mar 2017 03:32:28 -0000 On 11 February 2017 at 07:50, Cullen Jennings wrote: > > The Chairs and ADs discussed this today and we plan to allocate some agenda time for it at IETF 98. At the meeting we can try and figure out best way to dispatch this. I notice that this is on the agenda as simply "DKIM" and all we have is "brief summary of problem - 10 min (John)", which took me a while to latch on to. "Update DKIM Crypto" would be a better title, and John's full name would further help people reading the agenda. If nothing else, this email should help people find this thread again. If I can summarize where I think this left off, we have a desire to improve the strength of the cryptographic algorithms used in DKIM. No one seemed to object to that, but two options came out: 1. Define use of Ed25519 2. Define a modified RSA signature scheme where Sign(k, X) is defined as K || Sign-RSA(k, X) and Verify(H, K || M) is Hash(K) == H && Verify-RSA(K, M) A third option seems plausible as well: do both and let the market decide. I'd be surprised if either were a massive specification effort. In looking at this, we should probably dispatch this cross-area to CURDLE. It might require re-chartering (DKIM isn't explicitly mentioned), but it's a small change. CURDLE might be naturally predisposed to favour the option 1, but I'm sure that the ultimate decision might simply depend on whoever is willing to do the work. From nobody Mon Mar 20 21:01: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 6E190129536 for ; Mon, 20 Mar 2017 21:01:49 -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=nEVaXLLA; dkim=pass (1536-bit key) header.d=taugh.com header.b=kGLjeZoL 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 66kvXnERdato for ; Mon, 20 Mar 2017 21:01:48 -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 B688212951F for ; Mon, 20 Mar 2017 21:01:47 -0700 (PDT) Received: (qmail 49868 invoked from network); 21 Mar 2017 04:01:46 -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=c233.58d0a5aa.k1703; bh=NU98XVQGs0bTM0ljNlJbXLys/ZWwZJ/pasYQzdzbzis=; b=nEVaXLLAPIF3CfVJQrHfOtXS9y26XSz8g6CiD9Qd+owEj5A3vYC4xSItPTPVsxp7o9jw1akOZ4RPtCz+qUmDqaHmUzPfIGwQLu44iRzmQtTcvbMxMsfDctileMIhJpu0hNUEFynGSPYK0i9OD5PAfU52CWWPlg1J8aflRUh0bh/vnqGFjkPCzUPuwBoIKCpUgkYICT66B32SAFiRGdQAaGCFJY/tbxL4FFrDqqb9RKsi54EFO/n5Vc/wnmr+uzjS 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=c233.58d0a5aa.k1703; bh=NU98XVQGs0bTM0ljNlJbXLys/ZWwZJ/pasYQzdzbzis=; b=kGLjeZoL2GER/estLXRs5jTDVwiKsyKgB6BxXLnQ9159kzf9Ezzw+qD6n/4Gc2TFzYUHd/ddBaeJ2ToCvvbNeY+4yMNeNgs6nQQF+6k9sO8k+aUOq0ruR1BrPlRZtuMHEoEz3tOS2c8w+v6HlxNpuFXGtr39JY6eMEP/TOar/iBO9Zl3JNrQJbVpE/rS+9R7l3DZ6CXiPu2/ugWvP1b7g/pePvZJ5k9DZ0DKaaZjSVWrvZcTyWaSkjGENbvLTYJD 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; 21 Mar 2017 04:01:46 -0000 Date: 21 Mar 2017 00:01:46 -0400 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: "DISPATCH list" In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> 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] Updating DKIM for stronger crypto 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, 21 Mar 2017 04:01:49 -0000 > 1. Define use of Ed25519 > 2. Define a modified RSA signature scheme where Sign(k, X) is defined > as K || Sign-RSA(k, X) and Verify(H, K || M) is Hash(K) == H && > Verify-RSA(K, M) Yup, either or both. > In looking at this, we should probably dispatch this cross-area to > CURDLE. Please, no. There's nothing interesting about the choice of algorithms, only about how to update the DKIM spec to say what to do. R's, John From nobody Tue Mar 21 01:51:21 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 7E9451296A5 for ; Tue, 21 Mar 2017 01:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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 (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 7xjVGa0BYQS0 for ; Tue, 21 Mar 2017 01:51:18 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 AEB6D1296A0 for ; Tue, 21 Mar 2017 01:51:18 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p64so129783859qke.1 for ; Tue, 21 Mar 2017 01:51:18 -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=hX6QFo6vR30EzKhgoRkWN3QemTaeKAvGyO5C0LjcRXA=; b=upR9TfltRXuUfq9n/bXcDcqQGz05S4o+aPq8Ycdy/EEPaKDFFPLYZ6npbrvPWbLkga SVnsb+tteHPz8lGcgGkEQeF+fwLKMgvsfQTsglZ4mtwHgAX+5jQLE9qBcmG4T6sg06ju lFCHe7wPeG6fEkM6Opi612CTkshx3VGwBKpeorEd/6rKtt8VA0zGNb9BL3grFzf39Ybz jKJRmtWnV7j+pG2Iq+z4UIR/K/RsHZ30jY4IBlCnlI8dX/+XvZBhyE6feJNVh73DZ2Ym v43/vGMQIpwpbXDLW1Dt4ZEKOUo21x31ieBcx8Yfp8zWkpPIGARSPUizEbqA5KedBY4C 6z5w== 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=hX6QFo6vR30EzKhgoRkWN3QemTaeKAvGyO5C0LjcRXA=; b=FYmJZWUsP/S99+Xu8EkiLWuXYYTaw22cLG+vX/nHY2dqu3EBpab5KvUuWHi4/3ecVz 2+hF8//g6JRhIWn3MzfwLu1Sdn7P6qWh1i3Y/+f7S1D1/kIJGXoeTIl/SVEgkd9BhxwQ g+IHBNe0du1usX/Z+pyhHaSsGRcW63UKw3xbtf6cWBpELghyrNrx9NkdoGLoUSReG/DR 4vb4M9m92LbQtgt1lNE1u58kdg8Zjpp5mhNCXQj2usZ06VLh3cAz/t7iM7FwNQZXainF cXilMkp509DZMbhMSt/siRFa1IXCHjojc3xVPUlUpOPiV7FLsBXVZor8Q9UnrFvpnlVT g3HQ== X-Gm-Message-State: AFeK/H3BQ5J9hS1FO50k6aU2lbAa93+65g+jtJK/N5Z/vdUIVi68yzMafNSnvd4DhjmoFfj64HBYkK5KVuNbEQ== X-Received: by 10.55.43.23 with SMTP id r23mr1995576qkh.147.1490086277932; Tue, 21 Mar 2017 01:51:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 01:51:17 -0700 (PDT) Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 01:51:17 -0700 (PDT) In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> From: Martin Thomson Date: Tue, 21 Mar 2017 19:51:17 +1100 Message-ID: To: John R Levine Cc: DISPATCH Content-Type: multipart/alternative; boundary=001a11493f9a47ed54054b39bfb9 Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 21 Mar 2017 08:51:20 -0000 --001a11493f9a47ed54054b39bfb9 Content-Type: text/plain; charset=UTF-8 On 21 Mar. 2017 15:01, "John R Levine" wrote: In looking at this, we should probably dispatch this cross-area to > CURDLE. > Please, no. There's nothing interesting about the choice of algorithms, only about how to update the DKIM spec to say what to do. That doesn't seem like a good reason. I just spent a few minutes with RFC 6376 and it seems obvious that the changes required are minimal as long as you can conform to the well-established signing API that everyone - including DKIM - uses. You write a new draft that defines a new codepoint and the algorithms that the codepoint represents and that is it. That describes exactly what CURDLE does. Frankly, the process is pretty mechanical, if you want to pad a resume with RFCs, it is a good way to get started. If there is some way in which DKIM really *is* special despite outward appearances, I'd be very interested in hearing about it. Requiring a small public key representation isn't especially interesting or challenging. --001a11493f9a47ed54054b39bfb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0

On 21 Mar. 2017 15:01, "John R Levine" <johnl@taugh.com> wrote:
In looking at this, we should probably dispatch this cross-area to
CURDLE.

Please, no.=C2=A0 There's nothing interesting about the choice of algor= ithms, only about how to update the DKIM spec to say what to do.

That = doesn't seem like a good reason. I just spent a few minutes with RFC 63= 76 and it seems obvious that the changes required are minimal as long as yo= u can conform to the well-established signing API that everyone - including= DKIM - uses. You write a new draft that defines a new codepoint and the al= gorithms that the codepoint represents and that is it.=C2=A0

That describes exactly what CURDLE do= es.=C2=A0 Frankly, the process is pretty mechanical, if you want to pad a r= esume with RFCs, it is a good way to get started.=C2=A0

If there is some way in which DKIM really *= is* special despite outward appearances, I'd be very interested in hear= ing about it. Requiring a small public key representation isn't especia= lly interesting or challenging.
--001a11493f9a47ed54054b39bfb9-- From nobody Tue Mar 21 01:52:26 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 551611296A5 for ; Tue, 21 Mar 2017 01:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 FWqDITfE95js for ; Tue, 21 Mar 2017 01:52:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F53E1296A1 for ; Tue, 21 Mar 2017 01:52:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96F0BBE5B; Tue, 21 Mar 2017 08:52:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAF6S1dmV_7H; Tue, 21 Mar 2017 08:52:18 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 70A3EBE58; Tue, 21 Mar 2017 08:52:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1490086338; bh=Pf4vebQDQs9Iog7B6SnGgE3irV5pnREQf0n63nQSOGE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Bu04q4M4pUb1ZZLNS9RjBry1UBfWLM456oatA0I/iRMGJ58Ur8glcyX6bhIIgxDWf UL0a2Z63C8z6mGStPERFLsxXfzJDeDBbtkXMRkNwAo6Efnqd8Yt4aU8YcJMiySVZtl xnHDLdV4E5BT29PWz/h+WXlogcAYkgVs8J+WBeck= To: Martin Thomson , Cullen Jennings References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> Cc: DISPATCH list , John Levine From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 21 Mar 2017 08:52:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Msf0dPpXnSfxokKPRoSxmH4jgtnlDtmqg" Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 21 Mar 2017 08:52:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Msf0dPpXnSfxokKPRoSxmH4jgtnlDtmqg Content-Type: multipart/mixed; boundary="EtmEq9VM0MI1FWtLGmCnk66HQgWJdVHbp"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , Cullen Jennings Cc: DISPATCH list , John Levine Message-ID: Subject: Re: [dispatch] Updating DKIM for stronger crypto References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> In-Reply-To: --EtmEq9VM0MI1FWtLGmCnk66HQgWJdVHbp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/03/17 03:32, Martin Thomson wrote: > On 11 February 2017 at 07:50, Cullen Jennings wrote: >>=20 >> The Chairs and ADs discussed this today and we plan to allocate >> some agenda time for it at IETF 98. At the meeting we can try and >> figure out best way to dispatch this. >=20 > I notice that this is on the agenda as simply "DKIM" and all we have=20 > is "brief summary of problem - 10 min (John)", which took me a while=20 > to latch on to. "Update DKIM Crypto" would be a better title, and=20 > John's full name would further help people reading the agenda. If=20 > nothing else, this email should help people find this thread again. >=20 > If I can summarize where I think this left off, we have a desire to=20 > improve the strength of the cryptographic algorithms used in DKIM. > No one seemed to object to that, but two options came out: >=20 > 1. Define use of Ed25519=20 > 2. Define a modified RSA signature scheme > where Sign(k, X) is defined as K || Sign-RSA(k, X) and Verify(H, K || > M) is Hash(K) =3D=3D H && Verify-RSA(K, M) >=20 Hmm... WRT #2: I'd be against the idea of defining a mechanism at that level without significant input from CFRG as it'd be re-used if defined at that level so would need some analysis. I guess the idea in #2 is publishing a hashed key in the DNS DKIM key record instead of the key itself and of including the public key in a mail header field, which is a little different (and less scary:-) to how the above is presented. > A third option seems plausible as well: do both and let the market=20 > decide. I'd be surprised if either were a massive specification=20 > effort. I'm not sure letting the market decide here would be a good plan TBH, and I don't think ease of specification ought be a primary consideration. >=20 > In looking at this, we should probably dispatch this cross-area to=20 > CURDLE. It might require re-chartering (DKIM isn't explicitly=20 > mentioned), but it's a small change. CURDLE might be naturally=20 > predisposed to favour the option 1, but I'm sure that the ultimate=20 > decision might simply depend on whoever is willing to do the work. "Ask curdle" does seem like a reasonable approach, but I'd still think it'd be worth considering the topic in dispatch first to get a sense of desired direction, as I don't think those who would write or deploy updated DKIM code tend to participate in curdle today. So first, it'd be good to find out if there's a real appetite/need for updated crypto, or if it's just a nice thing that could be done but that'd not see deployment. Separately, I'd like to raise a different idea wrt DKIM. I don't expect it'll get traction, but no harm to at least raise it here to check... DKIM defines signatures so that a bad or missing signature are treated the same. The expectation in doing that was that DKIM signatures would be ephemeral things, and that public keys might be fairly often replaced using the selector mechanism. Last year, we learned that DKIM signatures can survive exfiltration and other subsequent steps leading to publication via wikileaks and that the same public keys allowing verification were still in use. That was surprising, for me at least. So I wonder if there's any interest in further considering key rollovers in DKIM, and if there's even interest in defining a scheme where old private keys are published, as a means to improve deniability when caches of old emails are subsequently leaked/published. Again, I'd be surprised if this got traction, so I'm not asking for time on the agenda unless the idea has resonated with folks on the list first. (It may also be that I just like the unexpected cuteness of there being potential utility in publishing private signature keys;-) There was a brief thread on the DKIM list about this a while back where the above and a couple of other ideas were mentioned without any of them attracting much interest. [1] Cheers, S. [1] http://mipassoc.org/pipermail/ietf-dkim/2016q4/017197.html >=20 > _______________________________________________ dispatch mailing > list dispatch@ietf.org=20 > https://www.ietf.org/mailman/listinfo/dispatch >=20 --EtmEq9VM0MI1FWtLGmCnk66HQgWJdVHbp-- --Msf0dPpXnSfxokKPRoSxmH4jgtnlDtmqg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY0OnCAAoJEC88hzaAX42iWVsH/A4izmAcYlm5ensKMJS8mBD2 PwQ8ioo+8lQR24WNwiRMIpBsNmMINggsvyR88Jfd28VIbfylShX7Y9+JFsIkwlsu XxwmurtbQcX7oyU0MjcllFJ7Vrh2XBDfkk/K/aPxrPvo+Fo5R1CSIpk0Mckn8GbI EUHevFhH7quACJc9Hj4/q9qFxb7/n8+SzCOiYW74XguKSO3xoIWLXO1wxx5YFgG4 SDrVfTikF9+Nig4o0HdoZghMMftsycpGuSQBdXeGy8AXM+sBPvtpxNx2cOGEQSgT ZHV5KOMYFq95U62lArjECnKR3uiyKxk+TsamNNR+BsKusVOljRqVL320Sdc7SF4= =NK9a -----END PGP SIGNATURE----- --Msf0dPpXnSfxokKPRoSxmH4jgtnlDtmqg-- From nobody Tue Mar 21 03:29:36 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 2C9521296CE; Tue, 21 Mar 2017 03:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 0GCS2YquP2_k; Tue, 21 Mar 2017 03:29:32 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9772F12947D; Tue, 21 Mar 2017 03:29:32 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3d5a:a5f5:d63b:49da] (unknown [IPv6:2601:648:8301:730f:3d5a:a5f5:d63b:49da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6505EAEB2F; Tue, 21 Mar 2017 11:29:27 +0100 (CET) To: Martin Thomson , DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org References: From: Marc Petit-Huguenin Message-ID: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> Date: Tue, 21 Mar 2017 03:29:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4fLmACQluJw9GFFKMQRIu07KhqBf4nfTs" Archived-At: Subject: Re: [dispatch] Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 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, 21 Mar 2017 10:29:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4fLmACQluJw9GFFKMQRIu07KhqBf4nfTs Content-Type: multipart/mixed; boundary="5KfN6kvXsJQ64rP88h0lTaE4ciclPmxp8"; protected-headers="v1" From: Marc Petit-Huguenin To: Martin Thomson , DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org Message-ID: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> Subject: Re: Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 References: In-Reply-To: --5KfN6kvXsJQ64rP88h0lTaE4ciclPmxp8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/20/2017 08:20 PM, Martin Thomson wrote: > This draft would appear to be firmly in the MMUSIC working group > remit. I note that the ICE working group defines mechanisms for ICE, > and MMUSIC defines SDP. Since this really only uses a mechanism that > is defined in TRAM, the only new protocol pieces here are some SDP, > which MMUSIC is good at. Yes. >=20 > I see that this is a new -00 draft, so maybe it's just too new to have > been discussed. Was it rejected from those groups? No, this draft comes from some bits that we removed from draft-ietf-tram-= stun-pmtud when we found out that the usage for RTP (or ICE or whatever) = was too under-defined to be useful. I also see that document as a bluepr= int on how to specify a PMTUD extension to an existing protocol. This is= the first appearance of the idea of doing PMTUD for RTP sessions in this= form. >=20 > On the details, ice-options is a better place to signal this. Drop > the abominable x- prefix at the same time. >=20 I am not sure about the ice-options (I agree with the x- prefix), as an i= ce-options would restricts the signaling to ICE. It's probably safe to s= ay that WebRTC will be the main user of that draft, but may be SIP would = like to use that too without ICE. Hence Dispatch. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --5KfN6kvXsJQ64rP88h0lTaE4ciclPmxp8-- --4fLmACQluJw9GFFKMQRIu07KhqBf4nfTs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAljRAIUACgkQKcRFldZq fsTsjRAAkK1fy0eVeA7NbdKx1TDFIjPVE+Kp1CrLqkGx4cVD8CVyr58s8R8v4vLb t3o7BMZqlkjJxN0/9M+7VyEDDpX+dVYpzGks4ElgEkQGtjKtuujV4IFkQMH8Mn2c TMs4IbJ2NqsM5j2v3SrfdosqbElmW6ZOZWQ0A7A4LW+LyznHDYMjRTSNlxnZTjyy HQtkJXQ7sbnidSjvsse8PsyfHuzf6MqErBbcPKUNob1PccfuLRMsC3zzYYQHVnSr FGhKGK0imSvcIAlqwFjtIJJZFQCZulrhbM6wBoJFSH3mUTR8UrBGlkom7gsVIe1v KPPRFJBhCK+AhUBJyjsrkPLN4hqcNIwndcvJXpvaeofRzxtK1I2NTYYDlosMEFse x9N2BG7RYHQ8PeWtWM9mXr+68sb6bXGi9hI9t5dTdbaUIT37K+/h7rX1/CNFXXkw etyu+ydMgDdgJ+ulYTHyE5Iw7N9tWC2Ov9kwz68HMlDwl5vvrBaNiPgxLQ100Mb/ UC9AItJLVQXUTUh4apM1NiSn9bgyYCuiIXYAZYsxSdI6ARqJwofG0gpiQW2cV3WX iXjEP5sWGqHju8njo4rtSQZo9UNPE575TvbQt1rr7opmYfj3flrU2bQe9t8Zrbms Tiy37w7dtjhrHAMz1rmyzubFp9fSkS3uXfOCTXri8VKACv4TtOs= =JilG -----END PGP SIGNATURE----- --4fLmACQluJw9GFFKMQRIu07KhqBf4nfTs-- From nobody Tue Mar 21 05:20:01 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 5C3D61297C4 for ; Tue, 21 Mar 2017 05:20:00 -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 Ir1JzcQ30TnJ for ; Tue, 21 Mar 2017 05:19:57 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 87DB61297EB for ; Tue, 21 Mar 2017 05:19:57 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p77so108422896ywg.1 for ; Tue, 21 Mar 2017 05:19: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=O+GREiOjMkA5nBJldC++XqA6y1dvpNpVLHPgVWZF/jY=; b=XdDagVUgIjRNPUJyOTB59IbHMgNgq5iV0x+nNGQbDBxlVb/tWkmLmDGTi10RXUWlcY oSjCfUwO0OTpu4M9b60vRPZmvKj6v6wspx35U27RTCAiZ4hxfYqLrlFIGFm20RDWEDXs AAm3goetJg9tP0PCfB2HXuNpdhmGespk0kAtIAW8k7e6H3DIXJ3ohW1/Hn2G4D0QFw/O PhPsAW0WKCp6uzSF91IVfB3mCFVL3gDJbQrYjHmyaCTQMwby+WnzzszKiGncq593GvX/ hBT/i0pn8Koily4KJyLx9imhy65ZlIiWE4ROub7RT0R0LaP6qa58ihAXulE3pP6S8cLf McQA== 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=O+GREiOjMkA5nBJldC++XqA6y1dvpNpVLHPgVWZF/jY=; b=Zsjp6KM7ShUzON8TJC2tXUFKOB+8QgIsCsqh56m8pcQOtPVZmUZK543kufxfc8NR7p iaOd9LA5nF3IRk3u+l8yu04qI8RUpRTwm8Ken0P6vBgSo5kCQ1MOnjO/jdI8o2xE70+b CdLpAR5CUbCImKHko+Vjb/5CM8cgEdNPD15fY2IgvVEh0A0Gcl+AqhFGLgMiJWZytwWL lWEjEg0z4heoAW31IsUK4fy3SrdZueu4Yvb017nt6eaauGPkqkFb8/JqYDkoxMvV4QNs j+wUf01vgfh2p5Eq0QEZNlG0sBYky19seM7D4u+CY9NJI6rkg/lc6+AKyqPVaappLmbg H7qQ== X-Gm-Message-State: AFeK/H3ndqFBV9I0FCLUIIp5NBXMGDKfKsxxNCwGBYIRrLljUk/MOJsMGondlh+iOdiFtsJbckbwmVlhA80DcQ== X-Received: by 10.37.53.138 with SMTP id c132mr22157731yba.105.1490098796704; Tue, 21 Mar 2017 05:19:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 21 Mar 2017 05:19:16 -0700 (PDT) In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> From: Eric Rescorla Date: Tue, 21 Mar 2017 05:19:16 -0700 Message-ID: To: Stephen Farrell Cc: Martin Thomson , Cullen Jennings , DISPATCH list , John Levine Content-Type: multipart/alternative; boundary=001a114bbb32757023054b3ca9e2 Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 21 Mar 2017 12:20:00 -0000 --001a114bbb32757023054b3ca9e2 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 21, 2017 at 1:52 AM, Stephen Farrell wrote: > > Hiya, > > On 21/03/17 03:32, Martin Thomson wrote: > > On 11 February 2017 at 07:50, Cullen Jennings wrote: > >> > >> The Chairs and ADs discussed this today and we plan to allocate > >> some agenda time for it at IETF 98. At the meeting we can try and > >> figure out best way to dispatch this. > > > > I notice that this is on the agenda as simply "DKIM" and all we have > > is "brief summary of problem - 10 min (John)", which took me a while > > to latch on to. "Update DKIM Crypto" would be a better title, and > > John's full name would further help people reading the agenda. If > > nothing else, this email should help people find this thread again. > > > > If I can summarize where I think this left off, we have a desire to > > improve the strength of the cryptographic algorithms used in DKIM. > > No one seemed to object to that, but two options came out: > > > > 1. Define use of Ed25519 > > 2. Define a modified RSA signature scheme > > where Sign(k, X) is defined as K || Sign-RSA(k, X) and Verify(H, K || > > M) is Hash(K) == H && Verify-RSA(K, M) > > > > Hmm... WRT #2: I'd be against the idea of defining a mechanism at > that level without significant input from CFRG as it'd be re-used > if defined at that level so would need some analysis. I guess the > idea in #2 is publishing a hashed key in the DNS DKIM key record > instead of the key itself and of including the public key in a > mail header field, which is a little different (and less scary:-) > to how the above is presented. > Yes. I only described it this way in the interest of explaining how implementations could be updated easily. Note that I have no particular axe to grind in favor of RSA, but to the extent to which your problem with RSA is merely the size of the key in the DNS, then this is the minimal change. In fact, I would argue that if you're going to bother to update the specs at all, you should stuff the hash in the DNS, not the key. > In looking at this, we should probably dispatch this cross-area to > > CURDLE. It might require re-chartering (DKIM isn't explicitly > > mentioned), but it's a small change. CURDLE might be naturally > > predisposed to favour the option 1, but I'm sure that the ultimate > > decision might simply depend on whoever is willing to do the work. > > "Ask curdle" does seem like a reasonable approach, but I'd still > think it'd be worth considering the topic in dispatch first to get > a sense of desired direction, as I don't think those who would > write or deploy updated DKIM code tend to participate in curdle > today. So first, it'd be good to find out if there's a real > appetite/need for updated crypto, or if it's just a nice thing > that could be done but that'd not see deployment. > I am fine with this being DISPATCHed to CURDLE. Less fine with it being DISPATCHed to RFC. -Ekr Separately, I'd like to raise a different idea wrt DKIM. I don't > expect it'll get traction, but no harm to at least raise it here > to check... > > DKIM defines signatures so that a bad or missing signature are > treated the same. The expectation in doing that was that DKIM > signatures would be ephemeral things, and that public keys might > be fairly often replaced using the selector mechanism. Last year, > we learned that DKIM signatures can survive exfiltration and > other subsequent steps leading to publication via wikileaks and > that the same public keys allowing verification were still in use. > > That was surprising, for me at least. So I wonder if there's any > interest in further considering key rollovers in DKIM, and if > there's even interest in defining a scheme where old private keys > are published, as a means to improve deniability when caches of old > emails are subsequently leaked/published. Again, I'd be surprised > if this got traction, so I'm not asking for time on the agenda > unless the idea has resonated with folks on the list first. (It > may also be that I just like the unexpected cuteness of there > being potential utility in publishing private signature keys;-) > > There was a brief thread on the DKIM list about this a while > back where the above and a couple of other ideas were mentioned > without any of them attracting much interest. [1] > > Cheers, > S. > > [1] http://mipassoc.org/pipermail/ietf-dkim/2016q4/017197.html > > > > > _______________________________________________ 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 > > --001a114bbb32757023054b3ca9e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 21, 2017 at 1:52 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 21/03/17 03:32, Martin Thomson wrote:
> On 11 February 2017 at 07:50, Cullen Jennings <fluffy@iii.ca> wrote:
>>
>> The Chairs and ADs discussed this today and we plan to allocate >> some agenda time for it at IETF 98. At the meeting we can try and<= br> >> figure out best way to dispatch this.
>
> I notice that this is on the agenda as simply "DKIM" and all= we have
> is "brief summary of problem - 10 min (John)", which took me= a while
> to latch on to.=C2=A0 "Update DKIM Crypto" would be a better= title, and
> John's full name would further help people reading the agenda.=C2= =A0 If
> nothing else, this email should help people find this thread again. >
> If I can summarize where I think this left off, we have a desire to > improve the strength of the cryptographic algorithms used in DKIM.
> No one seemed to object to that, but two options came out:
>
> 1. Define use of Ed25519
> 2. Define a modified RSA signature scheme
> where Sign(k, X) is defined as K || Sign-RSA(k, X) and Verify(H, K ||<= br> > M) is Hash(K) =3D=3D H && Verify-RSA(K, M)
>

Hmm... WRT #2: I'd be against the idea of defining a mechanism a= t
that level without significant input from CFRG as it'd be re-used
if defined at that level so would need some analysis. I guess the
idea in #2 is publishing a hashed key in the DNS DKIM key record
instead of the key itself and of including the public key in a
mail header field, which is a little different (and less scary:-)
to how the above is presented.

Yes. I o= nly described it this way in the interest of explaining how implementations=
could be updated easily. Note that I have no particular axe to g= rind in favor of
RSA, but to the extent to which your problem wit= h RSA is merely the size of
the key in the DNS, then this is the = minimal change. In fact, I would argue
that if you're going t= o bother to update the specs at all, you should stuff
the hash in= the DNS, not the key.



> In looking at this, we should probably dispatch this cross-area to
> CURDLE.=C2=A0 It might require re-chartering (DKIM isn't explicitl= y
> mentioned), but it's a small change.=C2=A0 CURDLE might be natural= ly
> predisposed to favour the option 1, but I'm sure that the ultimate=
> decision might simply depend on whoever is willing to do the work.

"Ask curdle" does seem like a reasonable approach, but I&#= 39;d still
think it'd be worth considering the topic in dispatch first to get
a sense of desired direction, as I don't think those who would
write or deploy updated DKIM code tend to participate in curdle
today. So first, it'd be good to find out if there's a real
appetite/need for updated crypto, or if it's just a nice thing
that could be done but that'd not see deployment.
=
I am fine with this being DISPATCHed to CURDLE. Less fine wi= th it being
DISPATCHed to RFC.

-Ekr


Separately, I'd like to raise a different idea wrt DKIM. I don't expect it'll get traction, but no harm to at least raise it here
to check...

DKIM defines signatures so that a bad or missing signature are
treated the same. The expectation in doing that was that DKIM
signatures would be ephemeral things, and that public keys might
be fairly often replaced using the selector mechanism. Last year,
we learned that DKIM signatures can survive exfiltration and
other subsequent steps leading to publication via wikileaks and
that the same public keys allowing verification were still in use.

That was surprising, for me at least. So I wonder if there's any
interest in further considering key rollovers in DKIM, and if
there's even interest in defining a scheme where old private keys
are published, as a means to improve deniability when caches of old
emails are subsequently leaked/published. Again, I'd be surprised
if this got traction, so I'm not asking for time on the agenda
unless the idea has resonated with folks on the list first. (It
may also be that I just like the unexpected cuteness of there
being potential utility in publishing private signature keys;-)

There was a brief thread on the DKIM list about this a while
back where the above and a couple of other ideas were mentioned
without any of them attracting much interest. [1]

Cheers,
S.

[1] http://mipassoc.org/pipermail/iet= f-dkim/2016q4/017197.html

>
> _______________________________________________ dispatch mailing<= br> > list dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispat= ch
>


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


--001a114bbb32757023054b3ca9e2-- From nobody Tue Mar 21 06:39:24 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 AFEBA12948A; Tue, 21 Mar 2017 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_PASS=-0.001, 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 hrj_i76XTmBx; Tue, 21 Mar 2017 06:39:20 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA945129488; Tue, 21 Mar 2017 06:39:19 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:3d5a:a5f5:d63b:49da] (unknown [IPv6:2601:648:8301:730f:3d5a:a5f5:d63b:49da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B64E4AEB2F; Tue, 21 Mar 2017 14:39:17 +0100 (CET) To: Martin Thomson , DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org References: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> From: Marc Petit-Huguenin Message-ID: Date: Tue, 21 Mar 2017 06:39:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8xA8da4OFg59RcTUolURBbCqgAAiSinLr" Archived-At: Subject: Re: [dispatch] Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 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, 21 Mar 2017 13:39:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8xA8da4OFg59RcTUolURBbCqgAAiSinLr Content-Type: multipart/mixed; boundary="DrXOajLSkuR2q3V31af8SLmULdXjet4Ws"; protected-headers="v1" From: Marc Petit-Huguenin To: Martin Thomson , DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org Message-ID: Subject: Re: Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 References: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> In-Reply-To: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> --DrXOajLSkuR2q3V31af8SLmULdXjet4Ws Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/21/2017 03:29 AM, Marc Petit-Huguenin wrote: > On 03/20/2017 08:20 PM, Martin Thomson wrote: >> This draft would appear to be firmly in the MMUSIC working group >> remit. I note that the ICE working group defines mechanisms for ICE, >> and MMUSIC defines SDP. Since this really only uses a mechanism that >> is defined in TRAM, the only new protocol pieces here are some SDP, >> which MMUSIC is good at. >=20 > Yes. I withdraw that "yes". It is also about finding the right bytes in all t= he packets exchanged (RTP, RTCP, STUN, even DTLS?) to be able to match th= e list of packets sent with the list of identifiers that will be sent bac= k in the Report response. >=20 >> >> I see that this is a new -00 draft, so maybe it's just too new to have= >> been discussed. Was it rejected from those groups? >=20 > No, this draft comes from some bits that we removed from draft-ietf-tra= m-stun-pmtud when we found out that the usage for RTP (or ICE or whatever= ) was too under-defined to be useful. I also see that document as a blue= print on how to specify a PMTUD extension to an existing protocol. This = is the first appearance of the idea of doing PMTUD for RTP sessions in th= is form. >=20 >> >> On the details, ice-options is a better place to signal this. Drop >> the abominable x- prefix at the same time. >> >=20 > I am not sure about the ice-options (I agree with the x- prefix), as an= ice-options would restricts the signaling to ICE. It's probably safe to= say that WebRTC will be the main user of that draft, but may be SIP woul= d like to use that too without ICE. Hence Dispatch. >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --DrXOajLSkuR2q3V31af8SLmULdXjet4Ws-- --8xA8da4OFg59RcTUolURBbCqgAAiSinLr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAljRLQMACgkQKcRFldZq fsT+QBAAwihx6QajE1HR1KnI5Vno/zvcgSwseePTHEVUvLEIbenxO0k7wE9yjhBG wZi0sP0lLW3r51ZiMxbMgH1fXqKNEkpJCfq8N1bnByAtpFQ+hu0aTm/lFJTT482C 3jx78e6CuMQe4hr7SY6cLStRP+GrlSyR6lKL5YY8vCEOVqF7hcf6dP+c//A4eFd7 8UEAfEZ6JFP/Z3+sg0ZXAQ1XceYeg6rwCmh6Rat7UFcsjO9acdzDJHVq5NJAXxyf YROfCp3XBo/XIqWJUanPrrJR2eJtlkGgqddCXH1oMtYZ99DVbBR6zQGO86EygPqm fbnIyu5JrsKw4dQaz+fOPLPryWxkCp3ZuL5LKNJ5/aAjoyOoomOATeXbRoccpSF7 ITD0zymDbiHG//U8PQ3bBmO/Qrjf2ZrYKSD0O8c5XoeJYnUHAPqnA00baCPA4ldF YlWmOpkP9xFNCZMRpapG+aHC/2ewG3+ZsFOPxzNo1PFD6eUJXzNzawf5R/RY4vci kxgiOSt5XVr0X5VfIlSLeJutMZMeZNlciBta45XzNH8b+VeyUIGrLlpsB12jmgjF Kea9yyeVcofoq7AYXC7EFoQ+cLwtqYnKYf+C4klNjtb76jU7WYV2DEIjpcJA0jn3 7UAMk5cWEfZXYDRgY/IfDD+tktJuycrDieGzPP4aqJQ58ouf988= =VUXx -----END PGP SIGNATURE----- --8xA8da4OFg59RcTUolURBbCqgAAiSinLr-- From nobody Tue Mar 21 07:05:30 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 5420112948B for ; Tue, 21 Mar 2017 07:05:26 -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=w6icEkSf; dkim=pass (1536-bit key) header.d=taugh.com header.b=SeFWiqsy 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 uhMiopBpDIip for ; Tue, 21 Mar 2017 07:05:24 -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 89A7B1200C5 for ; Tue, 21 Mar 2017 07:05:24 -0700 (PDT) Received: (qmail 88478 invoked from network); 21 Mar 2017 14:05:23 -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=1599c.58d13323.k1703; bh=ZCGe9n0J9eHHbFMbnMFwr9BxMMhCVhZwQVUNhp9K9Vk=; b=w6icEkSfL+hjBrBMkeycL8tL1dmXTybfC3lmcTN0rbvL05uYGQagw1cM2GDxZTEgAXqEIepX1BAV/9fIRsK+LqG7NfWMMiR58eJAAY12YNmTzWF5ChWFUgkiZMPxhYYtrh798lNVpeyfFHA79d6ZFOYOGNucx4xUOeMBLUsl3g9Ixpzz+qDCMDl/LIbpoPsI4SZPS8eXxiYjcgDO3Af+e9JRO88CdL6hgF57gXbx5IAUJAJhtu7QWQt7q+0VMgzy 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=1599c.58d13323.k1703; bh=ZCGe9n0J9eHHbFMbnMFwr9BxMMhCVhZwQVUNhp9K9Vk=; b=SeFWiqsyP1XkRZhoKztXbOa10AehmjVBGQr9LAjaNoKGQbnj5zmzx2MjotJfridpOkdmGOavNBftZrXIUl/vqvVXgiu9pirNLiZXF5b3f1ViOw4DO0zwnnN5UNRQRupDPUBPB/M2impac4Z95KfiEJCqsSJ4L1mfWivwz9GgG8zJwCVA1koiperz3Qoj2RBb9t5AgJk1NuegqVWQ7ygstFnLjEGyNPMYuzk6CTRGbgmn1nawVMtlQJNwYcfCvZ8V 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; 21 Mar 2017 14:05:23 -0000 Date: 21 Mar 2017 10:05:22 -0400 Message-ID: From: "John R Levine" To: "DISPATCH list" In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> 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] Updating DKIM for stronger crypto 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, 21 Mar 2017 14:05:26 -0000 > Note that I have no particular axe to grind in favor of > RSA, but to the extent to which your problem with RSA is merely the size of > the key in the DNS, then this is the minimal change. In fact, I would argue > that if you're going to bother to update the specs at all, you should stuff > the hash in the DNS, not the key. Given the difficulty of opening up specs, if we're going to do anything I'd like to both add the new algorithm and the option to publish key hashes. >> Last year, we learned that DKIM signatures can survive exfiltration and >> other subsequent steps leading to publication via wikileaks and that >> the same public keys allowing verification were still in use. This wasn't a surprise to people in the mail ops community. Most signers, even big ones, never rotate their keys, so if you can find an old message, you can probably validate it. Even for people like me who do rotate, large passive DNS databases probably have the old keys. Also, it is my recollection that the signatures weren't so much ephemeral as that they were expected to be checked fairly soon after signing so long-term security wasn't part of the model. If someone wanted to write something about key lifetimes with a way to poison keys by publishing them, that would be OK with me but I wouldn't want to put it into the DKIM spec. Currently it offers no advice on key rotation beyond noting that it's possible, and no useful advice on key sizes. R's, John From nobody Tue Mar 21 07:33:12 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 65DBD129961 for ; Tue, 21 Mar 2017 07:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ZWYazPdRL-3H for ; Tue, 21 Mar 2017 07:33:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4148812995F for ; Tue, 21 Mar 2017 07:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 55366BEB0; Tue, 21 Mar 2017 14:33:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh5X7aPKI8o9; Tue, 21 Mar 2017 14:33:04 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FA80BE38; Tue, 21 Mar 2017 14:32:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1490106779; bh=dvWb3hTPGvQGkT6BDXlU7/JjPMwTI54RZpwx9FqKo/M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RZg/L+coZ+ldWYUsFfQC/1751BV+zMG2ya1h7PKMLN/D8dUV/KmYdqm0V4pro0gf1 GtXEfXLLX1BR9FTdPE81JfdYs/gSXBRBrVqlcIxoFCSiPvk1uVYByHMaNM6KY1+bua z/YrtF2ATOyRNj/9djv7lwoHFWUnijImNJN89mmk= To: John R Levine , DISPATCH list References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <02a5c817-4b7a-0da8-6ad3-e8a5ac1c441e@cs.tcd.ie> Date: Tue, 21 Mar 2017 14:32:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9p4NW6ruEAfvgMvWAEF6VCnKhC35rFeH6" Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 21 Mar 2017 14:33:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9p4NW6ruEAfvgMvWAEF6VCnKhC35rFeH6 Content-Type: multipart/mixed; boundary="eLppIIqHQLApiBcfHEuNEGDBT5Vr8wDgk"; protected-headers="v1" From: Stephen Farrell To: John R Levine , DISPATCH list Message-ID: <02a5c817-4b7a-0da8-6ad3-e8a5ac1c441e@cs.tcd.ie> Subject: Re: [dispatch] Updating DKIM for stronger crypto References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> In-Reply-To: --eLppIIqHQLApiBcfHEuNEGDBT5Vr8wDgk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/03/17 14:05, John R Levine wrote: >=20 > If someone wanted to write something about key lifetimes with a way to > poison keys by publishing them, that would be OK with me but I wouldn't= > want to put it into the DKIM spec. Currently it offers no advice on ke= y > rotation beyond noting that it's possible, and no useful advice on key > sizes. Fully agree - were this to be done it ought be in it's own document. Personally, I'd be willing to help with it, but only if someone was likely to use it. (And so far, nobody is afaik.) S. --eLppIIqHQLApiBcfHEuNEGDBT5Vr8wDgk-- --9p4NW6ruEAfvgMvWAEF6VCnKhC35rFeH6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJY0TmaAAoJEC88hzaAX42iJywIALcpAcQezBhOBsGHd0EBkdRa TFMfPLYoABtFPCgG5fyJyWCHx20Ft/m5OlTsgmcyXXmLSeFCjwowMSrXgUlruwJP 2GHQqFwngnxxuabJeepbKDF6Z4QHmwAfJ2kp3GRIGXk3taXAd3F7FjuBZnaz/1Ee KOJDjB3GCGAiXV3sbxjS450mimHU15f4Nq5G6NOMTxr2e0CYD72ZBv/OAjRl3JDL 2EyNFA7Br5vhbATLtRzUHivPXqHmkzzlh4vFfsZturVZKeGpVXl9SEAicQD51/Sa I6XqiZi+cIsfJUvvaERA39jBzw7mxmUw1pAGJ6w0OtjFMb+yh0o+q1+SBKWzjv8= =AWKF -----END PGP SIGNATURE----- --9p4NW6ruEAfvgMvWAEF6VCnKhC35rFeH6-- From nobody Tue Mar 21 19:09:56 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 F2B7C12940F; Tue, 21 Mar 2017 19:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 qeg2MgyIg-4j; Tue, 21 Mar 2017 19:09:53 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 75D4B1200A0; Tue, 21 Mar 2017 19:09:53 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id x35so144513161qtc.2; Tue, 21 Mar 2017 19:09:53 -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=O3gi1U2df9eXdEVfjDL230WHpi3y2Z6FgwPKesa/CII=; b=L73rp0tHjC0qMyFp2k0vwppC3d4KRdlq4XIH/9Txo6sKXLDPBI8u5CVQeFGMGE9ZsQ 9G11kR7TJU93hGmSBf2fC2ERR9DH1dxYw6dBiOTmWp0RZY+Aoc69Si9sD17cKdpDejh4 9iCGBGFsQ6T6FO2ZRKgyVyf0D/Myn3ODooydvU30/hXMVrpCeze61vtkt4kMp7HB6nIt CYbkKJTvUAqL7cBLxuic1CSCDsFvrx0Th2+C8nNHyraHevn5/6vKAEw1+Hbtz/OntiCu st7Jjnj6rRDA0Gp+CP151/OYFk37Ki8X6/uhOSfzWkMTQ+gjmONXrTJIjwOxpFvfUlRV T3uQ== 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=O3gi1U2df9eXdEVfjDL230WHpi3y2Z6FgwPKesa/CII=; b=m9vWo2yJ7qMOmsmX2GJ+ApNgPPpphX0DQVKlAreZ9KH4lx+/cHTWRVo0xmcMeJggXj TdlvD9ggxR6m6PzHCFeElCYnRDJo7LNNZikBbrcRyKs4ZHmFnbG+evQ0MM1UMFoyRltB fssWLbstAf+9lNgUktO3q9W0WSYFFJ41uiLFYl/DviiH3TYJOOFlWtOaZ9GBFzEShypW xIKvA//ciQ34FI9STFS6A4sf/mRYq39B2Yzd2PzPIoE6Wr53jMQDciyQnv99dfQZsYmb +32fYSQWBAKKKm19vYXI5qTguKiVJ0/MMSHh1cFEN7Nkk+bTEW2CWsaTT/6f1aj0aPjX jiLg== X-Gm-Message-State: AFeK/H37Iw+pvUf+dHh1nZrF98UVeM/i6keB7V/ACtRSG+9uYdYvofN1KsHJ44n7o34WKTLI+uD45YmWXCOhXg== X-Received: by 10.237.34.250 with SMTP id q55mr35729362qtc.144.1490148592602; Tue, 21 Mar 2017 19:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 19:09:52 -0700 (PDT) In-Reply-To: References: <3a0bda90-e20f-73bd-344a-7067d48b38c6@petit-huguenin.org> From: Martin Thomson Date: Wed, 22 Mar 2017 13:09:52 +1100 Message-ID: To: Marc Petit-Huguenin Cc: DISPATCH , draft-petithuguenin-dispatch-rtp-pmtud@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Questions regarding draft-petithuguenin-dispatch-rtp-pmtud-00 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, 22 Mar 2017 02:09:55 -0000 On 22 March 2017 at 00:39, Marc Petit-Huguenin wrote: >> Yes. > > I withdraw that "yes". It is also about finding the right bytes in all the packets exchanged (RTP, RTCP, STUN, even DTLS?) to be able to match the list of packets sent with the list of identifiers that will be sent back in the Report response. Sounds like a good reason not to ask MMUSIC to do this (assuming the other necessary conditions are met). The SDP part becomes minor compared to that. From nobody Tue Mar 21 19:12:35 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 7706C131101 for ; Tue, 21 Mar 2017 19:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 OWRXE7Pyxwla for ; Tue, 21 Mar 2017 19:12:32 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 5EB8F129659 for ; Tue, 21 Mar 2017 19:12:28 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n21so144871650qta.1 for ; Tue, 21 Mar 2017 19:12:28 -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=+MigjAlgmkFWZb7TZig249aefZYcDhgA7x0ouV3jk8A=; b=qQSpsQO9FIS+YhMKnU9BbZBFPwhdRuWnys65eg2MAfYjBUBN9UCPUjcQIWptfPlLkS iCZT5puWdlBg+WwpTeaXr27LUHyLDNVeXk5laXTxOFgR9Pg6n3wSn15edntPtf/0hQqw oG8PbZbpqSBY4dm+Jvt9boECLzMzg//+HcO1R87yCU0vyLKZntQRd2R0Li+SyXyNxBTB JW35VY9u6PSKbWmf1YMI/jIiJuYDV3rcAgqYEZT07qbpTiy7fNIh/Lp+ooiVtLVnQzKn gTArvteTRIeEiz9BocUuwTEweKOw+O0dQ7e5kViav5VagY8yQ2DC1JvKh7vT7/yVqzIp Y/kw== 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=+MigjAlgmkFWZb7TZig249aefZYcDhgA7x0ouV3jk8A=; b=W6ks9XnH+T/KS6dGFFqJK3twz83rCgilDsysylK2QLUCwQa+NAPePDkPuS5KMUdAwR vEiCXeVpq/MNQv9jxUkvjvQHanfKDlI28aVZ1PlNJoCE9202QJSKFN3KfJEqK25S7r5I jwYpW6+IDls7/Q/lD8VdUihD7TurgrCY5P+TzvS8HJqOyyoygO/4P7tblfuFHNFiGB/9 ktVktEN4+8NgeGpexnXeGR+2bP0BrmejzBNuf9DTZlO6chpDADZHl/X6tUdOPMGzWNCQ eK2qqRhQUFiN2dcMsLRiCHddkQ9JVyZvApeCbZHK7LTLkNwm9tPdq4dU7yU9sfHLgqoy rp8w== X-Gm-Message-State: AFeK/H3OLsn87cwr6dSKh49wucWIqeizsFXY/+1jYmFfUV8jcGTnirX1ZkQaDoUPvj2seNrSSSKAOxytMeWWKg== X-Received: by 10.237.41.100 with SMTP id s91mr38465082qtd.143.1490148747603; Tue, 21 Mar 2017 19:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 19:12:27 -0700 (PDT) In-Reply-To: References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> From: Martin Thomson Date: Wed, 22 Mar 2017 13:12:27 +1100 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 22 Mar 2017 02:12:33 -0000 On 22 March 2017 at 01:05, John R Levine wrote: > Given the difficulty of opening up specs, if we're going to do anything I'd > like to both add the new algorithm and the option to publish key hashes. This sounds fine, though I'd disagree with the premise. I'm sure that you can write an extension specification that doesn't even have to update DKIM. It just says, you can implement this in addition to DKIM and it makes the keys bigger and better. From nobody Tue Mar 21 19:32:01 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 439721200A0 for ; Tue, 21 Mar 2017 19:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pi7pNwZBrBOQ for ; Tue, 21 Mar 2017 19:31:57 -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 67BAD12942F for ; Tue, 21 Mar 2017 19:31:57 -0700 (PDT) Received: (qmail 89122 invoked from network); 22 Mar 2017 02:31:55 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Mar 2017 02:31:55 -0000 Date: 22 Mar 2017 02:31:33 -0000 Message-ID: <20170322023133.72699.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org 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] Updating DKIM for stronger crypto 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, 22 Mar 2017 02:31:59 -0000 In article you write: >On 22 March 2017 at 01:05, John R Levine wrote: >> Given the difficulty of opening up specs, if we're going to do anything I'd >> like to both add the new algorithm and the option to publish key hashes. > >This sounds fine, though I'd disagree with the premise. I'm sure that >you can write an extension specification that doesn't even have to >update DKIM. It just says, you can implement this in addition to DKIM >and it makes the keys bigger and better. I suppose but it wouldn't make much sense. We designed DKIM so we can add new hashes and signing algorithms. R's, John From nobody Tue Mar 21 19:38: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 D74AA12702E for ; Tue, 21 Mar 2017 19:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 jVwm2wUYKk0A for ; Tue, 21 Mar 2017 19:38:08 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 309C912942F for ; Tue, 21 Mar 2017 19:38:08 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p22so9404549qka.3 for ; Tue, 21 Mar 2017 19:38:08 -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=vcgbvrjNE+adt++XuMwyT+KzCTnmO/NAQk8f5VqN/y4=; b=Fs2/jNOCIF3SYh47E9xtJFwtMD20lMexo71SsmkJMdVaxm2drVlJ58drRMVrOIixC3 DF99VvGaP+CJsK/2aP3a1bn1qnqDsADzNUN5qf0dfdxal0PFzg/lU9VSs6ABrFfjo42e 6VzEEHWphx5iN3hgDROT6sHMbg9s+SqqAkuNtj/nIxyvhfwjKvMWO7Gh16tuW9PN3GF6 q7xqT60kdX/P8LlKXoP4TmBQ+XbgHYkkFKHZxkxTfds/fhXOoltqujCyFF2xFRcUS/MD awPj82JgEAmU8jRL1nheCmtueL9neVa9cmV+N08NTZYcX3aX4nahawSv3AZfcahYsso7 hA1Q== 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=vcgbvrjNE+adt++XuMwyT+KzCTnmO/NAQk8f5VqN/y4=; b=gwx4ypcWbpDYPGujkwMV2RE3o3T9yWDvdq0iwwxRncBR3M3kuK7tRvMwBMGZt9eLqo zBDguLm6IOh/UichBoGjpOuzxnO+14ImhVO++0NNr7ZNjYMBBqUekfwQSV2zqqrJJHhn MlPol9shK/lDGGhdcn1zbtvNHT5sU4pYEzcxmGDjGZ1bBQ4ku+aW5IJzkLLZUVr12g27 XrYrJ7mPAIDIBe3cVVY0zBoqLCiSnLkro+Y9tbMOjpXfiTTXdWfccCjbvJaVizXexVdY +BWKguOd+20/sRCpan+XhOgEkZXg7TnN622lYdYenZys0txuHgwvC5BGUprRbriG8ghe iqXg== X-Gm-Message-State: AFeK/H2Qs4+0HNrC6VvweWOSnihzV5f5ZhC8fCoFK2jUkkPVOHAxeuZw2YsS7S4Yls3fkk0nd9DlHZprNS/WTA== X-Received: by 10.233.237.130 with SMTP id c124mr118273qkg.144.1490150287398; Tue, 21 Mar 2017 19:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 19:38:06 -0700 (PDT) In-Reply-To: <20170322023133.72699.qmail@ary.lan> References: <20170322023133.72699.qmail@ary.lan> From: Martin Thomson Date: Wed, 22 Mar 2017 13:38:06 +1100 Message-ID: To: John Levine Cc: DISPATCH Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 22 Mar 2017 02:38:10 -0000 On 22 March 2017 at 13:31, John Levine wrote: > We designed DKIM so we can add > new hashes and signing algorithms. Precisely my point. If that was successful (and it seems like it is at least on face value), then a new signing algorithm could be done by basically anyone. From nobody Tue Mar 21 20:05: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 4120012944C for ; Tue, 21 Mar 2017 20:05:55 -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=oBADbr5S; dkim=pass (1536-bit key) header.d=taugh.com header.b=o9RpOscx 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 rlrqd_C3_wBV for ; Tue, 21 Mar 2017 20:05: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 810AC131440 for ; Tue, 21 Mar 2017 20:05:53 -0700 (PDT) Received: (qmail 95520 invoked from network); 22 Mar 2017 03:05:52 -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=1751e.58d1ea10.k1703; bh=61/HgxzJNKKIXnrjuNuKaNJLeCIMBFddcEXR7N4BCdU=; b=oBADbr5S57Z6F9vyt8VU9yxMARs27LpoaJ2rCix2kDI0e9ZNc4DivygIDJjT8YDaLn3t971lzqxwv3QCQz00yMDEwVhP7laD9hjO6nv0XJnxxgMlXwaSBh2j7+u2s6w8Gu4t+etO4tZIJllTK4c1+mL9XV/8lBOe9dZd8WBtmdmdi9+X9NGh6Cy2mtjApswbpiiDMzvXAxFtGoaFHRJfm23hhJ6OjIPaDXOzIIU/a9A6OI6sH7NxLixED4oWHC52 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=1751e.58d1ea10.k1703; bh=61/HgxzJNKKIXnrjuNuKaNJLeCIMBFddcEXR7N4BCdU=; b=o9RpOscxo68ksAAS5tMeP6+biEANsu6w9Ds5SOO3nmC92rkjbr4+Mn2tDB2PehsHY1ncXa/BVBllak+/qOd9QDhf9AR58d0BFxocAsYWttl4+58d41lbhQpCb+TMGCJsB4xRy42FFwJjp9gnqHldZMcDNhkymakNGW4Wi5t6aIuzwjA2ejBtVURXx6KikqYzZd3HNcx0Wvcjx9AazH83Dgpj0Viq6l2UwWm3+vPUcbyVWCfa7LPmiOSlL1ZsVc/s 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; 22 Mar 2017 03:05:52 -0000 Date: 21 Mar 2017 23:05:51 -0400 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: "DISPATCH" In-Reply-To: References: <20170322023133.72699.qmail@ary.lan> 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] Updating DKIM for stronger crypto 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, 22 Mar 2017 03:05:55 -0000 > On 22 March 2017 at 13:31, John Levine wrote: >> We designed DKIM so we can add >> new hashes and signing algorithms. > > Precisely my point. If that was successful (and it seems like it is > at least on face value), then a new signing algorithm could be done by > basically anyone. Of course, but if the signers and verifiers don't agree on how the algorithm is represented in signatures and keys, it won't be very useful. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Mar 22 01:33:48 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 6813E129636 for ; Wed, 22 Mar 2017 01:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rediffmail.com; domainkeys=pass (1024-bit key) header.from=sunilkumarsinha9@rediffmail.com header.sender=sunilkumarsinha9@rediffmail.com header.d=rediffmail.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 z_7XsI_BNzl0 for ; Wed, 22 Mar 2017 01:33:44 -0700 (PDT) Received: from rediffmail.com (f5mail-224-118.rediffmail.com [114.31.224.118]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0289131532 for ; Wed, 22 Mar 2017 01:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rediffmail.com; s=mail; t=1490171617; bh=qHdP232Yr/qMm+IAN7RwMLBYyAVXTB0AVx/hJzmyrk0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=AeZ2oSsF0nVA7oAJk3QHZZNsfvjiumSugp0RausfnxC7erjHLRGLlNZr3xwi165Fp UPO0/gwfah5ZpC0tWWAGWSialxqfWEWjccMaUmr4kmsCNfvVtu3vEx7aDtUHGrgN4d ouQPk4xOBSIsiFd1sWhTmzB+ikCTA2TIn8jgFKQQ= Received: (qmail 2882 invoked by uid 510); 22 Mar 2017 08:33:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=hw5sFnaFq2ZnyGuIsGundvDOoIEyV7kuABmMsdGgP5rW2q6sC/WyakZCE4Q+WW0zsv9aIavUGDXwerDB7kbcqBq6FqV+ILtrKiWzPpc+pPoFbKKPluen1A+dJwsRyQ3N1f7Wo+mT9k/s5u6Nrbp6YjAOes/VoKwkY80WT4y0Ue0= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-OUT-VDRT-SpamState: 0\LEGIT X-OUT-VDRT-SpamScore: 0 X-OUT-VDRT-SpamCause: gggruggvucftvghtrhhoucdtuddrfeelhedrjedtgddufeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecutffgfffkhffhpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepffggvffkjghsuffhtgesrgdtreertddtjeenucfhrhhomhepfdhsuhhnihhluchkuhhmrghruchsihhnhhgrfdcuoehsuhhnihhlkhhumhgrrhhsihhnhhgrleesrhgvughifhhfmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeduvddurddvgeegrdduvdehrddujedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-Remote-IP: 121.244.125.170 X-REDF-OSEN: sunilkumarsinha9@rediffmail.com Date: 22 Mar 2017 08:33:37 -0000 MIME-Version: 1.0 To: Received: from unknown 121.244.125.170 by rediffmail.com via HTTP; 22 Mar 2017 08:33:37 -0000 X-Senderscore: D=0&S=0 Message-ID: <1465853420.S.12274.8910.f5-224-165.1490171617.2672@webmail.rediffmail.com> In-Reply-To: Sender: sunilkumarsinha9@rediffmail.com From: "sunil kumar sinha" Cc: , Content-Type: multipart/alternative; boundary="=_701b465befe7cbb09f41ff3676d30a81" Archived-At: Subject: Re: [dispatch] =?utf-8?q?draft-sunil-sankar-dispatch-sip-incr-00=3A_?= =?utf-8?q?comments_and_question?= 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, 22 Mar 2017 08:33:46 -0000 --=_701b465befe7cbb09f41ff3676d30a81 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Ranjit, I have tried to answer your valuable comments. Please find response inline below. Section 1 1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6. E.g To, From, Call-ID, CSeq, Contact, Max-Forwards and Via. In addition there could be more headers like Content-Type, Content-Length, etc [Answer] Thanks for pointing out blunder mistake. It will be corrected in next version. 2. Instead of jointly - which actually is used for 2 headers and not for many. so you should use the word - together or all of them . [Answer] It will also consider and corrected in next version. 3. Also I don't think the main motivation of providing more headers in a SIP message is to actually find a facility though the actual intent is to better describe the session or indicate support for a certain capability or service and mandate some feature (long list...) [Answer] : Ok 4. Also I do not think we can conclude whether the headers are needed or not before and after session is established. every header that is part of the SIP message has certain significance and it is put if there is a need. so we can not generalize saying that prior to session establishment more headers are needed and after session less. [Answer]: User Agent is free to add header when and wherever it is MUST in the session. Our suggestion is that once the dialog is established, only those optional header(s) will be present in the subsequent request or response whose attribute is changed. It will NOT applicable to seven mandatory headers i.e. To, From, CSeq, Call-ID, Max-Forwards, Via and Contact. 5. if you think it is burden on the bandwidth, the messages can be compressed. [Answer] Correct, compression is one good options. But it will not reduce the number of options headers. Our idea is to keep the minimum number of header after the dialog is established. This is because the larger message size take significantly more CPU cycles and memory for both parsing and producing. Thus, reducing message size would increase through put. At the same time it will also reduce the network burden. Thanks & Regards, Sunil Sinha On Tue, 14 Jun 2016 03:00:20 +0530 Ranjit Avasarala wrote >Hi Sunil my initial comments on this draft Section 1 1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6.  E.g  To, From, Call-ID, CSeq, Contact,     Max-Forwards and Via.  In addition there could be more headers like Content-Type, Content-Length, etc 2. Instead of jointly - which actually is used for 2 headers and not for many.  so you should use the word - together or all of them .3. Also I don't think the main motivation of providing more headers in a SIP message is to actually find a facility though the actual intent is to better     describe the session or indicate support for a certain capability or service and mandate some feature (long list...) 4. Also I do not think we can conclude whether the headers are needed or not before and after session is established.  every header that is part of the    SIP message has certain significance and it is put if there is a need. so we can not generalize saying that prior to session establishment more headers    are needed and after session less.5. if you think it is burden on the bandwidth, the messages can be compressed. More comments as I review ThanksRanjit On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate wrote: Hi, The following are a few comments concerning draft-sunil-sankar-dispatch-sip-incr-00. Thanks, Brett ------ 1) The draft should clarify the relation to SHOULD and MUST within other RFCs concerning header inclusion.  Section 6.1 appears to indicate that you can ignore MUST statements within other RFCs concerning the need to include a specific a header.  However, I'm currently unsure if section 4 next-to-last sentence supports or conflicts with that mandate. 2) You might want to reword section 4 to use normative language. 3) How would this draft interact with RFC 4028 from refresh -versus- deactivation perspective? 4) How would this draft interact with draft-ietf-insipid-session-id since the presence of the Session-ID is to help debug the call flow? 5) You should clarify that transaction specific headers such as Supported, Require, Proxy-Require, and Content-Length need to be included again. _______________________________________________ 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 --=_701b465befe7cbb09f41ff3676d30a81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi Ranjit,

I have tried to answer your valuable comments.
Please find response inline below.


Section 1

1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandato= ry headers and not 6. E.g
To, From, Call-ID, CSeq, Contact, Max-Forwards and Via. In addition there = could be more headers like
Content-Type, Content-Length, etc

[Answer] Thanks for pointing out blunder mistake. It will be corrected in n= ext version.


2. Instead of jointly - which actually is used for 2 headers and not for ma= ny. so you should use the
word - together or all of them .


[Answer] It will also consider and corrected in next version.


3. Also I don't think the main motivation of providing more headers in a SI= P message is to actually
find a facility though the actual intent is to better describe the session = or indicate support for a
certain capability or service and mandate some feature (long list...)

[Answer] : Ok


4. Also I do not think we can conclude whether the headers are needed or no= t before and after session
is established. every header that is part of the SIP message has certain s= ignificance and it is put if
there is a need. so we can not generalize saying that prior to session esta= blishment more headers are
needed and after session less.


[Answer]: User Agent is free to add header when and wherever it is MUST in = the session.

Our suggestion is that once the dialog is established, only those optional = header(s) will be present in
the subsequent request or response whose attribute is changed. It will NOT = applicable to seven
mandatory headers i.e. To, From, CSeq, Call-ID, Max-Forwards, Via and Conta= ct.

5. if you think it is burden on the bandwidth, the messages can be compress= ed.

[Answer] Correct, compression is one good options. But it will not reduce t= he number of options
headers. Our idea is to keep the minimum number of header after the dialog = is established. This is
because the larger message size take significantly more CPU cycles and memo= ry for both parsing and
producing. Thus, reducing message size would increase through put. At the s= ame time it will also reduce
the network burden.


Thanks & Regards,
Sunil Sinha






On Tue, 14 Jun 2016 03:00:20 +0530 Ranjit Avasarala wrote
>Hi Sunil
my initial comments on this draft
Section 1
1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandato= ry headers and not 6.=C2=A0 E.g
=C2=A0To, From, Call-ID, CSeq, Contact,=C2=A0=C2=A0 =C2=A0 Max-Forwards and= Via.=C2=A0 In addition there could be more headers
like Content-Type, Content-Length, etc=C2=A02. Instead of jointly - which a= ctually is used for 2 headers and
not for many. =C2=A0so you should use the word - together or all of them .3= . Also I don't think the main
motivation of providing more headers in a SIP message is to actually find a= facility though the actual
intent is to better=C2=A0=C2=A0 =C2=A0 describe the session or indicate sup= port for a certain capability or service
and mandate some feature (long list...)=C2=A04. Also I do not think we can = conclude whether the headers are
needed or not before and after session is established. =C2=A0every header t= hat is part of the=C2=A0 =C2=A0 SIP message
has certain significance and it is put if there is a need. so we can not ge= neralize saying that prior
to session establishment more headers=C2=A0 =C2=A0 are needed and after ses= sion less.5. if you think it is burden
on the bandwidth, the messages can be compressed.
More comments as I review
ThanksRanjit







On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate wrote: Hi,



The following are a few comments concerning

draft-sunil-sankar-dispatch-sip-incr-00.



Thanks,

Brett



------



1) The draft should clarify the relation to SHOULD and MUST within other
RFCs concerning header inclusion.=C2=A0 Section 6.1 appears to indicate tha= t

you can ignore MUST statements within other RFCs concerning the need to

include a specific a header.=C2=A0 However, I'm currently unsure if section= 4

next-to-last sentence supports or conflicts with that mandate.



2) You might want to reword section 4 to use normative language.



3) How would this draft interact with RFC 4028 from refresh -versus-

deactivation perspective?



4) How would this draft interact with draft-ietf-insipid-session-id since
the presence of the Session-ID is to help debug the call flow?



5) You should clarify that transaction specific headers such as Supported,<= br />
Require, Proxy-Require, and Content-Length need to be included again.



_______________________________________________

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


--=_701b465befe7cbb09f41ff3676d30a81-- From nobody Thu Mar 23 08:57:30 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 6FD50126E3A for ; Thu, 23 Mar 2017 08:57:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 KeUzkolJ8JBy for ; Thu, 23 Mar 2017 08:57:26 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 87BE4126579 for ; Thu, 23 Mar 2017 08:57:26 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id o24so190027161otb.1 for ; Thu, 23 Mar 2017 08:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cHqOhK7M9CFZJNeA+KBWtC1E2b8hrIjS/fX+xlyfYt8=; b=pDKaeqxdVnzOBaq1GAy24EsEJ2IkToL6MuMHq3aDq4PI/6LjkH1iq5bUZ+wFO7Q3cn JdWl1iTfF8DZYSxsqKHayPjm0O/7N5S/FPmY8WmQJ4dovB45o7nIpLLIsQ2uoic/9TDr AYTc2yJFkWLBT84R7mDHLfN751tayccj5do+7GfjQQkzjEBsBvBH9+ZHf+xxpBWU08bA BxlsMEqiysi+vgcHIk0kvriUaATii1wZ+NNu+DErmc3P5e9YhtlSODJJgjYcIj/2kISk oV6MxbtHJmM+p781sKR1JsBGW9ynmdXcWPNoAeiaBwxu9iggS/0YJv1VKvaxvgUvtYei DpRw== 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=cHqOhK7M9CFZJNeA+KBWtC1E2b8hrIjS/fX+xlyfYt8=; b=nvy0jgtKkygZB2xrIkh5RhB4ukC+iQGvHE/IjMcnDSw07bY70wDxcjeJO2usnBAd84 p6UnMQf4iwEoZXWNMhK8FeLMgUXVC9rkPbHJ13SnxcVTsmUzuRIB7reh6j4IYK3e+Y77 oa2F946dEgWkfofxOq1fOj7JQVCt1/WbhHzQ99nzx/ZqjF0tmyBQGLg+BFwnyUfQ3hpH 9qy2Rq7vFGoWBH/+9gD+yt5DU1O/I+++AYFGoRJw37LDXpqvWrAE6k8HKMOQ4EzHF77C MYrsI8BaZqcZtIhYtxhQNLeUjEZ43esZc8TEFwnXLe6MrbGWe6xedisS/1OKh+fpF9wN vVYw== X-Gm-Message-State: AFeK/H1uZWsB/F/JnrFoFcDZt5PLjhYkqiTehI2yZwP8RYYNDu3OW0caIV2Nz5FmhNVdpB/pyYPWM2Xkpz1BWLcE X-Received: by 10.157.57.228 with SMTP id y91mr1891636otb.33.1490284645816; Thu, 23 Mar 2017 08:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.89.206 with HTTP; Thu, 23 Mar 2017 08:57:25 -0700 (PDT) In-Reply-To: <02a5c817-4b7a-0da8-6ad3-e8a5ac1c441e@cs.tcd.ie> References: <20170206020826.1108.qmail@ary.lan> <29F6F66C-F14F-402A-83D4-CAC70841667E@iii.ca> <02a5c817-4b7a-0da8-6ad3-e8a5ac1c441e@cs.tcd.ie> From: Wei Chuang Date: Thu, 23 Mar 2017 08:57:25 -0700 Message-ID: To: Stephen Farrell Cc: John R Levine , DISPATCH list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11406d5af21bfe054b67eefe" Archived-At: Subject: Re: [dispatch] Updating DKIM for stronger crypto 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, 23 Mar 2017 15:57:28 -0000 --001a11406d5af21bfe054b67eefe Content-Type: multipart/alternative; boundary=001a11406d5aedf8e2054b67ee41 --001a11406d5aedf8e2054b67ee41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I think we (Gmail) would be interested in having this update get published. -Wei On Tue, Mar 21, 2017 at 7:32 AM, Stephen Farrell wrote: > > > On 21/03/17 14:05, John R Levine wrote: > > > > If someone wanted to write something about key lifetimes with a way to > > poison keys by publishing them, that would be OK with me but I wouldn't > > want to put it into the DKIM spec. Currently it offers no advice on key > > rotation beyond noting that it's possible, and no useful advice on key > > sizes. > > Fully agree - were this to be done it ought be in it's > own document. Personally, I'd be willing to help with it, > but only if someone was likely to use it. (And so far, > nobody is afaik.) > > S. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a11406d5aedf8e2054b67ee41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I think we (Gmail) would be interested in having this update get published.  

-Wei

On Tue, Mar 21, 2017 at 7:32 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 21/03/17 14:05, John R Levine wrote:
>
> If someone wanted to write something about key lifetimes with a way to
> poison keys by publishing them, that would be OK with me but I wouldn't
> want to put it into the DKIM spec.  Currently it offers no advice on key
> rotation beyond noting that it's possible, and no useful advice on key
> sizes.

Fully agree - were this to be done it ought be in it's
own document. Personally, I'd be willing to help with it,
but only if someone was likely to use it. (And so far,
nobody is afaik.)

S.


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


--001a11406d5aedf8e2054b67ee41-- --001a11406d5af21bfe054b67eefe Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCl/VYXKsSux0IFW7k4HW1A ILj3HN0wUHon3bjCDI4JpDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjMxNTU3MjZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAu0cif3uF91RkhdDfPwsZL5Bn08pLSEL13K1LC9p2 7rpk8LpoEqws/myyLVzZUyH881AVWwo7V0o24mbZJBMWYiorFy6UBghY4TV59n6Y28oBwXGQJczF P9nfaX2sV1dw3hGbEF6E7wpg5aBqr6ekqJwdVc8JXiZk8p25a/ayITmS0u+g9wRPEWH+FWz7F4hy e034eiy8FdlAgJ9KhrHLkHXz6zYvSjn0gChw63xET724F+SZ00hXb7OTf7+Wq3LxmmV4M8Lvq5Eh cagv6aupT4ECl8Nv++ddw/QPrnenVlz7CWJm+D2ssBbfxcAXBJJvYeCR+AUMlrZutSmVixzryg== --001a11406d5af21bfe054b67eefe-- From nobody Mon Mar 27 09:57: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 6BE8612946C for ; Mon, 27 Mar 2017 09:57:35 -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=sADfrdeW; dkim=pass (1536-bit key) header.d=taugh.com header.b=o/3x8bMn 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 bZTL0kV6thfm for ; Mon, 27 Mar 2017 09:57:32 -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 503291293FC for ; Mon, 27 Mar 2017 09:57:23 -0700 (PDT) Received: (qmail 31517 invoked from network); 27 Mar 2017 16:57:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=7b1b.58d94472.k1703; bh=DClC2sDgfpt+ws82ElDN64uziDj5O1tcA1xta4+wSRQ=; b=sADfrdeWBIOkwWC9Z2uDeg3ur/2xRnfpuIRzh5D4KVKudgt8quXuNwsnewgDYwA2wZKx1c8X7aIBp2h7d9pD51DEFsMcUqxTikePrZ8YhHb1vstmUv80DSFr16pklGJQ7O14yGmE2e5Iyw8iAwymsE6B/kN4XrChDk6Q5yoPTVNj2xgYkpZi9CMNpH1euefCWhzd503wS8iHZE2nF3QPU0n3CvZBCj3ZHSUalVW8hL8tdTYS2+bHiRpMnQsQ7iTR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=7b1b.58d94472.k1703; bh=DClC2sDgfpt+ws82ElDN64uziDj5O1tcA1xta4+wSRQ=; b=o/3x8bMnM/4FyiabDMOyxZ4RjI8T4T8cuLaIID1Kw7fgcdf9IoWtGh/6NfVEAB0tkzIPhC3uqt3w2Zj/2Ai6BVcN4ls5LPodKUSa76/Ql2H79c6gxK4FDdpw23CkKLIeSxVZLoQ39j5OWBaGjexkOwIWZT/EAZO3yuwgltovgzw05slk4S4E++WLZM5JBlXnINKimXZaAYbTNLWL65qn/rISNxqIKA7HuUtHFo1R+CceVrP1x18v7hC4KQWAvOEp 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; 27 Mar 2017 16:57:22 -0000 Date: 27 Mar 2017 11:57:20 -0500 Message-ID: From: "John R Levine" To: "DISPATCH list" User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dispatch] Proposed charter for DCRUP 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: Mon, 27 Mar 2017 16:57:35 -0000 The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify 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 two types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM signatures to represent new algorithms or key representations, and to DNS TXT records containing public key information. Milestones: * Adopt draft for new algorithms and key forms * WG last call * Ship it Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 27 10:06:14 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 24F3612702E for ; Mon, 27 Mar 2017 10:06:13 -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 (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 79ik5W8cbKK5 for ; Mon, 27 Mar 2017 10:06:10 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 6B4B5126DCA for ; Mon, 27 Mar 2017 10:06:09 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f11so44228205qkb.0 for ; Mon, 27 Mar 2017 10:06:09 -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=G2/d972d2dxQEyaYu0MtMjENNmWxFOw+6BgE6DV35kM=; b=rvUVCDa/+lXRSDF5SOQoWRd7rzTgaCNAOZ04zCvgirA58UfeVe1Zu5IkmCswkNmeUE FU4gdgEA4nQq2lz8rQ9inx0Tg28lBVQhvA07KIEJEiyVuz0pG1vuFBLcDqVQI9H85H1U 8pXAV6SbHdHSJhANrOdsHFVDt3JKoMTO7d0Ph+XiQvWhua2shQCKupq0f5q6AzgGpdij f+14oJALVWAQO52fJYSv3bzZBbz118bMcPGxglmmYagp0C5bP/t9eYZOsTMtqrqUfSRA rh92S6r+Rdjo4EXxHf6WVs2TI4Vqm/jMZx98NR2TOZiGqpzJ1uGrXRkWzEg/DQUGuS6Y ZMBg== 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=G2/d972d2dxQEyaYu0MtMjENNmWxFOw+6BgE6DV35kM=; b=D+gKQ2EGSO02b/1KLaWD44qFQYzYHFJsP74oeO/F30wyutoAD80xn09VZKJO5NWnQ2 hARWU8RYGFZfaBzf+HwtAl004cNa5AN2FbZBJ05fJqzZMqgjjSNAvwemfsc/02INB0ER vEaYZb4bo2OgIDcCUlP8SjnJ46f7sRgi3vEqzOBJCFk1LBRbp5iXxkOSPEsGzQfvDaRB P+Ltiku3eQqGLD/wZtLTahLUYkqCIS14XW+ItDQeCZ138xncR0UfEz2KElKFgzWaP18J V6GBZRbEGvVqi6t1SvdXUhmv7j9hdh1bWj5OUzJj9jY97iaTe/yaRWKbpyoeaMfPDL7y SCPw== X-Gm-Message-State: AFeK/H3EnEsAGYe3WTn3oRvx3B4moXLFNnMHGdfD17aOz66ZSdyr0U3Ui0reRj9gCDuByOUyDQc2tBU98CBPgQ== X-Received: by 10.55.136.2 with SMTP id k2mr22072726qkd.316.1490634368514; Mon, 27 Mar 2017 10:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 27 Mar 2017 10:06:08 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 27 Mar 2017 12:06:08 -0500 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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: Mon, 27 Mar 2017 17:06:13 -0000 On 27 March 2017 at 11:57, John R Levine wrote: > Ship it ^^ From nobody Mon Mar 27 10:48: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 421FD1293DF for ; Mon, 27 Mar 2017 10:48:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 J_dEkRTe4_Mi for ; Mon, 27 Mar 2017 10:48:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 210221274D0 for ; Mon, 27 Mar 2017 10:48:54 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i203so36999064ywc.3 for ; Mon, 27 Mar 2017 10:48:54 -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=WzvqjFZYA/wChGXwLbs6EmaF1yr48zEZLNSA6xnNsB4=; b=EizwPd0agplHuoKuG2M8NNxv0c7FXHcd8oEVUUIygV1bNM/Cf28WqZqaihxuNHA1gt mawkICwGxh8DrbFy44C1BwwJ9pA7KQDnIxR+xqJPnesRcmC+VGB2UakkFi6FDRXxfP5e B9qG6JGCXxQlFeFGM/QLINzBS36gaGGA9Tk1MbiGfJ16Hht1eRa8TgPm/LYdHoS9SXkN SlkHtaDIDdXwP2Q+pG1X6lYkMI+AFhxSxhTXCEewRN1rlXuPqPBouY+wZVmYmrxJB+86 jf+P9X6rzbKoW+KdjfUVnkz/Pj8CW3NKk746iCzunD1CMoMkbO7Pr+aUiLi2/bIqn7a0 5E3w== 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=WzvqjFZYA/wChGXwLbs6EmaF1yr48zEZLNSA6xnNsB4=; b=RueMzLyf6klM3YWdMrDYtHIIYEfEVidlXhIfRbtG39YHtZSJI9Hz6zuTAy6Wgphvgw LTZF3e6b7FiJBTMixw4q0amItg1BwUu8mlhKSpEIA0rC74qug8/Fe5PAV1IH4dj08ThN SPCi3TpgS2SceWO/BVnojOZ7RVHAYNmCRlcMf8g3yg4tTNVPM3C1tCMU9/oDgbD0iuIb 34xsXqupFILTTAgJIfBWbXebXp25OSk0Esacr9fpGUpTyrUuIoZDtkWrg0jmyGKa2Z1A M1NKhe0UKpI8HGUKTynsU5ldethKMeTEhgdE83Cx9HRCvRZCD94mKqBnQp+2Nf4lBXFx Pv7g== X-Gm-Message-State: AFeK/H2Hcitc8vuZAiztf3QSGSwB7IMQfjHKvFYWdRTSPqxO3lUgPAyTRmfmcXqirf0267Yq76FUwWj7RVAvCw== X-Received: by 10.129.172.23 with SMTP id k23mr18320107ywh.337.1490636933241; Mon, 27 Mar 2017 10:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 27 Mar 2017 10:48:12 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 27 Mar 2017 12:48:12 -0500 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: multipart/alternative; boundary=94eb2c1bae00e53abe054bb9f42c Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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: Mon, 27 Mar 2017 17:48:56 -0000 --94eb2c1bae00e53abe054bb9f42c Content-Type: text/plain; charset=UTF-8 LGTM On Mon, Mar 27, 2017 at 11:57 AM, John R Levine wrote: > The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify > 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 two types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM > signatures to represent new algorithms or key representations, and to DNS > TXT records containing public key information. > > Milestones: > > * Adopt draft for new algorithms and key forms > > * WG last call > > * Ship it > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --94eb2c1bae00e53abe054bb9f42c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LGTM


On Mon, Mar 27, 2017 at 11:57 AM, John R Levine <jo= hnl@taugh.com> wrote:
The D= KIM Crypto Update (DCRUP) working groupkin is chartered to modify DKIM to h= andle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) s= ignatures include a tag that identifies the hash algorithm and signing algo= rithm 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 sig= natures are common, longer signatures are not because bugs in DNS provision= ing software prevent publishing longer keys as DNS TXT records.

DCRUP will consider two types of changes to DKIM: additional signing algori= thms such as those based on elliptic curves, and new public key forms, such= as putting the public key in the signature and a hash of the key in the DN= S.=C2=A0 It will limit itself to existing implemented algorithms and key fo= rms. Other changes to DKIM, such as new message canonicalization schemes, a= re out of scope.

The WG's output will be an update to DKIM describing the changes to DKI= M signatures to represent new algorithms or key representations, and to DNS= TXT records containing public key information.

Milestones:

* Adopt draft for new algorithms and key forms

* WG last call

* Ship it

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

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

--94eb2c1bae00e53abe054bb9f42c-- From nobody Mon Mar 27 15:46:41 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 D42FE1296A4 for ; Mon, 27 Mar 2017 15:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 (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 26TwhZxbBrgt for ; Mon, 27 Mar 2017 15:46:39 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 41FC3129577 for ; Mon, 27 Mar 2017 15:46:37 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id e75so37536605itd.1 for ; Mon, 27 Mar 2017 15:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Vya4lZkR47Ul5TR0NSMr6SGBmDSn3XsWee65+5YI09c=; b=IuHyYgzwNfokKWS8H2AHYy3s7EUYJqBsOMTKpZirkyfpy6gHeNbRRSiisKCMrWY2Z3 J4zUEWHvwpc7gbjDlcWwiAkY0KBY57C5x12ReCPAFXwpmcGpM4hfv9RvfhS1Moz8nR4P SDloj/s9tmMwSoopH+gQQECvaq4hGJRbJdJyPluvMSrN72wpkKAYPStxqL3YJ6mK29e5 z94OQPNO0sJp7eiKKS5S1CtGmqCLCyyiHln45qZPqn/WvycfF2snPVdnECOpIFPpUdad Fh7Yp4zn10XawE3wyuEXaq/KIAzNCDw9vq1pB/92K2HpFiA0L8kgsFA1p7g+1rG6tHaz 8wsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Vya4lZkR47Ul5TR0NSMr6SGBmDSn3XsWee65+5YI09c=; b=HSXicWMUyaQaBPS+hLksAlaiWSSsVtbNND5+ZXBUQmpPpMKLmXSZiSac7dev009oHv H5QIHn2uG/GJHhvrNT6hRe+X3U5fXjzY/g7AxvmTTVbHi8toHZFVMoTxLKicTAFE9kiE G98vsEaoHKIZhkZXBy0cDTYgeT7paxwzdDMv6Yo6b/JC88dcHWxl2JDQYknsmiuCWk/P H4zpdOObBfPRWm7j6It7pW/1Sqxo2kcu1oALV75Az1iHKMhGL5sIY/mO81K44hwOKO8+ PgLm+5xIuY9Rc5H6o9Ze93pa5CGlsM1f/MTJ54+Kjc3gEmnFZ0PqCvLN1Q4QcmcASwqg WXQw== X-Gm-Message-State: AFeK/H2KLIfbVTMUNlfuMo0Lx6+8BNUrJRTwufCcBGILI+NowBd3uxqJRnjGWAgENBPAjHaZij97yg1JHXbqzg== X-Received: by 10.36.213.3 with SMTP id a3mr11652383itg.106.1490654796664; Mon, 27 Mar 2017 15:46:36 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.35.200 with HTTP; Mon, 27 Mar 2017 15:46:36 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Mon, 27 Mar 2017 17:46:36 -0500 X-Google-Sender-Auth: LaZfSVneF6fnjbEoQHiwatxi4BY Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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: Mon, 27 Mar 2017 22:46:41 -0000 =C3=87a marche. Barry On Mon, Mar 27, 2017 at 11:57 AM, John R Levine wrote: > The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify DK= IM > 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 RS= A, > 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 recor= ds. > > DCRUP will consider two types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, and new public key for= ms, > 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 for= ms. > Other changes to DKIM, such as new message canonicalization schemes, are = out > of scope. > > The WG's output will be an update to DKIM describing the changes to DKIM > signatures to represent new algorithms or key representations, and to DNS > TXT records containing public key information. > > Milestones: > > * Adopt draft for new algorithms and key forms > > * WG last call > > * Ship it > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Mar 27 20:02:58 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 83F09127058 for ; Mon, 27 Mar 2017 20:02:56 -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, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 EW0sGEfvGuKU for ; Mon, 27 Mar 2017 20:02:54 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 C3A131292AE for ; Mon, 27 Mar 2017 20:02:54 -0700 (PDT) Received: from dhcp-b9c8.meeting.ietf.org (dhcp-b9c8.meeting.ietf.org [31.133.185.200]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2S32q3G010763 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 27 Mar 2017 20:02:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490670174; bh=pP01PPIk5qyf+I6cOf+SjRwMEbMR3+WdkHUkBSVxDrk=; h=To:From:Subject:Date; b=K/EuSSEyqXyVw2OjwwKo2rVmq3Bi2xDiGbgexGQnMswpRT2ZDiD/mRO02MhJssaqZ OB7r81wTuXhTaAEnMzGMhC5PyrLxRyjs6QxItCQU1egOi1iyAyBUkj7/wt5Evheg8S fZOt9l4kB6TwMLQ/5SG7/nstWAnB2ZvCGMWs++lw= To: dispatch@ietf.org From: Jim Fenton Message-ID: Date: Mon, 27 Mar 2017 20:02:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Possible IPR or DKIM key hashes in DNS 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, 28 Mar 2017 03:02:56 -0000 In this morning's DISPATCH meeting, I didn't intend to scare people away from the idea of putting key hashes in DNS, just to point out that there is a possibly relevant patent. It is: https://www.google.com/patents/US7437558 Hopefully that isn't a problem. -Jim From nobody Mon Mar 27 21:28:26 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 4B671127735 for ; Mon, 27 Mar 2017 21:28:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 h1COkQUWytAG for ; Mon, 27 Mar 2017 21:28:23 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0112.outbound.protection.outlook.com [104.47.93.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96911275C5 for ; Mon, 27 Mar 2017 21:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+X5bp1srS8BbC3BDJfhwCEOppeeXZgvKAK3cSUN0KNo=; b=PufZYiZmf594e/aRvKTTKohbVGgSOY1KX8DSwl+T2tLh/0lyjlROR72botBybsxD/t/52FXYt2yMP6E/ij83dfhz4lHZOhphl5AJKg2hXwRt9J1BUc2Jc+8860rIwsyc8IkZO3HJUUNA2TJ6xIgFrdhuQOl+KnokXqOd0pzKfas= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0653.jpnprd01.prod.outlook.com (10.168.43.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Tue, 28 Mar 2017 04:28:20 +0000 To: John R Levine , DISPATCH list References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Tue, 28 Mar 2017 13:28:18 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0047.jpnprd01.prod.outlook.com (10.164.162.29) To TYXPR01MB0653.jpnprd01.prod.outlook.com (10.168.43.140) X-MS-Office365-Filtering-Correlation-Id: ad7bb83e-2b88-4f1c-f33e-08d47592dd27 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423055)(201703031133061); SRVR:TYXPR01MB0653; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0653; 3:eOTlBrrKL4Ll8rxU/TViNKiy4x6BlLy896NT3z55J85oZaMA9S++SsqBUhfFZMjy6eslI9m38Mhm93xxCvTJ8wEkaOYu2N53i7cw3mcjAXYKG+HN2I8MLIIS5WmeVkeeXBZV2LntyWtNTRDtJTUF/QZ/yavppGFn9gvjXVykCgtT7e5qQ5NcwdrJDOQUWEvV6cypEqHTH+K5bfGrGkzL88N3HltMjh/gx1T4g64Ox/Zj5c3stvmMqQrWbsOkf6TOcBg60EJErC57ns5J85caF9CK63xSl01xg0b9C8tdQDnvBdyj/RikA1aCbmZ74Ism0vLxviZZkpjbmv2g5ZowRA==; 25:QjWY5sJL0nSfLVeAa23Wd0/9RUCCAVSzDPuTEwZsZOI61G0/It9vqAyAU/QDY1ETvHrfQohp5rxUZQJV426TXbf+5zc0fT5OAPqSO+7msPNRAq8DfbWDDyOYV0jC2UDzhgePt9bsg+KxoybzJsujmJXwBqml0riUMfJMPTCpqiSoYE0gjYBQ/9NgQq+mMESRbyWs6i4PWgNzkhcvggQpFLoisBXljm0HNEsNLtxIa+d+OHKaDNTdmusCbQeD12sKZfm8vSYt2f5WqknNKAGinXoExmiT4Vy4j4s/eE+XvuWNbbNpZDrQ4n85Vge6M0E1WTus8ctIH6dad/S+HyQVe06VFyYa7dq1xdr0YJBSGZiegeeuH3IdAx9XC4ReaANX0S1LxXZEkT8/JH1oBbbmEVvH7f9eB0AlVvT2E4rhqniFnSK729+m/Y6S3S6wBPbMJo8LSMB2QWXGSP57m2OIvw== X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0653; 31:LzZnJe/fSiXWtT7I0KYsG72lI298nTmGL7c1Eu4rUMqXGp0P2kdbc7iDKNR9kwDOLqaYmuIyctoRKmCa/g94aoddwgIT5iKoH68TkzVI1jJZL8hdvbV4WwY/fpbG/RX38uzzy+R8AiVV2S+/RXyrTgVwt6Id9Q86Ez1xYRy49dAgCBH9eKOZw4LnB8HRubnWM422nrQUurrs/VQ3GFcQ5v3v8+Z5AfamwaLcUw04rBdh9GGl6HGnT3oRG2yjITsEvko0fULiJDBmoZ5cPMpkew== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040430)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(201703131423055)(201702281528055)(201702281529055)(201703061421054)(201703061406054)(20161123560025)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:TYXPR01MB0653; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0653; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0653; 4:SKOm78ru83WAmVM2k9zOlLYhEo0Eg8rl+qpP0rHC06y5W5UY/2WXY4jFR6SlVWRWxeLpsTqihCvo50S4KgLlNxTcr3S/3OrkjNpCCJMK85lLBw5mSmbnVziTnrmwqP/mk/X9iHNYajvW2E+giwHYgKD5gM3iXLyDqEKQyXqE9+Tlx+yws0EOpsu1dO9wCUzG1RlhYXP4HeVsQ8t6cOQLSZ2M2zWNbq/oCEXfKjTZ1de7g0ueH5Lnd+tRf+mo83oTqKTtW3eR+CegjBgMFCqditrmQJyEXseicrdyIshGfV/IRQynOA6n2a9qAXMTbPpsunPtJmAJdbMw2+yShoOZOKX7x+EOeUFSdp9x4q9FBDC+CzdNRy7NjZtVRxI4fQpOAnZdClJsx+XwtGi/5QE5A7qCw1KUTtAYSiXoHxvdr6tze42+l65y3zv2suC6SVttUotK1bkN1x7KOBGnDGcSqQgrZpEZixdKXPKriswOIcXj4iyAgS0v4FOmBUBHDBfpx+q5qahrpaMRtz/NAZ+1nudB6wbvnYekjIzaThbU5xjhUqq93FYdCCuWRSsIKB40QtJpqCFS9omkSQdp/qQlKjujV0SfRCTmylHeD6bWpJ9LXaDK0FCPfwonOqSxi73vUFIiHMXlamrlj4eDZWxZ8FNaQ7y4oCSqFYXOZLbHAQA2HXEpvVCuFh7yrEgq9PsH3/kNrlHSlwSOIJz09Nnt8Z7zulHr56crfMGGgttPf6y2Q740G6GSvgdne300FmRQJMPxd8cO72QflCByB9DHAQ== X-Forefront-PRVS: 0260457E99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39830400002)(39400400002)(39410400002)(24454002)(377424004)(65826007)(189998001)(65806001)(65956001)(229853002)(5660300001)(33646002)(66066001)(86362001)(7736002)(47776003)(305945005)(4001350100001)(38730400002)(2950100002)(42882006)(83506001)(31696002)(53546009)(25786009)(74482002)(90366009)(23676002)(6246003)(6306002)(3846002)(6116002)(6486002)(50466002)(53936002)(76176999)(8676002)(2906002)(50986999)(31686004)(2870700001)(54356999)(42186005)(81166006)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0653; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwNjUzOzIzOm1hU0dTSVNGM0lPM2dXMmw2ODJmUWx6NWJS?= =?utf-8?B?VGpLZFFDRmp5bGpTRWJ2ZnpEOXpWQTRWSVJMc1pMVHhQUjJ0eTdFcXNLdWRK?= =?utf-8?B?TmZaK0ZFSHl2SWJIR2xUcTFxb1N4aGhyNEsxTGZhcFdNbVdkb2gwY0U2OFJK?= =?utf-8?B?anl1YVVPWFJpalVTNWU1ekdKL055eUYyMDNZK3RuMU8yQmlLN2MrOVdQZHRR?= =?utf-8?B?WGp2bkpwSUlPTUt3aFIyUjEyVHBhUlFNNVVYdk5HRzFOL2VIbUlDb1RjUHlu?= =?utf-8?B?SllaRWpWOTB3MXRySHlUUHZnc0Y4UXhiL0tLZzZtb1ZqeHdPak90anZML201?= =?utf-8?B?UkZUZUdQUEdnY3AxTXNKNFcxWjhGOVcrNVc2REtpTk1zRi9yRmdBUXhkeVFs?= =?utf-8?B?QXI4Y1NUcG5OOG1jYmNxR1U1eEF4RTZRTkFTMDVhakNRKzZxZ0czbzdoMVVw?= =?utf-8?B?ZWlBeGFXWml3M3RuaGwvWlJENzJySDMrT3crempqVTg2ZThqUDIrQy9Bamdq?= =?utf-8?B?eUlvMGNJMlYvNm9kN2d6eDFRT1hhZkw1MzV0NmxlNlcrNjNxM3poZS90M295?= =?utf-8?B?WXE1aU9jdmhJeHhqWmd5OVJJL1VsaWp5ZUdjREd5OWI0WEVXMUJPcFZpSm40?= =?utf-8?B?eHZLcE4vNHlQQnM3MXo2WkhVZGcvbWxENDdnZ1d6M1BZVDlaR3JxYTZ5VXBO?= =?utf-8?B?VTQyalloUVR6REMvZ0FSV3JEZW1ERkoyZmJ0eUFtWWlVcFRwUU9oNk9ITlpw?= =?utf-8?B?T0lQOTErV1Fud0VGdXFuYzVQTjZYNmFJTGszSDFDU3RFSG0xY1FMSjI1QUNM?= =?utf-8?B?ZWJQMG1yRUhRTXd2eXhEczBKOUNSMWxtaDF2RHhQYjg1TGVmL1FsMHd1ZHMw?= =?utf-8?B?UW02NWxsOVRsYlZTVU9VUWFGaEYwSVFGeDlLTXlkdWNBRUNyT255eTBOcXZl?= =?utf-8?B?bkxkTHk2a3FFNFBFMmc3Vm5BdDJYd08xOXNnTUdRZis3andkSXFlVlBLVmlC?= =?utf-8?B?WFd0dFBYakpaNnJSWUUwNTlCK1hBM3pMM2V3TUFjckdxbGZ6UTJKSHViVkt4?= =?utf-8?B?STZMMFpIai9xK2tCbk80UXdQbnVCRDFZYm81WW5HMXQyVlAvWFFIVnlpTENq?= =?utf-8?B?bDh0NXFtczc1aGpJOUpqV005RlN2a1pPbHQ4YnFEMTRIMFZNRk1PQnpVblQ2?= =?utf-8?B?TjN0ZWszWExNdzR4cXh1dndJK2VrbEZPNWl3VXpKSXdwQ3B3UUw5OUs5WDg3?= =?utf-8?B?WElyVEplVzU4a1FCQ21KSkI2YVJBOGF4WmJOSzIyakxoSFJrd2xPc1hlODB3?= =?utf-8?B?VC9oSmtFb1BCQlNFNWx6Y0lSWWtwckFxYTFnMlcrb3RzejF4OHVLS0tBa2VT?= =?utf-8?B?bm01RE45YjMxYUFidktGL0FOU1JDdFJrcGNCRTR0UUdQVnlveFMyU09VRy9G?= =?utf-8?B?K1cwNGJIR25xSjhzYVhwdXBEeHVwMmJvaU4wbTNCWjJGeDhEdjJLaCtUWkVY?= =?utf-8?B?UWp4UlU5U2Yzam5TMnRxWlgyeldYNUVkMWpGMjZWVFlkOGZmZmhiMW1GN293?= =?utf-8?B?eml5STVWbG9lTDUyNGlFWmZBa0lSZ3VFMWdKd041ak5SRURlSzFISWJlcjI3?= =?utf-8?B?dFBoWGFremJRSEF6RXhENFBuV0FJMWUvVEtUVDJFRlk1NWVOVHVSRTd3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0653; 6:DNci6/EOBQTaOzLWaTT3+xukuifWqdg2/KfsGouD6D/39VN8gSjs5bk9VsYl2DS30NzY6fYrIKvuxIelU3r0or+PoZYwgAKM4vH0PGGyZGiuWR9QWsJxoytRiSwhmMrikmLkmpRbGaB5VfZOjtLh0dFwhnw6ckse0tvCYfpTn9JShIZHxguN1zZSX0pfhhc7sBRzZsCHQkwxuehGNiuJtGe5Vv/c7RON/oPtP9a5+XZRNmfRhhhxLUvhuM8yCIwvlLJ+JUAvSdmJHu3ZCpUIY4QWxMxIDxXX02bsJxKwaGuyQjfP+zHlEpOtb2xaYP1tN5WOBrq6rllBPaz2nT6fEplEJn506jH0JgW5DKXbHKjyy7mZ26E1ua2SJZP/3kIRWQHoTtwUo5F2rZ3BEGmHXQ==; 5:xxNfkf6sqf6a2Sl4lQ6LGcMaqY7ureofF/z6mlbTsDDDrdflaA7BfqQ6kbFNLM/XuCTBHVL4KETcnMu0QnWCdm4Jwa7a1W5oLo6cwjkzy7cKepJO1ZXGssw34+v+FwltZEQsDK0uVl1hnlNEgnd9BQ==; 24:hZpZkUKGa3WaHdJs004H8ym+VuZYZZaVIz0cP0kFMJold4aIpklRBVOiHhvvpD0+EIsZaMq1fRq9GKVqH/8i5esFeqwgv6zBYACXD1vwZG4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0653; 7:4NZsvIgswoV8yb77NCD5FMVZ8BJM7Lx6bqXGWXM4VpwY7HK9BflCD3xOHR1xbep/aftnfmkfJX8bt2UscLfd3IROlWOEqhRB630AIo9wGjx0nm3eJJIM4zCaWulGAIpmp7+92NeUXxuVLZotgisWWPBB6Vd+OMhFTzCIgQ9Vynm2eYpERjjJw0M0k63VRTlsu/C1Lm47qchZ08IywBapCokj/vuEYQM7qHcNKLl39p6Ir/drW3GtAy9uEQzCTixnDLHXiX8DJfHVazkGwExhTvaBqHjBW5Mzi0NljqKKq9Y0bKO6fsSIm3ltXDSwLj29Ud3aLTp0vWtzbInV5H4fsQ== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2017 04:28:20.1039 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0653 Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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, 28 Mar 2017 04:28:25 -0000 Ship it, except for "groupkin" -> "group" in the first line. (I'm not in Chicago, so I might have missed a process experiment with groupkins instead of groups; in this case, please ignore my comment.) Regards, Martin. On 2017/03/28 01:57, John R Levine wrote: > The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify > 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 two types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM > signatures to represent new algorithms or key representations, and to > DNS TXT records containing public key information. > > Milestones: > > * Adopt draft for new algorithms and key forms > > * WG last call > > * Ship it > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > . > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Tue Mar 28 08:10:50 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 B817112709D for ; Tue, 28 Mar 2017 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 7jKlsRWSN_V8 for ; Tue, 28 Mar 2017 08:10:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5F24D129450 for ; Tue, 28 Mar 2017 08:10:47 -0700 (PDT) Received: from dhcp-9432.meeting.ietf.org (dhcp-9432.meeting.ietf.org [31.133.148.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2SFAgiM040423 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 28 Mar 2017 10:10:43 -0500 (CDT) (envelope-from adam@nostrum.com) To: Jim Fenton , dispatch@ietf.org References: From: Adam Roach Message-ID: Date: Tue, 28 Mar 2017 10:10:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Possible IPR or DKIM key hashes in DNS 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, 28 Mar 2017 15:10:49 -0000 [as an individual] On 3/27/17 22:02, Jim Fenton wrote: > In this morning's DISPATCH meeting, I didn't intend to scare people away > from the idea of putting key hashes in DNS, just to point out that there > is a possibly relevant patent. It is: > > https://www.google.com/patents/US7437558 > > Hopefully that isn't a problem. Indeed, it would be helpful if someone were to compose an internet draft on this topic so that the patent holder would have an opportunity to make a disclosure. I'll point out that the IPR holder in question has a history of licensing patents related to IETF technologies under terms that are frequently deemed by WG participants to be sufficiently acceptable so as to move forward anyway. For a number of examples, see . /a From nobody Wed Mar 29 13:55:24 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 57B16129982 for ; Wed, 29 Mar 2017 13:55:22 -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=oW8Pkrq8; dkim=pass (1536-bit key) header.d=taugh.com header.b=o5LxCW1a 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 G_azxHg4mpO3 for ; Wed, 29 Mar 2017 13:55:14 -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 CA6C912997C for ; Wed, 29 Mar 2017 13:55:13 -0700 (PDT) Received: (qmail 76948 invoked from network); 29 Mar 2017 20:55:12 -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=12c91.58dc1f30.k1703; bh=NyGm3x5lqu0UpRZpCQhC7SWmzAfBE/3kCFjVIvy8Clw=; b=oW8Pkrq8rCNXRGBuVGBwxeUOpB/5Qnr07arz+5PO/0KL5ILGOjDv8B9qZpFU2e30H1n0jBPZgwNVbcB8EKySQdhVrPbpZXz+6bv9VirrM3qFItaak2me+yfnconXICFuO3RdN55lQrDqlcA+LrL8KilRaN3woPTkDpsuYVtBGnCWCUhfqbERB7cnWz081EbQvLu8/mLcZkKE/HW8QcCkvQl8ov7EDdyfiFa9dnV+tNrtfR0O9nIW50rOnBCWOzYL 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=12c91.58dc1f30.k1703; bh=NyGm3x5lqu0UpRZpCQhC7SWmzAfBE/3kCFjVIvy8Clw=; b=o5LxCW1axcIRVTtDVAXFVywSrLAOabkbAJ9CyKQ0HMgB5D5KC4YN6/knC6BYXWicX7XVW5raotioiUrcnhlIyXzYNaYLH8sTnKNWzERqksFbgsEsTB5TRk4s9anzXVOwzkPzeCMrPtaoeDBnyhC8rzAYQLdrMPBK3hEodQ3oLsqpNkHNyNltbj8uKfQijyGkV5dh6sBywkVTvtjF6ta0Z/Mx64Tdhi1iBj7b6eG+gu1Ue/soKtZZdatQ4Rxhlgrs 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; 29 Mar 2017 20:55:12 -0000 Date: 29 Mar 2017 15:55:11 -0500 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: Re: [dispatch] Draft and Proposed charter for DCRUP 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, 29 Mar 2017 20:55:22 -0000 Here's a draft. It needs a lot of work but it at least mentions all the things I think DCRUP would do. Name: draft-levine-dcrup-dkim-crypto Revision: 00 Title: Cryptographic Update to DKIM Document date: 2017-03-29 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-levine-dcrup-dkim-crypto-00.txt Status: https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/ Htmlized: https://tools.ietf.org/html/draft-levine-dcrup-dkim-crypto-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-levine-dcrup-dkim-crypto-00 ---------- On Mon, 27 Mar 2017, John R Levine wrote: > The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify 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 two types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM > signatures to represent new algorithms or key representations, and to DNS TXT > records containing public key information. > > Milestones: > > * Adopt draft for new algorithms and key forms > > * WG last call > > * Ship it > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Mar 29 20:40:59 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 934E7129546 for ; Wed, 29 Mar 2017 20:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 tQzHw8gKlnzr for ; Wed, 29 Mar 2017 20:40:56 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 18773127286 for ; Wed, 29 Mar 2017 20:40:55 -0700 (PDT) Received: from dhcp-b9c8.meeting.ietf.org (dhcp-b9c8.meeting.ietf.org [31.133.185.200]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2U3erAt013056 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 Mar 2017 20:40:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490845255; bh=e8UYnNyT4dBsrdU96BPJ1ScIpNfat4TYj1hx2yBZKAo=; h=Subject:To:References:From:Date:In-Reply-To; b=bEwqC+BcuP8sPpez3lEzPr2Ei2MKJ95DHJQdWO3P+9aKUcpTQ4ArVILVXJmFjTc+3 iqJXk1sOEG5rrioSE2Ygx5uBUeJzPqFL+ukXW3H8c/d61jlrGZFiHIVmHdRK/aUmMV Fh+j+EUIIFID2L74VgEeA/n7vPZqhB9BrwpuV/x0= To: dispatch@ietf.org References: From: Jim Fenton Message-ID: <1a42c4e1-0e92-d74c-c30f-dc01ad035d46@bluepopcorn.net> Date: Wed, 29 Mar 2017 20:40:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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, 30 Mar 2017 03:40:59 -0000 Yes, and in addition: "chartered to modify DKIM" -> "chartered to update DKIM" (unless there's some specific connotation to "update" in IETF that I'm missing) "The only current algorithm" -> "The only current signing algorithm" -Jim On 3/27/17 9:28 PM, Martin J. Dürst wrote: > Ship it, except for "groupkin" -> "group" in the first line. > > (I'm not in Chicago, so I might have missed a process experiment with > groupkins instead of groups; in this case, please ignore my comment.) > > Regards, Martin. > > On 2017/03/28 01:57, John R Levine wrote: >> The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify >> 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 two types of changes to DKIM: additional signing >> algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM >> signatures to represent new algorithms or key representations, and to >> DNS TXT records containing public key information. >> >> Milestones: >> >> * Adopt draft for new algorithms and key forms >> >> * WG last call >> >> * Ship it >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. >> https://jl.ly >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> . >> > From nobody Thu Mar 30 11:33:42 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 EC784129A1A for ; Thu, 30 Mar 2017 11:33:39 -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, FREEMAIL_FROM=0.001, SPF_PASS=-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 UOKhJodGwA28 for ; Thu, 30 Mar 2017 11:33:31 -0700 (PDT) Received: from forward1p.cmail.yandex.net (forward1p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01BA129A22 for ; Thu, 30 Mar 2017 11:33:28 -0700 (PDT) Received: from mxback5g.mail.yandex.net (mxback5g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:166]) by forward1p.cmail.yandex.net (Yandex) with ESMTP id 64AB020CC4; Thu, 30 Mar 2017 21:33:26 +0300 (MSK) Received: from web20j.yandex.ru (web20j.yandex.ru [5.45.198.61]) by mxback5g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id a0q5FM8JSe-XPla8V9G; Thu, 30 Mar 2017 21:33:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1490898805; bh=8KIHAgs6uV73qISO/lpwBZC9jf8FI8cIrbXfNRCiWus=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=wNDGy1jQNf43I5QCPQR00agsq/myHXcVjqz8t5Fkh4uCgIiGgeM+aRqGTzzN2D7G/ wYuNUnhzSIDklk7YMeWYuZodG5GRpZni9jKeu0Dii9KqpsGipN+u6iVFGzBhiCRJ8S W1zzLRK2Bsj6orinVYIS4guBkQQ7hLgNgCkrkzdA= Authentication-Results: mxback5g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web20j.yandex.ru with HTTP; Thu, 30 Mar 2017 21:33:25 +0300 From: Anton Tveretin To: "Belling, Thomas (Nokia - DE/Munich)" , DISPATCH list , "R.Jesske@telekom.de" In-Reply-To: References: <3049011489955911@web30g.yandex.ru> MIME-Version: 1.0 Message-Id: <2536031490898805@web20j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 30 Mar 2017 23:33:25 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] draft-resske-dispatch-reason-loc-q850-00 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, 30 Mar 2017 18:33:40 -0000 Dear Thomas, I do not agree with you. SIP UA is always a device that belongs to somebody. So it is in either in a public network (licensed), or in a private network, or user equipment. SIP clients would benefit from tracking error. For example, busy or congestion signal (486/600) might come from the called user, from her network, from a transit network (so retrying the call may succeed, if another transit network is chosen), or from caller's network (so all calls might fail). Adding features to SIP just for interworking sounds a little weird. We believe that SIP will at once replace SS7, don't we? Regards, Anton 20.03.2017, 14:34, "Belling, Thomas (Nokia - DE/Munich)" : > Dear Anton, > > Why would you remove ITU from the abstract? > The intention is only to encapsulate the ISUP cause location, and this should be clearly stated in the abstract. > And ISUP is defined by ITU-T ... > I would not expect that SIP clients send this, only IWFs. > But we still need to achieve that the semantics are clear. > > Regards, Thomas > > -----Original Message----- > From: Anton Tveretin [mailto:tveretinas@yandex.ru] > Sent: Sunday, March 19, 2017 9:39 PM > To: DISPATCH list ; R.Jesske@telekom.de; Belling, Thomas (Nokia - DE/Munich) > Subject: Re: draft-resske-dispatch-reason-loc-q850-00 > > Hello All, > Currently, this I-D gives an impression that SS7 is the only telephony, and SIP by itself is some useless crap :) Terms "private network", "local", "remote" etc. are clearly applicable to SIP networks. So I suggest: > 1. Explain these terms somewhere in the I-D rather than just refer to ITU. Note somewhat "these terms are consistent with Q.850". > 2. Remove all references to the ITU from the abstract. > BTW my own I-Ds suffered from similar problem, interworking first, then SIP-only. > Regards, > Anton. From nobody Thu Mar 30 12:01:21 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 79C2B129A6A for ; Thu, 30 Mar 2017 12:01:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ji3wsAmn5Kzj for ; Thu, 30 Mar 2017 12:01:17 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 9703C129A41 for ; Thu, 30 Mar 2017 12:00:53 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z204so66252973vkd.1 for ; Thu, 30 Mar 2017 12:00:53 -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=JhpjJTeykWS7K+GaeZWbCrvPIJea4UBYL3/mUQO/8aU=; b=HxgYxmk+FvFJ02eJ4HtGkL9/bjhCtNVXDNxVRZuDZ+OsAzjI6uSR/RcEqsdqR+whAQ G1Ibeqjr5V8Z6qpvJ634btkjVJ4X6X5FJWwwxcxgvLB4l0g7rip2X/qeEfG4/6rzbD0m XvSB2ovdZj5JHm4mhzV11oszglvUpqKAdHuwQWx339+CCwBP/jJxlxVOS5AqkPQwh20F YPGqhqqV0NaPys1w4sndf2Suy8U62kJaavIfqsfTOInzzy00RiDxHWqX6BnTsz59eZiN 5GEpXv+enVITaoedry+dvjkkdaQ59Xc9OCZJSGry2cJ52GbtKe+psd6jJTgs4O1jTNEp dBvA== 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=JhpjJTeykWS7K+GaeZWbCrvPIJea4UBYL3/mUQO/8aU=; b=r7AX0nZ+RTqnUA7C6vfkAfhYmnSq/bT4OtHWDqPJlag20Sw70RcTcxGifYXPJSr9ve 9qw3/cDoj05CnsqXmxo6kbuNT9y5DDJQ0O4izedr6a9Why9Rrk2iOolOwlpdFg9i02qr JjKjg22d+CHRkHprhwD5GMHfBG5I6NMSVcnXpooD0RXV+dWGfJv3d2QAvQO6SxnSgzGy pidAsyeMhzE/ScZO44oKR/YvVzrrUGI6KLKx7PVQZ/fWXGKP0FvVSFYiUE/wZjZUHT8s +SyxJ71RxSk4uIL5a1PJ//6UOmXQW4xmNH9ZnCg2RcucN4RKjNOSqvA9T0grvq1QTk1D PuTQ== X-Gm-Message-State: AFeK/H1JBsgP4oC2VZH8e6aV5PFnXVagvuct/R0WN13w12Z/kxV1wyZxnqXTlUmG0pkDvorOAlhwVIXuSbPKew== X-Received: by 10.176.92.13 with SMTP id q13mr713423uaf.149.1490900452641; Thu, 30 Mar 2017 12:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Thu, 30 Mar 2017 12:00:52 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 30 Mar 2017 14:00:52 -0500 Message-ID: To: John R Levine Cc: DISPATCH list Content-Type: multipart/alternative; boundary=f40304361416e00f73054bf74f72 Archived-At: Subject: Re: [dispatch] Proposed charter for DCRUP 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, 30 Mar 2017 19:01:19 -0000 --f40304361416e00f73054bf74f72 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 27, 2017 at 11:57 AM, John R Levine wrote: > The DKIM Crypto Update (DCRUP) working groupkin is chartered to modify > 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 two types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, 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's output will be an update to DKIM describing the changes to DKIM > signatures to represent new algorithms or key representations, and to DNS > TXT records containing public key information. > It would be nice to say that the output will be fully backward-compatible with the deployed base, but otherwise looks good. Do we want to say something about discontinuing mandatory support for 512-bit keys in verifiers? -MSK --f40304361416e00f73054bf74f72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 27, 2017 at 11:57 AM, John R Levine <johnl@tau= gh.com> wrote:
The DKIM Crypto Update (DCRUP) wo= rking groupkin is chartered to modify DKIM to handle more modern cryptograp= hic 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 s= ignatures are not because bugs in DNS provisioning software prevent publish= ing longer keys as DNS TXT records.

DCRUP will consider two types of changes to DKIM: additional signing algori= thms such as those based on elliptic curves, and new public key forms, such= as putting the public key in the signature and a hash of the key in the DN= S.=C2=A0 It will limit itself to existing implemented algorithms and key fo= rms. Other changes to DKIM, such as new message canonicalization schemes, a= re out of scope.

The WG's output will be an update to DKIM describing the changes to DKI= M signatures to represent new algorithms or key representations, and to DNS= TXT records containing public key information.

It would be nice to say that the output will be fully backward-com= patible with the deployed base, but otherwise looks good.

Do we want to say something about discontinuing mandatory support for 512-= bit keys in verifiers?

-MSK
--f40304361416e00f73054bf74f72-- From nobody Thu Mar 30 12:37:12 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 CD81A1293D9 for ; Thu, 30 Mar 2017 12:37:09 -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=GaleDqtU; dkim=pass (1536-bit key) header.d=taugh.com header.b=RkRTH9kt 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 0vfR1Intqgpf for ; Thu, 30 Mar 2017 12:37:07 -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 92EC31293F4 for ; Thu, 30 Mar 2017 12:37:07 -0700 (PDT) Received: (qmail 88907 invoked from network); 30 Mar 2017 19:37:06 -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=15b49.58dd5e62.k1703; bh=o3bwYmbpuWb2erBX2YJOVdxxk9ZcPHClKcky9TNWp+0=; b=GaleDqtUIZt/kdVX5EaLUjBf6lWPlnI+mtqQsQGeIjk0iOFNb+nWNxuVFMYlIFfOpH/plWt4Ejz1RP5M5CGxTMnvlOFs0M2uQ1n64koWQAkcVwqSuCE9/3YEqNcTktYT5ZLyhoTl3MSSIZGJEGmZSLXGo5YIzZaCHMGQfjkZa6GYlfVGrrKhX1wsF5R6EuTaG81ml+tMPneqS/hiP0Xzvc2HJwdWWkd5CiE7po7lrIA+R5StdzBT6h82NYnbS1pk 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=15b49.58dd5e62.k1703; bh=o3bwYmbpuWb2erBX2YJOVdxxk9ZcPHClKcky9TNWp+0=; b=RkRTH9ktQrNXM/WVHsKsCJzl76d0T6a+rpS1Z50KRnBRaKhLHO/VNgfDR6icLo6uGBy663bCt6n4/qMBw+6sKNK++OgPezl4zJZVCL72smLggWotwjVKYvH+/RyugcCAhFO8CwCcQCiQJUEd/dGNKoloPj0otkE0Sof6dc7pkFtYo9xteh3mpE+i3Z2pXeWF7y0vCkoU84u4kY/0H9pkAcS8t3ITpndr7K6K9nDizS7++F6kNm51fk0nCV1+MpKh 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; 30 Mar 2017 19:37:06 -0000 Date: 30 Mar 2017 14:37:05 -0500 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.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, 30 Mar 2017 19:37:10 -0000 A few minor changes per recent suggestions: modify -> update, allow deprecation of 512 bit RSA keys, don't be incompatible. 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, 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 Thu Mar 30 12:40:20 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 763E11293F4 for ; Thu, 30 Mar 2017 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 nSXPDgC1yjsM for ; Thu, 30 Mar 2017 12:40:16 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 B31171293EB for ; Thu, 30 Mar 2017 12:40:16 -0700 (PDT) Received: from dhcp-8607.meeting.ietf.org (dhcp-8607.meeting.ietf.org [31.133.134.7]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2UJeE8u025126 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 30 Mar 2017 12:40:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490902816; bh=KdxHqs8F8+rZc/VOzMP4bS/EmCZlnMjpEqHnZhm/dJk=; h=Subject:To:References:From:Date:In-Reply-To; b=IhqIVCsYaLrznfOGQT9O8KKTfYgui4WNmCDwycUrJrpImF3d8/64/J0ElyoNabUzZ WZfnmhwS0301Ro4uNq6qNwYJHJdifQ0uoUB/whR6fOmjeqXDM5foPwR3F78H160M4V wzeAlWKbc/4xsiCMfQ7D/I/EQnF5sH0E9Zar0Y/o= To: dispatch@ietf.org References: From: Jim Fenton Message-ID: <9cfb3a5f-044a-4075-6106-f17e5216ff1e@bluepopcorn.net> Date: Thu, 30 Mar 2017 12:40:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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, 30 Mar 2017 19:40:18 -0000 But still "groupkin"? On 3/30/17 12:37 PM, John R Levine wrote: > A few minor changes per recent suggestions: modify -> update, allow > deprecation of 512 bit RSA keys, don't be incompatible. > > 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, 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. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch