From nobody Fri Oct 14 20:50:52 2016 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C69129409; Fri, 14 Oct 2016 20:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 p9uJoQYC8Kov; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 767741293E1; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9F3oSV1024801; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3swr8h0lH6z7xhk; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Message-ID: <5801A7D0.8050100@tzi.org> Date: Sat, 15 Oct 2016 05:51:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: ace@ietf.org, core@ietf.org, cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF97: DRAFT AGENDA X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 03:50:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF97. Remember that there is still quite some potential for changes. IoT is starting a bit late at IETF97; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). CORE on HOMENET and IPWAVE (Wed) and CORE on ICNRG (Fri) are a bit painful but probably the unavoidable level of conflict. Moves due to other conflict avoidance may make this worse, though. All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten SUNDAY, November 13, 2016 1300-1600 IRTF*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 1330-1530 Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRTF cfrg Crypto Forum Grand BR II OPS v6ops IPv6 Operations WG 1550-1750 Afternoon Session II Grand BR III INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG TUESDAY, November 15, 2016 0930-1200 Morning Session I Grand BR II INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR I TSV quic QUIC WG 1330-1530 Afternoon Session I Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR I RTG rtgarea Routing Area Open Meeting Studio 4 SEC tokbind Token Binding WG Grand BR III TSV tsvwg Transport Area Working Group WG 1550-1820 Afternoon Session II Grand BR II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 Morning Session I Grand BR III OPS anima Autonomic Networking Integrated Model and Approach WG Grand BR II TSV taps Transport Services WG 1110-1210 Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR I TSV tsvwg Transport Area Working Group WG 1330-1500 Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR I INT homenet Home Networking WG Grand BR III INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR II TSV tsvarea Transport Area Open Meeting 1520-1620 Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRTF*** t2trg Thing-to-Thing Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG THURSDAY, November 17, 2016 0930-1100 Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery WG Grand BR II IRTF maprg Measurement and Analysis for Protocols Grand BR I SEC saag Security Area Open Meeting 1110-1210 Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR III INT *** lwig Light-Weight Implementation Guidance WG Grand BR I SEC saag Security Area Open Meeting 1330-1500 Afternoon Session I Studio 3 SEC oauth Web Authorization Protocol WG 1520-1750 Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Environments WG Studio 2 TSV rmcat RTP Media Congestion Avoidance Techniques WG FRIDAY, November 18, 2016 0930-1130 Morning Session I Studio 4 ART *** core Constrained RESTful Environments WG Grand BR II IRTF icnrg Information-Centric Networking Park BR 1 OPS anima Autonomic Networking Integrated Model and Approach WG Park BR 2 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Park BR 1 RTG babel Babel routing protocol WG Studio 4 SEC oauth Web Authorization Protocol WG From nobody Mon Oct 17 12:04:39 2016 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95FA129856; Mon, 17 Oct 2016 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 nN3ulF_dhZuw; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 1C4551297CB; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m138so59524682itm.0; Mon, 17 Oct 2016 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wOnPgxvjYk57wLKis8y/ajAIFeMzqJ5PjDGtGFsRq7o=; b=uNcx4MBVUr26+72sg2plVGwNFVuv3zwmvPzhju/hZFV5Epdl0M1RB2b43ctMpxLpDH U6FD1XBo1KhW3424CGbD2KeWu6VgcQcRYDRInItDgV3S5yJL534ip+gMSBWdHdDsfsrw HVUrirh6O+HR29VMUqyuoJQbidiQg53LbYa97gKUFA8NAA+ESapPSI2QGXcQtYAdBpVW YalHvEvMT1PoECVwFAmbdQXkiY7ZrgjqOwa2xlPiEgUBOt3EJXRARswAUNJ6CaOUzHI7 i0Cl9tsSyPU9UYZ/cXIC+GXSVB/KhDQQh8BuqB6DoaIYgTIIX4AmcwtJp4tqI/i/gDu2 i0ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wOnPgxvjYk57wLKis8y/ajAIFeMzqJ5PjDGtGFsRq7o=; b=Ak2F/3U0KgwYrJthoWHNge4YW66XLFBl4Qw4XQjUCSnslya8aCIy4L1GWQh1NWArjo 2E/PgRn0teHwkdatwYpzLOw9Wc8Ut8qp4loU2KBY7mpjBMoNJAzOstlOdMqEzt26gaxt qU6vd+geWEUgqFPHE5FUsLebI3Nl/M3+wDIJUmr+Rn8rEo9M8DRkPx0//QibxtXVdAX9 P65Y/papzL+SnXkREaItjaN5xbNSnNSxiZgpXk2T6bphQhgIqG4noSXkQKebpQbGgWnN L70NB2EbNCQi6w9phXEqMBHtnkV+KUwJl+Lzp9XYthnmlFEBW5P8Y+D0kMQ3tLzPQEUq Vnew== X-Gm-Message-State: AA6/9Rk49bQC2z1YewpeFiRcYgzQ74G0N+uetvlQpl960i4ZN7VTom8lBKuhWaijLcqH+httNcUkJ+0dZtEu/g== X-Received: by 10.36.90.202 with SMTP id v193mr10047820ita.120.1476731066107; Mon, 17 Oct 2016 12:04:26 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 12:04:25 -0700 (PDT) In-Reply-To: <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com> From: Daniel Migault Date: Mon, 17 Oct 2016 15:04:25 -0400 X-Google-Sender-Auth: nemMv8cefk4u0ovMQy3HsO7MqSE Message-ID: To: "6lo@ietf.org" <6lo@ietf.org>, "dtls-iot@ietf.org" Content-Type: multipart/alternative; boundary=001a1145c51c9fcd5c053f143e67 Archived-At: Cc: Russ Housley , IETF TLS Subject: Re: [Dtls-iot] [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 19:04:30 -0000 --001a1145c51c9fcd5c053f143e67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We are discussing in the TLS wg assignment points for TLS PSK authentication. We would like to understand if there is a specific interest of the IoT community for the following suites. TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; Additional question might be whether AES_256_CCM_8_SHA384 is of interest for an IoT use case. Any feed back is appreciated. please provide them by the end of the week! BR, Daniel On Mon, Oct 17, 2016 at 12:08 PM, Russ Housley wrote= : > I would like to see these included: > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; > > > I am fine with including these as well if someone wants to use them: > > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; > > > I do not really see a reason to include the ones with the shorter MAC: > > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; > > > Russ > > > On Oct 17, 2016, at 12:03 PM, Daniel Migault > wrote: > > Hi, > > I am not clear what the consensus is for the following points. Is there > any consensus for requesting the following ones? > > BR, > Daniel > > TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x01}; > TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x02}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04}; > TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x05}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x06}; > > > > On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson > wrote: > >> I'm mainly just looking to economize on different configurations. >> >> On 9 October 2016 at 16:32, John Mattsson >> wrote: >> > Hi Martin, >> > >> > >> > AES_256_CCM_8 was not in the first versions of the draft but added lat= er >> > after request from IoT people (probably afraid of quantum computers). >> > >> > >> > While I think it makes very much sense to have short tags in wireless >> > radio, I do not know how large need there is for AES-256 in IoT for >> > constrained devices, or how large the need would be to truncate the ta= g >> in >> > these cases. >> > >> > >> > My current understanding is that Grover=E2=80=99s algorithm may never = be more >> > cost-effective than a cluster of classical computers, and that quantum >> > computers therefore likely do not affect the lifetime of AES-128. >> > >> > >> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or >> not. >> > We should not give the impression that AES-256 is needed for practical >> > resistance to quantum computers anytime soon, it is however a >> requirement >> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM see= ms >> > like the best choices in most cases. >> > >> > >> > Cheers, >> > John >> > >> > >> > >> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" < >> tls-bounces@ietf.org >> > on behalf of martin.thomson@gmail.com> wrote: >> > >> >>Looking at those emails, I am prompted to wonder if anyone can justify >> >>the existence of a ciphersuite with a double-sized key and half-sized >> >>authentication tag. RFC 6655 doesn't really explain how that is a >> >>useful thing. >> >> >> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos >> >>wrote: >> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: >> >>>> All, >> >>>> >> >>>> We've received a request for early IANA assignments for the 6 ciphe= r >> >>>> suites listed in https://datatracker.ietf.org/d >> oc/draft-ietf-tls-ecdh >> >>>> e-psk-aead/. Please respond before August 23rd if you have concern= s >> >>>> about early code point assignment for these cipher suites. >> >>> >> >>> I have previously raised an issue [0] on these ciphersuites. The sam= e >> >>> requirement was noted also by Peter Dettman as something special in >> >>> [1]. However, there has been no reaction from the authors (now in CC= ). >> >>> >> >>> regards, >> >>> Nikos >> >>> >> >>> [0]. >> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ >> >>> [1]. >> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds >> >>> >> >>> _______________________________________________ >> >>> TLS mailing list >> >>> TLS@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >>_______________________________________________ >> >>TLS mailing list >> >>TLS@ietf.org >> >>https://www.ietf.org/mailman/listinfo/tls >> > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1145c51c9fcd5c053f143e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We are discussing in the = TLS wg assignment points for TLS PSK authentication. We would like to under= stand if there is a specific interest of the IoT community for the followin= g suites.

TLS_ECDHE_PSK_WITH_AES_128_= CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_= CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04};

= Additional question might be whether AES_256_CCM_8_SHA384 is of interest for an IoT use = case.

Any feed back is appreciated. please provide= them by the end of the week!

BR,
Daniel



On Mon, Oct 17,= 2016 at 12:08 PM, Russ Housley <housley@vigilsec.com> wr= ote:
I would like to see these included:

=
TLS_= ECDHE_PSK_WITH_AES_128_GCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0= ,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384=C2=A0=C2=A0 =3D {0xTB= D; 0xTBD} {0xD0,0x02};

I am fine wi= th including these as well if someone wants to use them:

= TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {= 0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0=C2=A0 =3D {= 0xTBD; 0xTBD} {0xD0,0x06};

I do not= really see a reason to include the ones with the shorter MAC:

TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0= x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0= xD0,0x04};

=
Russ


On Oct 17, 2016, at 12:03 PM, Dani= el Migault <daniel.migault@ericsson.com> wrote:

Hi,

I am not clear what the consensus is fo= r the following points. Is there any consensus for requesting the following= ones?

BR,
Daniel

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA= 256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_2= 56_GCM_SHA384=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE= _PSK_WITH_AES_128_CCM_8_SHA256 =3D {0xTBD; 0xTBD} {0xD0,0x03};
TLS_= ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 =3D {0xTBD; 0xTBD} {0xD0,0x04};TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256=C2=A0=C2=A0 =3D {0xTBD; 0xTBD} = {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384=C2=A0=C2=A0 =3D = {0xTBD; 0xTBD} {0xD0,0x06};


On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
I'm mainly just looking to economize = on different configurations.

On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.com> wrote= :
> Hi Martin,
>
>
> AES_256_CCM_8 was not in the first versions of the draft but added lat= er
> after request from IoT people (probably afraid of quantum computers).<= br> >
>
> While I think it makes very much sense to have short tags in wireless<= br> > radio, I do not know how large need there is for AES-256 in IoT for > constrained devices, or how large the need would be to truncate the ta= g in
> these cases.
>
>
> My current understanding is that Grover=E2=80=99s algorithm may never = be more
> cost-effective than a cluster of classical computers, and that quantum=
> computers therefore likely do not affect the lifetime of AES-128.
>
>
> I do not have any strong opinions regarding keeping AES_256_CCM_8 or n= ot.
> We should not give the impression that AES-256 is needed for practical=
> resistance to quantum computers anytime soon, it is however a requirem= ent
> for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM see= ms
> like the best choices in most cases.
>
>
> Cheers,
> John
>
>
>
> On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-bounces@ietf.org=
> on behalf of martin.thomson@gmail.com> wrote:
>
>>Looking at those emails, I am prompted to wonder if anyone can just= ify
>>the existence of a ciphersuite with a double-sized key and half-siz= ed
>>authentication tag.=C2=A0 RFC 6655 doesn't really explain how t= hat is a
>>useful thing.
>>
>>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@redhat.com>
>>wrote:
>>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>>>> All,
>>>>
>>>> We've received a request for early IANA assignments fo= r the 6 cipher
>>>> suites listed in https://datatr= acker.ietf.org/doc/draft-ietf-tls-ecdh
>>>> e-psk-aead/.=C2=A0 Please respond before August 23rd if yo= u have concerns
>>>> about early code point assignment for these cipher suites.=
>>>
>>> I have previously raised an issue [0] on these ciphersuites. T= he same
>>> requirement was noted also by Peter Dettman as something speci= al in
>>> [1]. However, there has been no reaction from the authors (now= in CC).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0].
>>>https://mailarchive= .ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
>>> [1].
>>>https://mailarchive= .ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/tls=
>>
>>_______________________________________________
>>TLS mailing list
>>TLS@ietf.org<= br> >>https://www.ietf.org/mailman/listinfo/tls<= br> >

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

_______________________________________________
TLS mailing listTLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tls


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


--001a1145c51c9fcd5c053f143e67-- From nobody Sat Oct 22 01:45:42 2016 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C58129440; Sat, 22 Oct 2016 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.699, RCVD_IN_DNSWL_MED=-2.3] 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 IkVMbQZK5nb9; Sat, 22 Oct 2016 01:45:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 C06D41293D6; Sat, 22 Oct 2016 01:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9M8jOf9021213; Sat, 22 Oct 2016 10:45:24 +0200 (CEST) Received: from client-0074.vpn.uni-bremen.de.mail (client-0074.vpn.uni-bremen.de [134.102.107.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3t1GMX3vQYz7xR8; Sat, 22 Oct 2016 10:45:11 +0200 (CEST) Date: Sat, 22 Oct 2016 10:42:20 +0200 From: Carsten Bormann To: cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org, ace@ietf.org, core@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Airmail (390) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="580b270a_37ba36b9_ff73" Archived-At: Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF97: FINAL AGENDA X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 08:45:33 -0000 --580b270a_37ba36b9_ff73 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is my usual eclectic condensed agenda based on the =22=46INAL=22 AGE= NDA for IET=4697. =C2=A0(=22=46INAL=22 historically has not always been =22fi= nal=22...) Not many changes; TOKBIND, OAUTH, CURDLE moved around, and the big clashing cluster on =46riday morning has become bigger with another TLS session. =C2=A0(I previously wrote: IoT is starting a bit late at IET=469= 7; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). =C2=A0CORE on HOMEN= ET and IPWAVE (Wed) and CORE on ICNRG (=46ri) are a bit painful but probably the unavoidable level of conflict.) All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, November 13, 2016 1300-1600 =C2=A0 =C2=A0 =C2=A0 IRT=46*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 ART dispatch Dispatch WG - 09:30-11:00 Studio 3 SEC oauth Web Authorization Protocol WG 1330-1530 =C2=A0Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRT=46 cfrg Crypto =46orum Grand BR 2 OPS v6ops IPv6 Operations WG 1550-1750 =C2=A0Afternoon Session II Grand BR 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG Studio 4 SEC tokbind Token Binding WG TUESDAY, November 15, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR 1 TSV quic QUIC WG 1330-1530 =C2=A0Afternoon Session I Park BR 2 ART httpbis Hypertext Transfer Protocol WG Grand BR 2 RTG rtgarea Routing Area Open Meeting Park BR 1 TSV tsvwg Transport Area Working Group WG 1550-1820 =C2=A0Afternoon Session II Grand BR 2 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes W= G Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 =C2=A0Morning Session I Grand BR 3 OPS anima Autonomic Networking Integrated Model and Approach W= G Grand BR 2 TSV taps Transport Services WG 1110-1210 =C2=A0Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR 1 TSV tsvwg Transport Area Working Group WG 1330-1500 =C2=A0Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 1 INT homenet Home Networking WG Grand BR 3 INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR 2 TSV tsvarea Transport Area Open Meeting 1520-1620 =C2=A0Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRT=46*** t2trg Thing-to-Thing Studio 3 SEC oauth Web Authorization Protocol WG THURSDAY, November 17, 2016 0930-1100 =C2=A0Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery =C2=A0WG= Grand BR 2 IRT=46 maprg Measurement and Analysis for Protocols Grand BR 1 SEC saag Security Area Open Meeting 1110-1210 =C2=A0Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR 3 INT *** lwig Light-Weight Implementation Guidance WG Grand BR 1 SEC saag Security Area Open Meeting 1520-1750 =C2=A0Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Env= ironments WG Studio 3 TSV rmcat RTP Media Congestion Avoidance Techniques WG =46RIDAY, November 18, 2016 0930-1130 =C2=A0Morning Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 3 IRT=46 icnrg Information-Centric Networking Park BR 2 OPS anima Autonomic Networking Integrated Model and Approach WG= Grand BR 2 SEC tls Transport Layer Security WG Studio 4 TSV tcpinc TCP Increased Security WG 1150-1320 =C2=A0Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Studio 4 ART webpush Web-Based Push Notifications WG Park BR 2 RTG babel Babel routing protocol WG Park BR 1 RTG babel Babel routing protocol WG Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG --580b270a_37ba36b9_ff73 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline