[Dots] TLS APLN extension

"Jon Shallow" <supjps-ietf@jpshallow.com> Mon, 21 May 2018 07:54 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 4885F12E866 for <dots@ietfa.amsl.com>; Mon, 21 May 2018 00:54:37 -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, HTML_MESSAGE=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 MUti8DWMJbgK for <dots@ietfa.amsl.com>; Mon, 21 May 2018 00:54:35 -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 9AE99126C22 for <dots@ietf.org>; Mon, 21 May 2018 00:54:35 -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 1fKfeM-0004Tg-3y for ietf-supjps-dots@ietf.org; Mon, 21 May 2018 08:54:34 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: dots@ietf.org
Date: Mon, 21 May 2018 08:54:36 +0100
Message-ID: <13d301d3f0d8$f66f7c60$e34e7520$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_13D4_01D3F0E1.58365560"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdPw2PQOXpzyKiqHQ7+v5FEn8F2Thw==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/I-rCoRZ0Sv951HcRQXiCJBsVoWc>
Subject: [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, 21 May 2018 07:54:38 -0000

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