Re: [Dots] TLS APLN extension

"Jon Shallow" <supjps-ietf@jpshallow.com> Mon, 28 May 2018 08:40 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 7684812704A for <dots@ietfa.amsl.com>; Mon, 28 May 2018 01:40:42 -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 KCwnE5Qaa0-P for <dots@ietfa.amsl.com>; Mon, 28 May 2018 01:40:40 -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 582A4127078 for <dots@ietf.org>; Mon, 28 May 2018 01:40:40 -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 1fNDhk-0000Gi-Sp; Mon, 28 May 2018 09:40:36 +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>
In-Reply-To: <BN6PR16MB142569E727B738DA81844E73EA6E0@BN6PR16MB1425.namprd16.prod.outlook.com>
Date: Mon, 28 May 2018 09:40:37 +0100
Message-ID: <18b001d3f65f$8d47df20$a7d79d60$@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/ABpTg7WwITkQo3pLx7bWA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Ffg56z1DFWBRWkN7wo5_5HSNb48>
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: Mon, 28 May 2018 08:40:43 -0000

Hi Tiru,

I agree that it makes no sense to have our own APLN - "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.

"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:ietf-supjps-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 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