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

[Magnus Westerlund <[e-mail]>]

Hi,

On Thu, 2020-12-17 at 16:56 +0000, [e-mail] wrote:
> 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.

To my understanding ALPN is part of the TLS mechansism that applies to both TLS
and DTLS so I don't really understand the above sentence applicability.

> 
> > 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.

So I think there are several possible implementation paths for this. I see at
least two.

First, do a 5-tuple connect on UDP to filter that particular UDP flow, process
the DTLS handshake for this socket and then based on ALPN decide on target
process and then hand over the socket and the DTLS state to the right process. 

Secondly, is to run some type of front end dispatcher that processes the packets
and tracks all the different DTLS connection and have secure message passing
between the front end dispatcher and the different servers. But this do requie
another security model and trust relationship between the dispatcher and the
servers. 

> 
> 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.

I think the current security properties are basically the same between two well
know ports and one port with unencrypted ALPN. And when you move to DTLS 1.3 the
alpn extension will be encrypted and you have slightly better security as the
third party observer can't know if it is DOTS signal or DOTS call home that
being used based on the handshake.

Cheers

Magnus