IETF Logo Mail Archive

Re: [Dots] TLS APLN extension

<mohamed.boucadair@orange.com> Tue, 22 May 2018 07:54 UTC

Return-Path: <mohamed.boucadair@orange.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 92E6D12E858 for <dots@ietfa.amsl.com>; Tue, 22 May 2018 00:54:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uK9BaP4FC5ec for <dots@ietfa.amsl.com>; Tue, 22 May 2018 00:54:42 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8AF12E854 for <dots@ietf.org>; Tue, 22 May 2018 00:54:42 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 92EC3C05F0; Tue, 22 May 2018 09:54:40 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 7064B4005B; Tue, 22 May 2018 09:54:40 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0389.001; Tue, 22 May 2018 09:54:40 +0200
From: mohamed.boucadair@orange.com
To: Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] TLS APLN extension
Thread-Index: AdPw2PQOXpzyKiqHQ7+v5FEn8F2ThwAyFv1g
Date: Tue, 22 May 2018 07:54:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF1E28F@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <13d301d3f0d8$f66f7c60$e34e7520$@jpshallow.com>
In-Reply-To: <13d301d3f0d8$f66f7c60$e34e7520$@jpshallow.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF1E28FOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/QzdkYo4JT1_3RC6Ufz-P9AxmhKQ>
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, 22 May 2018 07:54:45 -0000

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

v2.23.0 | Report a Bug | By Email