Re: [Tls-reg-review] [IANA #1154299] Re: [UNVERIFIED SENDER] Request to Register Value in TLS ALPN Registry

"Salz, Rich" <rsalz@akamai.com> Tue, 22 October 2019 23:39 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: tls-reg-review@ietfa.amsl.com
Delivered-To: tls-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06F120152 for <tls-reg-review@ietfa.amsl.com>; Tue, 22 Oct 2019 16:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 UXwDADibSwAb for <tls-reg-review@ietfa.amsl.com>; Tue, 22 Oct 2019 16:39:10 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 94C8812006A for <tls-reg-review@ietf.org>; Tue, 22 Oct 2019 16:39:10 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9MNavHU014629; Wed, 23 Oct 2019 00:38:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=KotFL9eBD870Gh337bjcKPXkZZQBvxwdL6IBDhcaeVs=; b=QjOmx6HwudiKWOGIm5YY45mOsnx93VsLSGyeTLjB+27rE6iTaHBiQiiXzRXQkJV6YkeJ 7EtIFtdhOfAydXS7uY+4XcdmzJJSkSg++2RHc4hWckXcHj6xucphyuddo1dnH0PmXN1L GI1E3GaYSinkB+pWuNH33oHeWeGx1UijFjrjrqj/KM7ifb2PwW17hBQ7xwlq1elBcSyW TJ2Qh0d4xSS7XfjHiZXID60D5YYtwnhLuAzchbOXhWkHL9urzLbLVIozp48KrsFjgEDw XRYeHs/S+Jn9fBl0hwc7Agkxw9TWGgHLTlAeXCrqGDqn5QBCBtsSV5/hDCJ4Xd8IkvJY Ag==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vqsr9t1b4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 00:38:47 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9MNWc0o008498; Tue, 22 Oct 2019 19:38:46 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vqwtyu7xu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 19:38:46 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 19:38:45 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 22 Oct 2019 19:38:45 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "iana-prot-param@iana.org" <iana-prot-param@iana.org>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>
CC: "tls-reg-review@ietf.org" <tls-reg-review@ietf.org>
Thread-Topic: [Tls-reg-review] [IANA #1154299] Re: [UNVERIFIED SENDER] Request to Register Value in TLS ALPN Registry
Thread-Index: AQHViSOP4sMFJULRWEqnclBAuXp6KadnUWcA
Date: Tue, 22 Oct 2019 23:38:44 +0000
Message-ID: <78B07C5F-115F-4CC8-9DDF-919B6FCCC3A2@akamai.com>
References: <RT-Ticket-1154299@icann.org> <237DADD1-883D-47C3-88D4-3B39D9843CBC@amazon.com> <73904165-C904-455B-B681-488F7EE676C2@gmail.com> <50D9DBC7-2A06-4479-90D5-D3CEA2BD857F@amazon.com> <B8780BD9-84F3-41ED-9EDD-C94F122BB3DE@gmail.com> <D8E8C333-79BA-4854-92F9-7D55C56F4CD4@akamai.com> <50281700-558A-48AF-BA75-4A36E48EE334@gmail.com> <rt-4.4.3-10882-1571781381-887.1154299-37-0@icann.org>
In-Reply-To: <rt-4.4.3-10882-1571781381-887.1154299-37-0@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.187]
Content-Type: text/plain; charset="utf-8"
Content-ID: <73E010F39908F44B8ADC14A1506D94D7@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-22_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910220203
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-22_06:2019-10-22,2019-10-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910220203
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls-reg-review/C6_lLffCt-60cEZ307uYr5yGOng>
Subject: Re: [Tls-reg-review] [IANA #1154299] Re: [UNVERIFIED SENDER] Request to Register Value in TLS ALPN Registry
X-BeenThere: tls-reg-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TLS REVIEW <tls-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls-reg-review>, <mailto:tls-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls-reg-review/>
List-Post: <mailto:tls-reg-review@ietf.org>
List-Help: <mailto:tls-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls-reg-review>, <mailto:tls-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 23:39:13 -0000

Put the reserved first and then chronologically.

On 10/22/19, 5:56 PM, "Sabrina Tanamal via RT" <iana-prot-param@iana.org> wrote:

    Hi Yoav, all, 
    
    Before we add this entry to the registry, should we continue to list the entries chronologically by the registration date? If so, should we make an exception for the reserved entries and list them at the end, or should we add the newest entry after the last reserved entry?
    
    You can see the current registry here: 
    
    https://www.iana.org/assignments/tls-extensiontype-values
    
    Thanks,
    Sabrina
    
    On Fri Oct 18 18:56:57 2019, ynir.ietf@gmail.com wrote:
    > Yup, even IP.
    > 
    > IANA: Can you please add the following registration?
    > 
    > Registry name: TLS Application-Layer Protocol Negotiation (ALPN)
    > Protocol IDs
    > Protocol field should be “OASIS Message Queuing Telemetry Transport
    > (MQTT)”
    > Identification sequence should be:   0x6d 0x71 0x74 0x74 (“mqtt”)
    > Reference should be this document:   http://docs.oasis-
    > open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html <http://docs.oasis-
    > open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html>
    > 
    > Thanks.
    > 
    > Yoav
    > (on behalf of the TLS registry review team)
    > 
    > 
    > > On 18 Oct 2019, at 21:44, Salz, Rich <rsalz@akamai.com> wrote:
    > >
    > > I’m fine with it.
    > >
    > > Tunneling things through HTTPS has a long history :)
    > >
    > > From: Yoav Nir <ynir.ietf@gmail.com>
    > > Date: Friday, October 18, 2019 at 2:41 PM
    > > To: "Thakar, Eeshan" <thakar@amazon.com>om>, "tls-reg-review@ietf.org"
    > > <tls-reg-review@ietf.org>
    > > Cc: "Lee, Alexandra" <alexanl@amazon.com>om>, "Sharfin, Jared"
    > > <sharfinj@amazon.com>om>, "Gochenaur, Drew" <gochenau@amazon.com>
    > > Subject: Re: [Tls-reg-review] [UNVERIFIED SENDER] Request to Register
    > > Value in TLS ALPN Registry
    > >
    > > I think it’s fine.
    > >
    > > Rich?  Nick?  (we need at least two of us to agree)
    > >
    > > Yoav
    > >
    > >
    > >> On 18 Oct 2019, at 20:30, Thakar, Eeshan <thakar@amazon.com
    > >> <mailto:thakar@amazon.com>> wrote:
    > >>
    > >> Hello,
    > >>
    > >> Did you get a chance to review the application with the added
    > >> context from my email?
    > >>
    > >> Thanks,
    > >>
    > >> Eeshan
    > >>
    > >> From: Thakar, Eeshan <thakar@amazon.com <mailto:thakar@amazon.com>>
    > >> Sent: Monday, August 12, 2019 5:13 PM
    > >> To: Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>
    > >> Cc: tls-reg-review@ietf.org <mailto:tls-reg-review@ietf.org>; Lee,
    > >> Alexandra <alexanl@amazon.com <mailto:alexanl@amazon.com>>; Sharfin,
    > >> Jared <sharfinj@amazon.com <mailto:sharfinj@amazon.com>>; Gochenaur,
    > >> Drew <gochenau@amazon.com <mailto:gochenau@amazon.com>>
    > >> Subject: Re: [UNVERIFIED SENDER] Re: [Tls-reg-review] Request to
    > >> Register Value in TLS ALPN Registry
    > >>
    > >> Hi Yoav,
    > >>
    > >> Thanks for taking a look through the request. The current
    > >> implementation for the AWS IoT Gateway endpoint does support
    > >> HTTP/1.1 and MQTT (3.1 and 3.1.1) on the same port (443) using ALPN
    > >> (with a custom ALPN protocol id).
    > >> It also supports MQTT on the IANA registered port (8883), but allows
    > >> ALPN based MQTT connections on 443 to work around standard firewall
    > >> configurations [1].
    > >>
    > >> The goal with getting the “mqtt” protocol id registered was to have
    > >> a common basis for all implementers of gateways that support HTTP
    > >> and MQTT (multiple cloud IoT services do so today, albeit not on the
    > >> same port) to have a way to accept MQTT traffic on port 443. This is
    > >> similar to how CoAP has both an ALPN registered string (“coap”) and
    > >> a registered port (5684 for CoAP with TCP/TLS).
    > >>
    > >> Thanks,
    > >>
    > >> Eeshan
    > >>
    > >> [1]: https://aws.amazon.com/blogs/iot/mqtt-with-tls-client-
    > >> authentication-on-port-443-why-it-is-useful-and-how-it-works/
    > >> <https://urldefense.proofpoint.com/v2/url?u=https-
    > >> 3A__aws.amazon.com_blogs_iot_mqtt-2Dwith-2Dtls-2Dclient-
    > >> 2Dauthentication-2Don-2Dport-2D443-2Dwhy-2Dit-2Dis-2Duseful-2Dand-
    > >> 2Dhow-2Dit-
    > >> 2Dworks_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
    > >> w&m=3E_UAQbU2i5rQj4oofQmA2Zn6VVJWCevYQrKZ79iWEM&s=gS3wQv9j7fykgWX5rYj3Juwi-
    > >> bASrckP4DIA5dBf2Ec&e=>
    > >>
    > >> From: Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>
    > >> Date: Saturday, August 10, 2019 at 2:08 AM
    > >> To: "Thakar, Eeshan" <thakar@amazon.com <mailto:thakar@amazon.com>>
    > >> Cc: "tls-reg-review@ietf.org <mailto:tls-reg-review@ietf.org>" <tls-
    > >> reg-review@ietf.org <mailto:tls-reg-review@ietf.org>>, "Lee,
    > >> Alexandra" <alexanl@amazon.com <mailto:alexanl@amazon.com>>,
    > >> "Sharfin, Jared" <sharfinj@amazon.com <mailto:sharfinj@amazon.com>>,
    > >> "Gochenaur, Drew" <gochenau@amazon.com <mailto:gochenau@amazon.com>>
    > >> Subject: [UNVERIFIED SENDER] Re: [Tls-reg-review] Request to
    > >> Register Value in TLS ALPN Registry
    > >>
    > >> On 9 Aug 2019, at 23:45, Thakar, Eeshan
    > >> <thakar=40amazon.com@dmarc.ietf.org
    > >> <mailto:thakar=40amazon.com@dmarc.ietf.org>> wrote:
    > >>
    > >>> Type of Assignment:
    > >>> Registration of “mqtt” token
    > >>>
    > >>> Registry:
    > >>> Application Layer Protocol Negotiation (ALPN) Protocol ID
    > >>>
    > >>> Description:
    > >>> The mqtt protocol has the protocol version written into the first
    > >>> message on a connection. The mqtt server implementations typically
    > >>> understand the protocol version based on the fixed header on the
    > >>> first message (connect).
    > >>>
    > >>> Adding this protocol id to the registry will help the community
    > >>> since clients wanting to request mqtt as the protocol would have an
    > >>> appropriate specification reference to use.
    > >>>
    > >>> Additional Info:
    > >>> [1] MQTT 3.1 Specification:
    > >>> http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-
    > >>> v3r1.html <https://urldefense.proofpoint.com/v2/url?u=http-
    > >>> 3A__public.dhe.ibm.com_software_dw_webservices_ws-2Dmqtt_mqtt-
    > >>> 2Dv3r1.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
    > >>> w&m=3E_UAQbU2i5rQj4oofQmA2Zn6VVJWCevYQrKZ79iWEM&s=cCCKZ-
    > >>> lqltftwi8iSb9xnH41GIG7pDOo77inFY0LShI&e=>
    > >>> [2] MQTT 3.1.1 Specification: http://docs.oasis-
    > >>> open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html
    > >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-
    > >>> 2Dopen.org_mqtt_mqtt_v3.1.1_csprd02_mqtt-2Dv3.1.1-
    > >>> 2Dcsprd02.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
    > >>> w&m=3E_UAQbU2i5rQj4oofQmA2Zn6VVJWCevYQrKZ79iWEM&s=PmP61TQmKHzpZMhM8TNDzpcZBqp1fZ8RM7xE05_c9T8&e=>
    > >>> [3] MQTT 5.0 Specification: http://docs.oasis-
    > >>> open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
    > >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-
    > >>> 2Dopen.org_mqtt_mqtt_v5.0_mqtt-
    > >>> 2Dv5.0.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-
    > >>> w&m=3E_UAQbU2i5rQj4oofQmA2Zn6VVJWCevYQrKZ79iWEM&s=BEoHGVZzaCG6fp19ig2vfDpkz4rJkQhdUEVOG8EtQD0&e=>
    > >>>
    > >>
    > >> Hi, Eeshan.
    > >>
    > >> I’ve looked through the linked specifications, especially the third
    > >> one because it says it replaces the others.
    > >>
    > >> It says that TCP port 8883 is registered with IANA for MQTT over
    > >> TLS, and the IANA registry confirms it.  If you have your own port,
    > >> why do you need ALPN?
    > >>
    > >> ALPN is used to negotiate a particular service (such as HTTP) over a
    > >> single port, typically 443.
    > >>
    > >> So if you were using a server listening on port 443 and serving both
    > >> MQTT and HTTP/2 you would need that to distinguish clients that need
    > >> MQTT from web browsers that need HTTP/2.
    > >>
    > >> The linked document does not make any mention of such a server.  Is
    > >> this described elsewhere?
    > >>
    > >> Thanks
    > >>
    > >> Yoav
    
    _______________________________________________
    tls-reg-review mailing list
    tls-reg-review@ietf.org
    https://www.ietf.org/mailman/listinfo/tls-reg-review