Subject: [Dots] TLS APLN extension

From: "Jon Shallow" <[email-masked]>
Date: Mon, 21 May 2018 08:54:36 +0100

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

---

From: <[email-masked]>
Date: Tue, 22 May 2018 07:54:39 +0000

Re-,

Do we need this given that DOTS is using a dedicated port number?

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 21 mai 2018 09:55
À : [email-masked]
Objet : [Dots] TLS APLN extension

Hi there,

...

Do we need to refer to the requirement for ALPN as we are not hosting on port 5684?

Regards

Jon

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 May 2018 19:34:52 -0500

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, [email-masked] wrote:
> ....

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 23 May 2018 09:28:15 +0100

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: [email-masked]] On Behalf Of Benjamin Kaduk
Sent: 23 May 2018 01:35
To: [email-masked]
Cc: Jon Shallow; [email-masked]
Subject: Re: [Dots] TLS APLN extension

-Ben

port 5684?

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 28 May 2018 06:02:43 +0000

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

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Wednesday, May 23, 2018 1:58 PM
> To: 'Benjamin Kaduk' <[email-masked]>; [email-masked];
> [email-masked]
> 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
> 
> > Envoyé : lundi 21 mai 2018 09:55 À : [email-masked] Objet : [Dots] TLS
> > APLN extension
> >
> > Hi there,
> >

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 28 May 2018 09:40:37 +0100

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:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 28 May 2018 07:03
To: Jon Shallow; 'Benjamin Kaduk'; [email-masked]; [email-masked]
Subject: Re: [Dots] TLS APLN extension

Cheers
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 28 May 2018 09:48:58 +0000

> From: Jon Shallow [mailto:[email-masked]]
> Sent: Monday, May 28, 2018 2:11 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Benjamin Kaduk <[email-masked]>; [email-masked];
> [email-masked]
> Subject: RE: [Dots] TLS APLN extension
> 
> 
> 
> 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.

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
> 
> 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.
> > 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
> > 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
> >
> > > Envoyé : lundi 21 mai 2018 09:55 À : [email-masked] Objet : [Dots]
> > > TLS APLN extension
> > >
> > > Hi there,
> > >

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 28 May 2018 11:00:46 +0100

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?

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 28 May 2018 10:49
To: Jon Shallow; Benjamin Kaduk; [email-masked]; [email-masked]
Subject: Re: [Dots] TLS APLN extension

> I agree that it makes no sense to have our own ALPN - "coap" is fine as that is

-Tiru

> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: 28 May 2018 07:03

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 28 May 2018 13:28:12 +0000

> Sent: Monday, May 28, 2018 3:31 PM
> 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.

Cheers,
-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
> >
> > 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.
> > > coaps+tcp://127.0.0.1:4646/.well-known/dots/v1/config" against my
> > > coaps+DOTS
> > > RFC

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 28 May 2018 15:44:30 +0100

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 28 May 2018 14:28
To: Jon Shallow; Benjamin Kaduk; [email-masked]; [email-masked]
Subject: Re: [Dots] TLS APLN extension

[Jon] Agreed.  Are you able to do this with some suitable wrapper text?
~Jon

Cheers,
-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 29 May 2018 07:09:16 +0000

> Sent: Monday, May 28, 2018 8:15 PM
> > 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?
> 

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

> > > 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
> >
> > >
> > > 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.
> > > > To: 'Benjamin Kaduk' <[email-masked]>;
> > > > [email-masked]; [email-masked]
> > > > For example, I can use the github libcoap coap-client (Pull
> > > > Request
> > > > #176
> > > > 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
> > > > > De : Dots [mailto:[email-masked]] De la part de Jon
> > > > > Shallow Envoyé : lundi 21 mai 2018 09:55 À : [email-masked] Objet
> > > > > : [Dots] TLS APLN extension
> > > > >
> > > > > Hi there,
> > > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 29 May 2018 08:42:49 +0100

Hi Tiru,

Suggested text looks good to me.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 29 May 2018 08:09
To: Jon Shallow; Benjamin Kaduk; [email-masked]; [email-masked]
Subject: Re: [Dots] TLS APLN extension

Proposed text:

-Tiru

---

From: <[email-masked]>
Date: Tue, 29 May 2018 09:38:16 +0000

Re-,

I updated the draft accordingly. 

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mardi 29 mai 2018 09:43
> À : 'Konda, Tirumaleswar Reddy'; Benjamin Kaduk; BOUCADAIR Mohamed IMT/OLN;
> [email-masked]
> Objet : RE: [Dots] TLS APLN extension
> 
> Hi Tiru,
> 
> DOTS signal channel uses the "coaps" URI scheme defined in Section 6 of
> RFC7252 and "coaps+tcp" URI scheme defined in