[core] DTLS CID update (and follow-up)

[Fossati, Thomas (Nokia - GB/Cambridge)]

Hi folks,

For those who couldn't come to Wednesday's TLS session, the decision was
to progress CID for DTLS 1.2 separately from 1.3, in order to make it
available earlier.

The other decision was to not back-port the "CID update" signalling from
1.3 to 1.2, which means that if we want a coherent privacy story for
1.2, we need to do something outside DTLS.

<tldr>
Differently from DTLS 1.3, where two dedicated post-handshake messages
exist to run a "CID update" sub-protocol over an existing session, in
DTLS 1.2 endpoints are stuck with the connection ids that have been
negotiated at handshake time. The problem with this is that lacking
the ability to update connection ids mid-session limits the potential
to protect against an adversary that can observe multiple paths and
can correlate devices' interactions across those paths.
</tldr>

So, I was wondering whether we could add a couple of CoAP options with
same semantics as 1.3's RequestConnectionId and NewConnectionId and
piggyback those on confirmable transactions - yes, ACKing those signals
is not an option.

This is certainly not the cleanest design possible - it abuses a
construct that is intended for carrying representation semantics and
stuffs path attributes into it! - but I couldn't come up with anything
better, apparently.

Before starting to write up a proposal, I'd like to hear from the you
whether you think:
a) This approach unacceptable?
b) There's an alternative design?

Thanks for your time,
Cheers, t

[Klaus Hartke]

Post by Fossati, Thomas (Nokia - GB/Cambridge)
a) This approach unacceptable?
b) There's an alternative design?

We have the 7.xx CoAP signalling codes to manage a TCP connection. I
could imagine doing something similar here if that's really necessary.
Tacking new options onto requests or responses for that, which are not
related to those requests and responses, is probably not a good idea.

After glancing at draft-ietf-tls-dtls-connection-id-00, it looks like
this belongs more to the DTLS layer. Will DTLS implementations need to
provide an API for managing connection IDs from applications? Or are
DTLS implementations expected to scan CoAP messages for magic fields?
It seems this could be solved more cleanly if all information needed
was provided within DTLS itself. I didn't follow the discussion in the
TLS WG, though.

Klaus

[Fossati, Thomas (Nokia - GB/Cambridge)]

Hi Klaus,

Post by Klaus Hartke

Post by Fossati, Thomas (Nokia - GB/Cambridge)
a) This approach unacceptable?
b) There's an alternative design?

We have the 7.xx CoAP signalling codes to manage a TCP connection. I
could imagine doing something similar here if that's really necessary.

It looks like 7.xx and a couple of ad hoc options might do the trick
then?

Post by Klaus Hartke
Tacking new options onto requests or responses for that, which are not
related to those requests and responses, is probably not a good idea.

I agree it's pretty messed up. The only nice property is you can
piggyback CID updates on existing exchanges so you don't need extra
round-trips...

Post by Klaus Hartke
After glancing at draft-ietf-tls-dtls-connection-id-00, it looks like
this belongs more to the DTLS layer. Will DTLS implementations need to
provide an API for managing connection IDs from applications? Or are
DTLS implementations expected to scan CoAP messages for magic fields?

Yes, if we go down this route we need to also extend the DTLS API to
support at least two things: getting a new CID and setting the peer's
CID for the session.

Post by Klaus Hartke
It seems this could be solved more cleanly if all information needed
was provided within DTLS itself. I didn't follow the discussion in the
TLS WG, though.

Yes, I also think DTLS would be the right place for doing this.
However, the TLS chairs were pretty clear that porting 1.3 features (and
the complexity that comes with that) to 1.2 was not in scope.

The alternative is that we design yet another CID with the privacy
properties we need and that can live with the reduced signalling
available in 1.2. As a matter of facts, we originally worked on an HOTP
based construction that precomputes the same, arbitrarily long, string
of 4-bytes CIDs on both ends and therefore doesn't need any explicit
update signalling post-handshake. The trouble is the collision
properties are pretty rubbish [1], making the scheme brittle when the
number of concurrent sessions gets moderately high.

Another possibility is we just drop the privacy requirement for 1.2,
that'd be pretty sad though.


Thanks very much for your input!

Cheers, t


[1] https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-01#section-4

[Klaus Hartke]

Post by Fossati, Thomas (Nokia - GB/Cambridge)
It looks like 7.xx and a couple of ad hoc options might do the trick
then?

Well, CoAP over DTLS is currently not specified to have 7.xx codes. So
you would need to specify a new protocol version, let's call it CoAP
1.1, that adds support and specify some version negotiation mechanism
that allows clients and servers to discover if the other side
understands the 7.xx codes over DTLS or not (ALPN?). My gut feeling is
that this combined (plus the APIs to manage CIDs from applications)
would create much more complexity than just extending DTLS 1.2.

Another idea: You let each end of the DTLS connection offer a CoAP
resource that represents the DTLS connection. If one end wants to
change the connection parameters, it can manipulate the remote
resource with POST or PATCH requests. That's not much better
complexity-wise, but at least it wouldn't put the complexity into DTLS
or CoAP.

Klaus

[Fossati, Thomas (Nokia - GB/Cambridge)]

Hi Klaus,

Post by Klaus Hartke

Post by Fossati, Thomas (Nokia - GB/Cambridge)
It looks like 7.xx and a couple of ad hoc options might do the trick
then?

Well, CoAP over DTLS is currently not specified to have 7.xx codes. So
you would need to specify a new protocol version, let's call it CoAP
1.1, that adds support and specify some version negotiation mechanism
that allows clients and servers to discover if the other side
understands the 7.xx codes over DTLS or not (ALPN?). My gut feeling is
that this combined (plus the APIs to manage CIDs from applications)
would create much more complexity than just extending DTLS 1.2.

Actually, doing the API is probably the easiest, it's the capability
negotiation that looks overkill.

With regards to extending DTLS, I fully agree with you and that was also
my initial stance, but the signal from the TLS WG was very clear, and
in a sense understandable.

The problem here is that the IoT upgrade to TLS 1.3 operates on
completely different time scales than that of browsers, and the risk of
having a relevant number of deployments on 1.2 for longer than desirable
is not negligible.

And since we are the main consumers of the CID construct (at least for
the time being), it is not completely bonkers to try and work out a
solution here in CoRE.

Post by Klaus Hartke
Another idea: You let each end of the DTLS connection offer a CoAP
resource that represents the DTLS connection. If one end wants to
change the connection parameters, it can manipulate the remote
resource with POST or PATCH requests. That's not much better
complexity-wise, but at least it wouldn't put the complexity into DTLS
or CoAP.

The disadvantage is that this moves the implementation of the mechanism
from the stack to the application - with all that it entails.

But thanks for throwing ideas at the problem - much appreciated!