[core] Connection ID

[Hannes Tschofenig]

Hi all,

some of you may have missed the TLS WG meeting last week where we had a
discussion about the Connection ID. The slides can be found at
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-connection-id/
and the draft itself is here:
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-02

I am bringing this to your attention since there have been several
discussions about problems with expired NAT bindings and DTLS on this
mailing list.

Here is the good news: the TLS WG meeting participants expressed strong
consensus to adopt this work.

We are planning to advance the work rapidly given the urgency. There are
open issues, which we plan to address in the next couple of weeks. Then,
we would like to do an online interop test. If you have an
implementation please drop me a private mail.

Ciao
Hannes

PS: Note that the latest DTLS 1.3 spec now includes an optimized record
layer format, which can be used with the connection ID draft. This leads
to a smaller per packet overhead.

[Carsten Bormann]

Post by Hannes Tschofenig
Hi all,
some of you may have missed the TLS WG meeting last week where we had a
discussion about the Connection ID. The slides can be found at
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-connection-id/
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-02
I am bringing this to your attention since there have been several
discussions about problems with expired NAT bindings and DTLS on this
mailing list.
Here is the good news: the TLS WG meeting participants expressed strong
consensus to adopt this work.
We are planning to advance the work rapidly given the urgency. There are
open issues, which we plan to address in the next couple of weeks. Then,
we would like to do an online interop test. If you have an
implementation please drop me a private mail.
Ciao
Hannes
PS: Note that the latest DTLS 1.3 spec now includes an optimized record
layer format, which can be used with the connection ID draft. This leads
to a smaller per packet overhead.

This is all very good.

RFC 7252 still says:

The following rules are added for matching an Acknowledgement message
or Reset message to a Confirmable message, or a Reset message to a
Non-confirmable message: The DTLS session MUST be the same, and the
epoch MUST be the same.

Apparently, we need to relax the rule about the epoch.
Should we just strike this part, or is there going to be a weaker rule?

Grüße, Carsten

[Klaus Hartke]

Post by Carsten Bormann
The following rules are added for matching an Acknowledgement message
or Reset message to a Confirmable message, or a Reset message to a
Non-confirmable message: The DTLS session MUST be the same, and the
epoch MUST be the same.
Apparently, we need to relax the rule about the epoch.
Should we just strike this part, or is there going to be a weaker rule?

Does the epoch actually change?

Klaus

[Hannes Tschofenig]

Hi Klaus,

the epoch wouldn't change based on the current proposal.

The epoch may, however, change based on a key update, which is totally unrelated to the entire connection id business.

Hence, the question even for DTLS 1.3 is why a change of the epoch value should cause the state to be deleted.
An application shouldn't care about the change of epoch since this is a rather mechanical process that relates to cipher use and policies.

On the other hand, DTLS 1.3 allows post handshake authentication which should be of interest to the application layer since the authenticated endpoints may change.

Ciao
Hannes

PS: Maybe the definition of DTLS session also needs to be clarified/modified since the use of the term session does not appear often in the DTLS 1.3 spec anymore and it refers mostly to two aspects, namely the ability to execute a PSK-based handshake using previously established keying material, and the use of sequence numbers.

-----Original Message-----
From: Klaus Hartke [mailto:***@projectcool.de]
Sent: 20 November 2017 19:14
To: Carsten Bormann
Cc: Hannes Tschofenig; Hannes Tschofenig; ***@ietf.org WG
Subject: Re: [core] Connection ID

Post by Carsten Bormann
The following rules are added for matching an Acknowledgement message
or Reset message to a Confirmable message, or a Reset message to a
Non-confirmable message: The DTLS session MUST be the same, and the
epoch MUST be the same.
Apparently, we need to relax the rule about the epoch.
Should we just strike this part, or is there going to be a weaker rule?

Does the epoch actually change?

Klaus
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Klaus Hartke]

Post by Hannes Tschofenig
the epoch wouldn't change based on the current proposal.
The epoch may, however, change based on a key update, which is totally unrelated to the entire connection id business.
Hence, the question even for DTLS 1.3 is why a change of the epoch value should cause the state to be deleted.

At least in DTLS 1.2 the epoch can change for a number of reasons.

We need a precise definition of when two epoch are compatible.

Clearly, a server shouldn't send a response to client B if it received
a request from client A just because A and B happen to be both in
epoch number 2.

Clearly, there is no reason why a server shouldn't be able to send a
response in epoch number 3 if it received the request in epoch number
2 of the same connection and nothing changed but the traffic keys.

Clearly, a server shouldn't send a response in epoch number 3 if it
received the request in epoch number 2 of the same connection if the
client was unauthenticated in epoch number 2 and is authenticated in
epoch number 3.

What about the other cases?

As Carsten indicated earlier [1], once we have have a precise
definition, we can update RFCs 7252 and 7641.

(It seems the Connection ID removes a lot of pain even with the
current, more restrictive definition, though, which I think is
awesome!)

Klaus

[1] https://www.ietf.org/mail-archive/web/core/current/msg08821.html

[Hannes Tschofenig]

Hi Klaus,

Thanks for your input.

IMHO, applications shouldn't have to look at the epoch value when they transmit or receive data. I don't even think (although I haven't checked) that DTLS stacks would even expose that type of information through their APIs.

Of course, there are security relevant events that can happen in a TLS/DTLS exchange, such as post-handshake authentication (DTLS 1.3) or renegotiation (DTLS 1.2), that should be of interest to the application. What exactly the applications do in response to such an event is application dependent. I don't think the CoAP spec should mandate a specific behaviour.

Key updates seem to be super important. In practice, however, a device can run for a very long time without having to update keys, particularly if IoT devices transmit only small amounts of data infrequently.
Here are some details about this topic: https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-08

Ciao
Hannes

-----Original Message-----
From: Klaus Hartke [mailto:***@projectcool.de]
Sent: 22 November 2017 15:45
To: Hannes Tschofenig
Cc: Carsten Bormann; Hannes Tschofenig; ***@ietf.org WG
Subject: Re: [core] Connection ID

Post by Hannes Tschofenig
the epoch wouldn't change based on the current proposal.
The epoch may, however, change based on a key update, which is totally unrelated to the entire connection id business.
Hence, the question even for DTLS 1.3 is why a change of the epoch value should cause the state to be deleted.

At least in DTLS 1.2 the epoch can change for a number of reasons.

We need a precise definition of when two epoch are compatible.

Clearly, a server shouldn't send a response to client B if it received a request from client A just because A and B happen to be both in epoch number 2.

Clearly, there is no reason why a server shouldn't be able to send a response in epoch number 3 if it received the request in epoch number
2 of the same connection and nothing changed but the traffic keys.

Clearly, a server shouldn't send a response in epoch number 3 if it received the request in epoch number 2 of the same connection if the client was unauthenticated in epoch number 2 and is authenticated in epoch number 3.

What about the other cases?

As Carsten indicated earlier [1], once we have have a precise definition, we can update RFCs 7252 and 7641.

(It seems the Connection ID removes a lot of pain even with the current, more restrictive definition, though, which I think is
awesome!)

Klaus

[1] https://www.ietf.org/mail-archive/web/core/current/msg08821.html
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Klaus Hartke]

Post by Hannes Tschofenig
Of course, there are security relevant events that can happen in a TLS/DTLS exchange, such as post-handshake authentication (DTLS 1.3) or renegotiation (DTLS 1.2), that should be of interest to the application. What exactly the applications do in response to such an event is application dependent. I don't think the CoAP spec should mandate a specific behaviour.

I would like CoAP over DTLS to be secure by default.

Application builders should be able to just switch on "coaps://" for
their applications and be reasonably secure without performing an
in-depth analysis of possible security holes related to epoch changes.
Of course, an application builder who wants to perform an in-depth
analysis and implement their own behavior for security relevant events
should be able to do that. But I would assume that in the majority of
cases application builders will just use the defaults provided by the
(most likely application-agnostic) CoAP implementation.

I understand that not all DTLS implementations expose enough
information to react to epoch changes. What would be a good, realistic
default behavior that application-agnostic CoAP implementations should
implement to make applications secure by default?

Klaus

[Hannes Tschofenig]

Hi Klaus,

Normally, you would not use post handshake authentication (DTLS/TLS 1.3) or renegotiation (DTLS/TLS 1.2) in an IoT context since the expectation is that you start with mutual authentication right away.

In TLS (1.2 and 1.3) there is no epoch value but you can still have these handshake messages. Hence, making rules that relate to epoch values just gets us into trouble*.

From your design vision point of view it is better to restrict the use of DTLS/TLS features.

Ciao
Hannes

*: I wonder whether we said anything about this issue in the CoAP over TCP/TLS draft....

-----Original Message-----
From: Klaus Hartke [mailto:***@projectcool.de]
Sent: 22 November 2017 16:48
To: Hannes Tschofenig
Cc: Carsten Bormann; Hannes Tschofenig; ***@ietf.org WG
Subject: Re: [core] Connection ID

Post by Hannes Tschofenig
Of course, there are security relevant events that can happen in a TLS/DTLS exchange, such as post-handshake authentication (DTLS 1.3) or renegotiation (DTLS 1.2), that should be of interest to the application. What exactly the applications do in response to such an event is application dependent. I don't think the CoAP spec should mandate a specific behaviour.

I would like CoAP over DTLS to be secure by default.

Application builders should be able to just switch on "coaps://" for their applications and be reasonably secure without performing an in-depth analysis of possible security holes related to epoch changes.
Of course, an application builder who wants to perform an in-depth analysis and implement their own behavior for security relevant events should be able to do that. But I would assume that in the majority of cases application builders will just use the defaults provided by the (most likely application-agnostic) CoAP implementation.

I understand that not all DTLS implementations expose enough information to react to epoch changes. What would be a good, realistic default behavior that application-agnostic CoAP implementations should implement to make applications secure by default?

Klaus
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Carsten Bormann]

Post by Hannes Tschofenig
*: I wonder whether we said anything about this issue in the CoAP over TCP/TLS draft....

3.3:

Responses MUST be returned over the same connection as
the originating request.

So CoAP over byte-stream is clearly scoped to the connection.

Grüße, Carsten

[Hannes Tschofenig]

So, in CoAP over TCP there is no issue since the connection terminology refers to TCP.
Hence, there is the question why the issues of renegotiation / post handshake authentication matter in DTLS when they do not matter in TLS.

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: 22 November 2017 17:07
To: Hannes Tschofenig
Cc: Klaus Hartke; Hannes Tschofenig; ***@ietf.org WG
Subject: Re: [core] Connection ID

Post by Hannes Tschofenig
*: I wonder whether we said anything about this issue in the CoAP over TCP/TLS draft....

3.3:

Responses MUST be returned over the same connection as
the originating request.

So CoAP over byte-stream is clearly scoped to the connection.

Grüße, Carsten

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[Carsten Bormann]

Post by Hannes Tschofenig
So, in CoAP over TCP there is no issue since the connection terminology refers to TCP.
Hence, there is the question why the issues of renegotiation / post handshake authentication matter in DTLS when they do not matter in TLS.

Well, we wrote the text for TCP in 2016, when we already were aware that the text in RFC 7252/7641 may be too strict.
The text there was written in 2012/2013, when the experience with complex forms of DTLS usage was limited, and the focus was on making sure we didn’t inadvertently exchange data over a connection that had different properties than the applications thought.

I think a better rule for 7252 might have been “don’t do something stupid to your DTLS connection” (expanded in the appropriate DTLS terms), which of course is implicitly the rule underlying CoAP over TLS.

Grüße, Carsten

[Klaus Hartke]

Post by Hannes Tschofenig
Hence, there is the question why the issues of renegotiation / post handshake authentication matter in DTLS when they do not matter in TLS.

I would say they do matter but the current text maybe doesn't reflect
that very well.

Klaus

[Klaus Hartke]

Post by Hannes Tschofenig
From your design vision point of view it is better to restrict the use of DTLS/TLS features.

I generally prefer whitelists over blacklists for security related
restrictions. RFC 7252 essentially whitelists any DTLS feature that
doesn't change the epoch. That probably means just connection setup
and teardown. What additional features should be whitelisted? If post
handshake authentication and renegotiation aren't used and Connection
IDs cover most of session resumption, is it just the change of traffic
keys?

Klaus

[Simon Bernard]

Post by Carsten Bormann

Post by Hannes Tschofenig
Hi all,
some of you may have missed the TLS WG meeting last week where we had a
discussion about the Connection ID. The slides can be found at
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-connection-id/
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-02
I am bringing this to your attention since there have been several
discussions about problems with expired NAT bindings and DTLS on this
mailing list.
Here is the good news: the TLS WG meeting participants expressed strong
consensus to adopt this work.
We are planning to advance the work rapidly given the urgency. There are
open issues, which we plan to address in the next couple of weeks. Then,
we would like to do an online interop test. If you have an
implementation please drop me a private mail.
Ciao
Hannes
PS: Note that the latest DTLS 1.3 spec now includes an optimized record
layer format, which can be used with the connection ID draft. This leads
to a smaller per packet overhead.

This is all very good.
The following rules are added for matching an Acknowledgement message
or Reset message to a Confirmable message, or a Reset message to a
Non-confirmable message: The DTLS session MUST be the same, and the
epoch MUST be the same.
Apparently, we need to relax the rule about the epoch.
Should we just strike this part, or is there going to be a weaker rule?
GrÌße, Carsten

"The DTLS session MUST be the same, and the epoch MUST be the same." I
never find someone which can explain to me what is the purpose of this.
I would happy to know.

Asking on TLS mailing list (for DTLS 1.2), I understand that starting
DTLS connection means epoch = 0.
epoch is incremented each time we change security parameters (after
changecipherspec message). So epoch start from 0. After the first
handshake/changecipherspec epoch is 1. It could be more than that if you
are using session renegociation. (renegociation allow to change security
parameters in the same connection creating a new DTLS session).
Session resumption(!= session renegociation), also called abbreviated
handshake, means using same session/cipher for a new DTLS connection.  A
session resumption start with epoch=0.
(Please correct me if I'm wrong)

So what does "same epoch" means  ? I understand epoch must have same value ?
In that case, you can :
- start a session, send a CoAP request, resume session, receive ACK.
(same session id and same epoch(=1) but different connection)
but you can not :
- start a session, renegociate it, send a CoAP request, resume session,
receive ACK (same session id but epoch is different (1!=2)...)
What is the purpose of this ? allowing session resumption only if you
don't renegociate it before ?

I think we should define in english what we want :
- no session resumption ?
- no session renegociation ?
- cipher suite must not change ?
- identity must not change ?
- or any other security constraint ?
From this we can translate it, in protocol rules.

2nd question, the RFC 7641 say :

GET request with an Observe Option MUST be returned within the same epoch
of the same connection as the request.

This rule is ever more strict. (same connection instead of same session)
So this means no resumption and  no re-negotiation at all.
As observation can be a relation with very long lifetime (more than DTLS
session lifetime which is advised to be 24h), we should find a solution
which allow to separate DTLS session lifetime to observation relation
life time.
Maybe we can consider to use same identity / same cipher. if there is
not client authentication we can fallback with same session.
(Same identity means same psk id or same public key or same certificate)

In Californium(CoAP) project, we code request/response matching in a
flexible way. Any users can implements its own matching rules.
In Leshan (LWM2M) project, we will implement same identity/ same ciper.
(authentication is mandatory).

[Jim Schaad]

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, November 20, 2017 9:55 AM
To: Hannes Tschofenig <***@gmx.net>
Cc: Hannes Tschofenig <***@arm.com>; ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] Connection ID

Post by Hannes Tschofenig
Hi all,
some of you may have missed the TLS WG meeting last week where we had
a discussion about the Connection ID. The slides can be found at
https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sess
a-connection-id/
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-02
I am bringing this to your attention since there have been several
discussions about problems with expired NAT bindings and DTLS on this
mailing list.
Here is the good news: the TLS WG meeting participants expressed
strong consensus to adopt this work.
We are planning to advance the work rapidly given the urgency. There
are open issues, which we plan to address in the next couple of weeks.
Then, we would like to do an online interop test. If you have an
implementation please drop me a private mail.
Ciao
Hannes
PS: Note that the latest DTLS 1.3 spec now includes an optimized
record layer format, which can be used with the connection ID draft.
This leads to a smaller per packet overhead.

This is all very good.

RFC 7252 still says:

The following rules are added for matching an Acknowledgement message
or Reset message to a Confirmable message, or a Reset message to a
Non-confirmable message: The DTLS session MUST be the same, and the
epoch MUST be the same.

Apparently, we need to relax the rule about the epoch.
Should we just strike this part, or is there going to be a weaker rule?

[JLS] I would say that the session might need to be the same, but I am not sure. Something that connects the sessions would be required so say that the sessions are the same (hello connection id?). The epoch should be able to change w/o a problem.

Jim


Grüße, Carsten

_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core