Re: [Dots] TLS APLN extension

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: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 28 May 2018 10:49
To: Jon Shallow; Benjamin Kaduk; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] TLS APLN extension

> -----Original Message-----
> From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
> Sent: Monday, May 28, 2018 2:11 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
> Benjamin Kaduk <kaduk@mit.edu>; mohamed.boucadair@orange.com;
> dots@ietf.org
> Subject: RE: [Dots] TLS APLN extension
> 
> 
> 
> Hi 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
> 
> -----Original Message-----
> From: Dots [mailto: 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

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots