Re: [Dots] TLS APLN extension
"Jon Shallow" <supjps-ietf@jpshallow.com> Tue, 29 May 2018 07:42 UTC
Return-Path: <supjps-ietf@jpshallow.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8820D12DA03 for <dots@ietfa.amsl.com>; Tue, 29 May 2018 00:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giFfwhUe7CAB for <dots@ietfa.amsl.com>; Tue, 29 May 2018 00:42:52 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 4C8DD12D869 for <dots@ietf.org>; Tue, 29 May 2018 00:42:52 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from <jon.shallow@jpshallow.com>) id 1fNZHN-00017y-1D; Tue, 29 May 2018 08:42:49 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: "'Konda, Tirumaleswar Reddy'" <TirumaleswarReddy_Konda@mcafee.com>, Benjamin Kaduk <kaduk@mit.edu>, mohamed.boucadair@orange.com, dots@ietf.org
References: <13d301d3f0d8$f66f7c60$e34e7520$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF1E28F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180523003451.GG10597@kduck.kaduk.org> <15bc01d3f26f$fecf3380$fc6d9a80$@jpshallow.com> <BN6PR16MB142569E727B738DA81844E73EA6E0@BN6PR16MB1425.namprd16.prod.outlook.com> <18b001d3f65f$8d47df20$a7d79d60$@jpshallow.com> <BN6PR16MB14254F55D58FD5EE301C6CADEA6E0@BN6PR16MB1425.namprd16.prod.outlook.com> <18d701d3f66a$bfd2dcf0$3f7896d0$@jpshallow.com> <BN6PR16MB1425C4A5A36C10D3F2961038EA6E0@BN6PR16MB1425.namprd16.prod.outlook.com> <192201d3f692$62c4a930$284dfb90$@jpshallow.com> <BN6PR16MB1425A7BC48FD29D05B88E2B6EA6D0@BN6PR16MB1425.namprd16.prod.outlook.com>
In-Reply-To: <BN6PR16MB1425A7BC48FD29D05B88E2B6EA6D0@BN6PR16MB1425.namprd16.prod.outlook.com>
Date: Tue, 29 May 2018 08:42:49 +0100
Message-ID: <196a01d3f720$a44ab550$ece01ff0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF7fY0SEnbbzScVHebrKQTjRWAcaAIi09JrAU1FL/ABpTg7WwITkQo3AlFTTtUCAn+wpwGSMkFzAlhh1J8AmoNr6AJ1YtACpGOMeTA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/qrkFa-kMfzM47PnHaOZc2LBiAoU>
Subject: Re: [Dots] TLS APLN extension
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 07:42:56 -0000
Hi Tiru, Suggested text looks good to me. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 29 May 2018 08:09 To: Jon Shallow; Benjamin Kaduk; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] TLS APLN extension > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Monday, May 28, 2018 8:15 PM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; > Benjamin Kaduk <kaduk@mit.edu>; mohamed.boucadair@orange.com; > dots@ietf.org > Subject: RE: [Dots] TLS APLN extension > > This email originated from outside of the organization. Do not click links or > open attachments unless you recognize the sender and know the content is safe. > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar > Reddy > Sent: 28 May 2018 14:28 > To: Jon Shallow; Benjamin Kaduk; mohamed.boucadair@orange.com; > dots@ietf.org > Subject: Re: [Dots] TLS APLN extension > > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Monday, May 28, 2018 3:31 PM > > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; > > Benjamin Kaduk <kaduk@mit.edu>; mohamed.boucadair@orange.com; > > dots@ietf.org > > Subject: RE: [Dots] TLS APLN extension > > > > This email originated from outside of the organization. Do not click > > links or open attachments unless you recognize the sender and know the > content is safe. > > > > Hi Tiru, > > > > I agree the DOTS server has to send back a "coap" if it receives a > > ALPN request over TCP. Do we need to state this in the Draft? > > No, but I think https://tools.ietf.org/html/draft-ietf-dots-signal-channel- > 19#section-3 needs to point to both > RFC7252 and RFC8323. > > [Jon] Agreed. Are you able to do this with some suitable wrapper text? Proposed text: DOTS signal channel uses the "coaps" URI scheme defined in Section 6 of RFC7252 and "coaps+tcp" URI scheme defined in section 8.2 of RFC 8323 to identify DOTS server resources accessible using CoAP over UDP secured with DTLS and CoAP over TCP secured with TLS. -Tiru > ~Jon > > Cheers, > -Tiru > > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > Tirumaleswar Reddy > > Sent: 28 May 2018 10:49 > > To: Jon Shallow; Benjamin Kaduk; mohamed.boucadair@orange.com; > > dots@ietf.org > > Subject: Re: [Dots] TLS APLN extension > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Monday, May 28, 2018 2:11 PM > > > To: Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@McAfee.com>; > > > Benjamin Kaduk <kaduk@mit.edu>; mohamed.boucadair@orange.com; > > > dots@ietf.org > > > Subject: RE: [Dots] TLS APLN extension > > > > > > > > > > > > Hi Tiru, > > > > > > I agree that it makes no sense to have our own ALPN - "coap" is fine > > > as that is describing the next protocol layer up. However, I did > > > raise the question in case the DOTS Server needs to respond to a > > > DOTS client that is correctly following RFC 8323 and expecting to > > > see back a ALPN > > response. > > > > The DOTS server will not be running on 5684. If the DOTS server is > > correctly following RFC8323, it should respond with ALPN response "coap". > > > > -Tiru > > > > > > > > "If the TLS server either does not negotiate the ALPN extension or > > > returns a no_application_protocol alert, the TLS client MUST close > > > the > > connection." > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > Tirumaleswar Reddy > > > Sent: 28 May 2018 07:03 > > > To: Jon Shallow; 'Benjamin Kaduk'; mohamed.boucadair@orange.com; > > > dots@ietf.org > > > Subject: Re: [Dots] TLS APLN extension > > > > > > Although coaps+tcp URI scheme is used by DOTS signal channel, we > > > have not yet seen any requirement where multiple protocols will be > > > run on the DOTS server port number 4646. > > > I don't see the need to define a new ALPN for DOTS signal channel. > > > > > > Cheers > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > > Sent: Wednesday, May 23, 2018 1:58 PM > > > > To: 'Benjamin Kaduk' <kaduk@mit.edu>; > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] TLS APLN extension > > > > > > > > > > > > > > > > Hi Ben, > > > > > > > > The DOTS signal spec calls for CoAP secured by running over (D)TLS > > > > (either UDP and/or TCP), and CoAP over TLS is coaps+tcp. So, yes, > > > > both coaps and > > > > coaps+tcp have to be supported. > > > > > > > > For example, I can use the github libcoap coap-client (Pull > > > > Request > > > > #176 > > > > installed) and do "coap-client -c cert.pem > > > > coaps+tcp://127.0.0.1:4646/.well-known/dots/v1/config" against my > > > > coaps+DOTS > > > > server and get back binary data (it is CBOR encoded). > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Benjamin > > > > Kaduk > > > > Sent: 23 May 2018 01:35 > > > > To: mohamed.boucadair@orange.com > > > > Cc: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] TLS APLN extension > > > > > > > > The dedicated port number is only somewhat relevant, I think -- > > > > the main question is whether the coaps+tcp URI scheme is in use. > > > > The RFC > > > > 8323 requirements only come into play for that URI scheme. > > > > > > > > -Ben > > > > > > > > On Tue, May 22, 2018 at 07:54:39AM +0000, > > > mohamed.boucadair@orange.com > > > > wrote: > > > > > Re-, > > > > > > > > > > Do we need this given that DOTS is using a dedicated port number? > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > Shallow Envoyé : lundi 21 mai 2018 09:55 À : dots@ietf.org Objet > > > > > : [Dots] TLS APLN extension > > > > > > > > > > Hi there, > > > > > > > > > > As per RFC 8323: 8.2. coaps+tcp URI Scheme > > > > > > > > > > .... > > > > > > > > > > o If a TLS server does not support the Application-Layer Protocol > > > > > Negotiation (ALPN) extension [RFC7301] or wishes to accommodate > > > > > TLS clients that do not support ALPN, it MAY offer a coaps+tcp > > > > > endpoint on TCP port 5684. This endpoint MAY also be ALPN > > > > > enabled. A TLS server MAY offer coaps+tcp endpoints on ports > > > > > other than TCP port 5684, which MUST be ALPN enabled. > > > > > > > > > > o For TCP ports other than port 5684, the TLS client MUST use the > > > > > ALPN extension to advertise the "coap" protocol identifier (see > > > > > Section 11.7) in the list of protocols in its ClientHello. If the > > > > > TCP server selects and returns the "coap" protocol identifier > > > > > using the ALPN extension in its ServerHello, then the connection > > > > > succeeds. If the TLS server either does not negotiate the ALPN > > > > > extension or returns a no_application_protocol alert, the TLS > > > > > client MUST close the connection. > > > > > > > > > > Do we need to refer to the requirement for ALPN as we are not > > > > > hosting on > > > > port 5684? > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots
- [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension mohamed.boucadair
- Re: [Dots] TLS APLN extension Benjamin Kaduk
- Re: [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension Konda, Tirumaleswar Reddy
- Re: [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension Konda, Tirumaleswar Reddy
- Re: [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension Konda, Tirumaleswar Reddy
- Re: [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension Konda, Tirumaleswar Reddy
- Re: [Dots] TLS APLN extension Jon Shallow
- Re: [Dots] TLS APLN extension mohamed.boucadair