Re: [Dots] TLS APLN extension

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Jon Shallow [mailto:[e-mail]]
> Sent: Monday, May 28, 2018 8:15 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Benjamin Kaduk <[e-mail]>; [e-mail];
> [e-mail]
> Subject: RE: [Dots] TLS APLN extension
> 
> 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.
> 
> -----Original Message-----
> From: Dots [mailto: [e-mail]] On Behalf Of Konda, Tirumaleswar
> Reddy
> Sent: 28 May 2018 14:28
> To: Jon Shallow; Benjamin Kaduk; [e-mail];
> [e-mail]
> Subject: Re: [Dots] TLS APLN extension
> 
> > -----Original Message-----
> > From: Jon Shallow [mailto:[e-mail]]
> > Sent: Monday, May 28, 2018 3:31 PM
> > To: Konda, Tirumaleswar Reddy <[e-mail]>;
> > Benjamin Kaduk <[e-mail]>; [e-mail];
> > [e-mail]
> > Subject: RE: [Dots] TLS APLN extension
> >
> > 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.
> 
> [Jon] Agreed.  Are you able to do this with some suitable wrapper text?

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

> ~Jon
> 
> Cheers,
> -Tiru
> 
> >
> > Regards
> >
> > Jon
> >
> > -----Original Message-----
> > From: Dots [mailto: [e-mail]] On Behalf Of Konda,
> > Tirumaleswar Reddy
> > Sent: 28 May 2018 10:49
> > To: Jon Shallow; Benjamin Kaduk; [e-mail];
> > [e-mail]
> > Subject: Re: [Dots] TLS APLN extension
> >
> > > -----Original Message-----
> > > From: Jon Shallow [mailto:[e-mail]]
> > > Sent: Monday, May 28, 2018 2:11 PM
> > > To: Konda, Tirumaleswar Reddy
> <[e-mail]>;
> > > Benjamin Kaduk <[e-mail]>; [e-mail];
> > > [e-mail]
> > > 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: [e-mail]] On Behalf Of Konda,
> > > Tirumaleswar Reddy
> > > Sent: 28 May 2018 07:03
> > > To: Jon Shallow; 'Benjamin Kaduk'; [e-mail];
> > > [e-mail]
> > > 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:[e-mail]] On Behalf Of Jon Shallow
> > > > Sent: Wednesday, May 23, 2018 1:58 PM
> > > > To: 'Benjamin Kaduk' <[e-mail]>;
> > > > [e-mail]; [e-mail]
> > > > 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
> > > > coaps+DOTS
> > > > server and get back binary data (it is CBOR encoded).
> > > >
> > > > Regards
> > > >
> > > > Jon
> > > >
> > > > -----Original Message-----
> > > > From: Dots [mailto: [e-mail]] On Behalf Of Benjamin
> > > > Kaduk
> > > > Sent: 23 May 2018 01:35
> > > > To: [e-mail]
> > > > Cc: Jon Shallow; [e-mail]
> > > > 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,
> > > [e-mail]
> > > > wrote:
> > > > > Re-,
> > > > >
> > > > > Do we need this given that DOTS is using a dedicated port number?
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > De : Dots [mailto:[e-mail]] De la part de Jon
> > > > > Shallow Envoyé : lundi 21 mai 2018 09:55 À : [e-mail] 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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/dots
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
> >
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots