Re: [Dots] Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS)

[[e-mail]]

Hi Magnus,

We had considered using ALPN.

While DOTS signal channel can use TLS, given that this DOTS protocol has to be robust in an Distribute Denial of Service attack environment, its primary use will be DTLS using UDP.

> Based on what you write in your email to my understanding ALPN in (D)TLS
> would work fairly well to dispatch the secured connection to the individual
> implementation of DOTS-signal and Dots-call home if that is needed.

When using TCP, it is relatively easy to dispatch a secured connection and attach it to, say a forked copy of the appropriate application or a new thread in the application which then does all the network i/o over that secured connection.

However, for UDP from an implementation perspective, I cannot see how this can be done so the network stack can itself steer each input packet to the appropriate application when the traffic arrives on the same IP and port (only one application can receive traffic on a specific udp port).  I welcome any wisdom on how to do this.

There is also a minor concern in about exposing the protocol as https://tools.ietf.org/html/rfc7301#section-5  which states

   Implementers and document editors who intend to extend the protocol
   identifier registry by adding new protocol identifiers should
   consider that in TLS versions 1.2 and below the client sends these
   identifiers in the clear.  They should also consider that, for at
   least the next decade, it is expected that browsers would normally
   use these earlier versions of TLS in the initial ClientHello.

   Care must be taken when such identifiers may leak personally
   identifiable information, or when such leakage may lead to profiling
   or to leaking of sensitive information.  If any of these apply to
   this new protocol identifier, the identifier SHOULD NOT be used in
   TLS configurations where it would be visible in the clear, and
   documents specifying such protocol identifiers SHOULD recommend
   against such unsafe use.

Even though it is possible to derive things from the fact that a particular port being used.

Regards

Jon

> -----Original Message-----
> From: Magnus Westerlund [mailto:ietf-supjps-
> [e-mail]]
> Sent: 17 December 2020 15:55
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; draft-ietf-dots-
> [e-mail]
> Subject: Re: Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-home-
> 11: (with DISCUSS)
> 
> Hi,
> 
> I hadn't read this before. But I have now read it and it don't really change my
> perspective. I think there are several options here that should work for you.
> 
> Based on what you write in your email to my understanding ALPN in (D)TLS
> would
> work fairly well to dispatch the secured connection to the individual
> implementation of DOTS-signal and Dots-call home if that is needed. And future
> implementation that are combined can simply use that ALPN signal as a basic
> indication on behavior in common code paths.
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> 
> 
> 
> On Thu, 2020-12-17 at 15:22 +0000, [e-mail] wrote:
> > Hi Magnus,
> >
> > I wonder whether you had a chance to read this message where explain why
> this
> > is a new service, not a variant of an existing service:
> > https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-
> 4XtJHPmsPR_quuyO0c/
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Magnus Westerlund via Datatracker [mailto:[e-mail]]
> > > Envoyé : jeudi 17 décembre 2020 15:29
> > > À : The IESG <[e-mail]>
> > > Cc : [e-mail]; dots-
> > > [e-mail]; [e-mail]; Valery Smyslov <[e-mail]>;
> > > [e-mail]
> > > Objet : Magnus Westerlund's Discuss on draft-ietf-dots-signal-call-
> > > home-11: (with DISCUSS)
> > >
> > > Magnus Westerlund has entered the following ballot position for
> > > draft-ietf-dots-signal-call-home-11: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-
> > > criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Section 7.1: Port request for DOTS signal for home.
> > >
> > > I think the WG has failed to take the assignment principles in RFC
> > > 6335 to
> > > heart:
> > >
> > > > From Section 7:
> > >
> > >    "The basic principle of service name and port number registry
> > >    management is to conserve use of the port space where possible."
> > >
> > >    o  IANA strives to assign only one assigned port number per
> > > service
> > >       or application.
> > >
> > >       Note: At the time of writing of this document, there is no
> > > IETF
> > >       consensus on when it is appropriate to use a second port for
> > > an
> > >       insecure version of a protocol.
> > >
> > >    o  IANA strives to assign only one assigned port number for all
> > >       variants of a service (e.g., for updated versions of a
> > > service).
> > >
> > >    o  IANA strives to encourage the deployment of secure protocols.
> > >
> > >    o  IANA strives to assign only one assigned port number for all
> > >       different types of devices using or participating in the same
> > >       service.
> > >
> > >    o  IANA strives to assign port numbers only for the transport
> > >       protocol(s) explicitly named in an assignment request.
> > >
> > >    o  IANA may recover unused port numbers, via the new procedures
> > > of
> > >       de-assignment, revocation, and transfer.
> > >
> > > After having reviewed Appendix A I think the WG has made the wrong
> > > choice and also not considered all the available choices for
> > > enabling DOTS signal and call home to be colocated on the same port.
> > > Several options exists:
> > >
> > >         - URI name space so that it is the same protocol just making
> > > requests
> > >         with different URIs depending on mode - Use the already
> > > existing
> > >         settings negotiation to determine the mode of operation. -
> > > Using ALPN
> > >         on (D)TLS connection establishment
> > >
> > > > From my perspective the DOTS WG have multiple choices that are
> > >
> > > quite
> > > > simple to
> > >
> > > solve there colocation issue that would not incur significnat cost
> > > or overhead.
> > > Using an additional port do incur a cost of consuming a resource
> > > that is endless and not easily recoverable. I do share the IANA port
> > > experts team's verdict that this port assignment should be denied
> > > and alternative solution found as the motivation appears very weak.
> > >
> > >
> > >
> > >
> >
> >
> >
> _________________________________________________________________
> _____________
> > ___________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> > message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> > electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou
> > falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> > information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete
> > this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been
> > modified, changed or falsified.
> > Thank you.
> >