[core] DTLS and Epochs

Discussion:

Jim Schaad

2017-05-15 04:21:44 UTC

I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand. I did not see any messages in
the mailing list that dealt with this so I would like to get an explanation
if possible.

RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the same. I
can understand the reasoning behind the id and session being the same,
however I am unsure of the reason that the epoch would need to be the same
as well. I cannot see of a reason why the epoch should matter. The
security session is still the same. I could understand that there would be
a reason to kill an association if additional client or server
authentication information had been passed along, but while that would
change the epoch, an epoch can change just because enough messages have been
sent over the pipe.

Can somebody please explain the reasoning to me.

Jim

Klaus Hartke

2017-05-15 12:01:55 UTC

Permalink

Hi Jim,

the requirement was added for the case that the epoch changes due to
client or server authentication.

Example:

1. A client connects to a server using DTLS. The server
authenticates with a server certificate; the client
is unauthenticated.

2. The client sends a request that requires the client
to be authenticated.

3. The server requests the client to authenticate.

4. The client authenticates with a client certificate;
a new epoch starts.

5. The server processes the request, assuming it comes
from the now authenticated client. Oops!

Requiring that the request is sent in the same epoch as the response
prevents this. It seems the language in the RFC was made too broad
when trying to say that, though. An erratum could make it more
precise.

Klaus

Post by Jim Schaad
I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand. I did not see any messages in
the mailing list that dealt with this so I would like to get an explanation
if possible.
RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the same. I
can understand the reasoning behind the id and session being the same,
however I am unsure of the reason that the epoch would need to be the same
as well. I cannot see of a reason why the epoch should matter. The
security session is still the same. I could understand that there would be
a reason to kill an association if additional client or server
authentication information had been passed along, but while that would
change the epoch, an epoch can change just because enough messages have been
sent over the pipe.
Can somebody please explain the reasoning to me.
Jim

Carsten Bormann

2017-05-15 12:49:32 UTC

Permalink

Hi Jim,

Klaus described one of several conceivable ways in which an epoch change might change the security state enough that simply ignoring it at the application layer creates problems.

When we designed CoAP, we were thinking about ways to handle this set of issues.
In the end, DTSTTCPW won.
(“Work” here means “is arguably secure, and still doesn’t completely break secure applications”.)

Anything more powerful that what we have now probably requires substantial analysis.
I would not be comfortable with fixing this at the errata level — the above decision very much was not an erratum.

I could imagine that we fix this together with providing the well-requested feature of session resumption after an IP address changed.

Grüße, Carsten

Klaus Hartke

2017-05-15 12:57:08 UTC

Permalink

Post by Carsten Bormann
Anything more powerful that what we have now probably requires substantial analysis.

+1

Klaus

Jim Schaad

2017-05-15 15:26:50 UTC

Permalink

At this point I would have to ask why similar language is not in the TLS draft as well.

Note however that this has nothing to do with epochs and everything to do with additional authentication. I think that an errata is called for to clarify this.

It turns out that my DTLS libraries are unable to give me the fact that an epoch has changed, but would know if additional authentication was done. Two very different operations.

Jim

-----Original Message-----
From: Klaus Hartke [mailto:***@tzi.org]
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad <***@augustcellars.com>
Cc: ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] DTLS and Epochs

Hi Jim,

the requirement was added for the case that the epoch changes due to client or server authentication.

Example:

1. A client connects to a server using DTLS. The server
authenticates with a server certificate; the client
is unauthenticated.

2. The client sends a request that requires the client
to be authenticated.

3. The server requests the client to authenticate.

4. The client authenticates with a client certificate;
a new epoch starts.

5. The server processes the request, assuming it comes
from the now authenticated client. Oops!

Requiring that the request is sent in the same epoch as the response prevents this. It seems the language in the RFC was made too broad when trying to say that, though. An erratum could make it more precise.

Klaus

Post by Jim Schaad
I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand. I did not see any messages
in the mailing list that dealt with this so I would like to get an
explanation if possible.
RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the
same. I can understand the reasoning behind the id and session being
the same, however I am unsure of the reason that the epoch would need
to be the same as well. I cannot see of a reason why the epoch should
matter. The security session is still the same. I could understand
that there would be a reason to kill an association if additional
client or server authentication information had been passed along, but
while that would change the epoch, an epoch can change just because
enough messages have been sent over the pipe.
Can somebody please explain the reasoning to me.
Jim

Jim Schaad

2017-06-01 16:10:14 UTC

Permalink

Please note - I did not say that the epoch was not changed, I said that it does not tell me that the epoch has changed. From a strictly security point of view there is no reason to do so if, for example, the epoch changed just because the key was rolled over.

Jim

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 12:13 AM
To: Jim Schaad <***@augustcellars.com>; 'Klaus Hartke' <***@tzi.org>
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Post by Jim Schaad
It turns out that my DTLS libraries are unable to give me the fact
that an epoch has changed, but would know if additional authentication
was done. Two very different operations.

It is not known what libraries are used.
Here we use Califorium fore CoAP/DTLS/UDP/IP and CoAP/DTLS/SMS tests.

The epoch is changed after receiveing ChangeCipherSpec at the server side.

Regards

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Monday, May 15, 2017 11:26 PM
To: 'Klaus Hartke'
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

At this point I would have to ask why similar language is not in the TLS draft as well.

Note however that this has nothing to do with epochs and everything to do with additional authentication. I think that an errata is called for to clarify this.

It turns out that my DTLS libraries are unable to give me the fact that an epoch has changed, but would know if additional authentication was done.
Two very different operations.

Jim

-----Original Message-----
From: Klaus Hartke [mailto:***@tzi.org]
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad <***@augustcellars.com>
Cc: ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] DTLS and Epochs

Hi Jim,

the requirement was added for the case that the epoch changes due to client or server authentication.

Example:

1. A client connects to a server using DTLS. The server
authenticates with a server certificate; the client
is unauthenticated.

2. The client sends a request that requires the client
to be authenticated.

3. The server requests the client to authenticate.

4. The client authenticates with a client certificate;
a new epoch starts.

5. The server processes the request, assuming it comes
from the now authenticated client. Oops!

Requiring that the request is sent in the same epoch as the response prevents this. It seems the language in the RFC was made too broad when trying to say that, though. An erratum could make it more precise.

Klaus

Post by Jim Schaad
I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand. I did not see any messages
in the mailing list that dealt with this so I would like to get an
explanation if possible.
RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the
same. I can understand the reasoning behind the id and session being
the same, however I am unsure of the reason that the epoch would need
to be the same as well. I cannot see of a reason why the epoch should
matter. The security session is still the same. I could understand
that there would be a reason to kill an association if additional
client or server authentication information had been passed along, but
while that would change the epoch, an epoch can change just because
enough messages have been sent over the pipe.
Can somebody please explain the reasoning to me.
Jim

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

Carsten Bormann

2017-06-01 16:36:23 UTC

Permalink

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said that it does not tell me that the epoch has changed. From a strictly security point of view there is no reason to do so if, for example, the epoch changed just because the key was rolled over.

Right, and the question for me is: How do we get from the overly restrictive spec in 7252 to something that is still secure and can be supported by TLS libraries that are out there.

Grüße, Carsten

Jim Schaad

2017-06-01 17:45:26 UTC

Permalink

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <***@augustcellars.com>
Cc: weigengyu <***@bupt.edu.cn>; Klaus Hartke <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Right, and the question for me is: How do we get from the overly restrictive spec in 7252 to something that is still secure and can be supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally thought that I would file an errata, but I do not believe that is a correct use of the errata system. It is used for things which are unclear or technically wrong. This is not wrong, just misguided. It might be easiest to just do a delta RFC unless there is a good number of errata that need to be rolled into an updated document.

Jim

Grüße, Carsten

Jim Schaad

2017-06-02 03:38:06 UTC

Permalink

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate requirement that all messages MUST be responded to using the epoch value. Without the knowledge that the epoch value has changed this is not enforceable on either end.

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said
that it does not tell me that the epoch has changed.
From a strictly security point of view there is no reason to do so if,
for example, the epoch changed just because the key was rolled over.

Why the epoch changed event must tell "me", i.e. the upper layer entity?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <***@augustcellars.com>
Cc: weigengyu <***@bupt.edu.cn>; Klaus Hartke <***@tzi.org>;
***@ietf.org
Subject: Re: [core] DTLS and Epochs

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said that it
does not tell me that the epoch has changed. From a strictly security
point of view there is no reason to do so if, for example, the epoch
changed just because the key was rolled over.

Right, and the question for me is: How do we get from the overly
restrictive spec in 7252 to something that is still secure and can be
supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally
thought that I would file an errata, but I do not believe that is a correct
use of the errata system. It is used for things which are unclear or
technically wrong. This is not wrong, just misguided. It might be easiest
to just do a delta RFC unless there is a good number of errata that need to
be rolled into an updated document.

Jim

Grüße, Carsten

Jim Schaad

2017-06-02 04:10:14 UTC

Permalink

My intention is to get rid of the requirement since it makes no sense. That is what the message I sent to Carsten was about. What is the best process for doing so.

Jim

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Thank you for your explainations.

Post by Jim Schaad
Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate
requirement that all messages MUST be responded to using the epoch value.

It is really unfortunate requirements that the application protocol is forced to be tied with the lower-layer variable.
Is there an intension to creat a cross-layer mechanim?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 11:38 AM
To: 'weigengyu' ; 'Carsten Bormann'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate requirement that all messages MUST be responded to using the epoch value. Without the knowledge that the epoch value has changed this is not enforceable on either end.

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said
that it does not tell me that the epoch has changed.
From a strictly security point of view there is no reason to do so if,
for example, the epoch changed just because the key was rolled over.

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said
that it does not tell me that the epoch has changed. From a strictly
security point of view there is no reason to do so if, for example,
the epoch changed just because the key was rolled over.

weigengyu

2017-06-05 11:54:01 UTC

Permalink

Hi Jim,

I present our opinions about epoch changes.
In weekend we (my studens: Mr. Haihai REN and Jiantong LI) reviewed the
source code of Cf. CoAP and RFC7252 9.1.

Based on the text of RFC7252 and the layered protocol concepts,
it may be a problem to tie the CoAP message with DTLS epoch, as you pointed.
It may be a problem how the CoAP entity knows the DTLS epoch changes.

But, such a problem has never be happened in our previous works. Why?
Reviewing Cf. CoAP's source code, it becomes clear that the CoAP entity
would read the DTLS epoch when it starts sending messages.
In this specific implementation, the CoAP entity has the ability to read
DTLS epoch of another object which is a variable of another layer in
protocol concepts.

In Cf.CoAP source code, when the CoAP entity needs to send messages,
it invokes the DTLS entity to work, i.e. to do server and client
authentifications;
then the client sends ChangeChipherSpec, and server' Finish, the DTLS's
epoch change. Actually the epoch is plus one.
Then the CoAP entity would get DTLS epoch and begin to send CoAP messages
over DTLS Record.
It is clear that the CoAP entity could get the new epoch in Cf. CoAP.

It is known that Cf. CoAP is a specific implementation in which getting
epoch is not a tough work.
It seems that it is not a critical matter in software implementation as in
protocol concept.

Probably, statements in RFC7252 should be clear enough to tell that the CoAP
getting DTLS epoch is a cross-layer operation.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 12:10 PM
To: 'weigengyu'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

My intention is to get rid of the requirement since it makes no sense. That
is what the message I sent to Carsten was about. What is the best process
for doing so.

Jim

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Thank you for your explainations.

Post by Jim Schaad
Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate
requirement that all messages MUST be responded to using the epoch value.

It is really unfortunate requirements that the application protocol is
forced to be tied with the lower-layer variable.
Is there an intension to creat a cross-layer mechanim?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 11:38 AM
To: 'weigengyu' ; 'Carsten Bormann'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate requirement
that all messages MUST be responded to using the epoch value. Without the
knowledge that the epoch value has changed this is not enforceable on either
end.

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said
that it does not tell me that the epoch has changed.
From a strictly security point of view there is no reason to do so if,
for example, the epoch changed just because the key was rolled over.

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said
that it does not tell me that the epoch has changed. From a strictly
security point of view there is no reason to do so if, for example,
the epoch changed just because the key was rolled over.

Right, and the question for me is: How do we get from the overly
restrictive spec in 7252 to something that is still secure and can be
supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally
thought that I would file an errata, but I do not believe that is a correct
use of the errata system. It is used for things which are unclear or
technically wrong. This is not wrong, just misguided. It might be easiest
to just do a delta RFC unless there is a good number of errata that need to
be rolled into an updated document.

Jim

Grüße, Carsten

Kraus Achim (INST/ECS4)

2017-06-08 08:17:33 UTC

Permalink

Hi all,

Reviewing Cf. CoAP's source code, it becomes clear that the CoAP entity would read the DTLS epoch when it starts sending messages.

Scandium (java DTLS implementation, subproject in californium, java CoAP implementation) was implemented to be used for CoAP, therefore it was extended to check the epoch. But, if the (D)TLS implementation doesn't provide this information, you can't check it. That's the issue others got aware.

And there is still a pitfall: you can only check the epoch number! So currently, if an initial DTLS handshake is finished you get a session ID (say S12345), a selected ciphersuite (say CS_XYZ), and the epoch (with number 1). A new handshake would get a new session ID (S6789) and could be detected. But for a resuming handshake, this will end-up in the same session ID and same epoch-number.

It's still unclear to me, if this should be considered to be the "same epoch" in the meaning of RFC7252.

I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but I could get clarification on that.

Mit freundlichen Grüßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn

-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of weigengyu
Sent: Montag, 5. Juni 2017 13:54
To: Jim Schaad <***@augustcellars.com>
Cc: ***@ietf.org; 'Klaus Hartke' <***@tzi.org>
Subject: Re: [core] DTLS and Epochs

Hi Jim,

I present our opinions about epoch changes.
In weekend we (my studens: Mr. Haihai REN and Jiantong LI) reviewed the source code of Cf. CoAP and RFC7252 9.1.

Based on the text of RFC7252 and the layered protocol concepts, it may be a problem to tie the CoAP message with DTLS epoch, as you pointed.
It may be a problem how the CoAP entity knows the DTLS epoch changes.

But, such a problem has never be happened in our previous works. Why?
Reviewing Cf. CoAP's source code, it becomes clear that the CoAP entity would read the DTLS epoch when it starts sending messages.
In this specific implementation, the CoAP entity has the ability to read DTLS epoch of another object which is a variable of another layer in protocol concepts.

In Cf.CoAP source code, when the CoAP entity needs to send messages, it invokes the DTLS entity to work, i.e. to do server and client authentifications; then the client sends ChangeChipherSpec, and server' Finish, the DTLS's epoch change. Actually the epoch is plus one.
Then the CoAP entity would get DTLS epoch and begin to send CoAP messages over DTLS Record.
It is clear that the CoAP entity could get the new epoch in Cf. CoAP.

It is known that Cf. CoAP is a specific implementation in which getting epoch is not a tough work.
It seems that it is not a critical matter in software implementation as in protocol concept.

Probably, statements in RFC7252 should be clear enough to tell that the CoAP getting DTLS epoch is a cross-layer operation.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 12:10 PM
To: 'weigengyu'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

My intention is to get rid of the requirement since it makes no sense. That
is what the message I sent to Carsten was about. What is the best process
for doing so.

Jim

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Thank you for your explainations.

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate
requirement that all messages MUST be responded to using the epoch value.

It is really unfortunate requirements that the application protocol is
forced to be tied with the lower-layer variable.
Is there an intension to creat a cross-layer mechanim?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 11:38 AM
To: 'weigengyu' ; 'Carsten Bormann'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate requirement
that all messages MUST be responded to using the epoch value. Without the
knowledge that the epoch value has changed this is not enforceable on either
end.

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

Right, and the question for me is: How do we get from the overly
restrictive spec in 7252 to something that is still secure and can be
supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally
thought that I would file an errata, but I do not believe that is a correct
use of the errata system. It is used for things which are unclear or
technically wrong. This is not wrong, just misguided. It might be easiest
to just do a delta RFC unless there is a good number of errata that need to
be rolled into an updated document.

Jim

Grüße, Carsten

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

Carsten Bormann

2017-06-08 09:08:35 UTC

Permalink

Post by Kraus Achim (INST/ECS4)
It's still unclear to me, if this should be considered to be the "same epoch" in the meaning of RFC7252.
I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but I could get clarification on that.

I think that we can agree that the current definition is
— not fully clear
— unrealistic in certain implementation environments (so it may not actually be implemented)
— unnecessarily restrictive.

Now the next question is what definition would
— make sense from an implementers’ point of view
— not be unnecessarily restrictive
— retain the desirable security properties of the current restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isn’t fully baked yet).

(And then we have to figure out the process for fixing it — that is not too hard once we know the extent of the change that needs to me made. E.g., an RFC updating RFC 7252.)

Grüße, Carsten

Simon Bernard

2017-06-09 10:35:14 UTC

Permalink

Hi,

We faced this issue when we tried to make observe work behind NAT in
a LWM2M context.

My understanding is "same epoch" means implicitly "same DTLS
connection too" which is a real issue in dynamic IP address environment
(as DTLS connection is identified by IP address). "same epoch" means "no
TLS renegociation".

IMHO, "same epoch/connection" should be replaced by "same identity"
(PSK identity for PSK, public key for RPK, CN for certificate) for
authenticated peer or "same session" for non-authenticated. In case you
want to allow TLS renegotiation you should add "same cipher" too. But
TLS renegotiation seems to be not advisable for DTLS 1.2 :
https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3
last time I looked at it.

I initially think about that for observe request, but maybe it can be
generalized to all request/response correlation.

Here some discussion about this idea :
- https://www.ietf.org/mail-archive/web/core/current/msg08019.html
- https://www.ietf.org/mail-archive/web/core/current/msg08004.html

Simon

Post by Carsten Bormann

I think that we can agree that the current definition is
â not fully clear
â unrealistic in certain implementation environments (so it may not actually be implemented)
â unnecessarily restrictive.
Now the next question is what definition would
â make sense from an implementersâ point of view
â not be unnecessarily restrictive
â retain the desirable security properties of the current restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isnât fully baked yet).
(And then we have to figure out the process for fixing it â that is not too hard once we know the extent of the change that needs to me made. E.g., an RFC updating RFC 7252.)
GrÃŒÃe, Carsten
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

weigengyu

2017-06-09 16:23:49 UTC

Permalink

Hi all,

In DTLS there is a formal to calculate a cookie:
Cookie = HMAC(Secret, Client-IP, Client-Parameters)
Cookie is related to the Client-IP address and used during DTLS handshakes.

If the IP address is changed just during handshanke stage, the handshake will not continue.
Then it must start a new DTLS shandshake with the new IP address.

If the IP address is changed during DTLS record delivery after a successfule handshake,
the DTLS record carried in a new IP address would be treated to belong to a different DTLS association.
In a receiving side with an unchanged IP address, the DTLS record would be regarded as an invalide one to be discarded according to RFC6347.

So, for CoAP Observe if the IP address is changed, a new DTLS association must be establishied.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Simon Bernard
Sent: Friday, June 09, 2017 6:35 PM
To: Carsten Bormann ; Kraus Achim (INST/ECS4)
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

We faced this issue when we tried to make observe work behind NAT in a LWM2M context.

My understanding is "same epoch" means implicitly "same DTLS connection too" which is a real issue in dynamic IP address environment (as DTLS connection is identified by IP address). "same epoch" means "no TLS renegociation".

IMHO, "same epoch/connection" should be replaced by "same identity" (PSK identity for PSK, public key for RPK, CN for certificate) for authenticated peer or "same session" for non-authenticated. In case you want to allow TLS renegotiation you should add "same cipher" too. But TLS renegotiation seems to be not advisable for DTLS 1.2 : https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3 last time I looked at it.

I initially think about that for observe request, but maybe it can be generalized to all request/response correlation.

Here some discussion about this idea :
- https://www.ietf.org/mail-archive/web/core/current/msg08019.html
- https://www.ietf.org/mail-archive/web/core/current/msg08004.html

Simon

Le 08/06/2017 Ã 11:08, Carsten Bormann a Ã©crit :

On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4) mailto:***@bosch-si.com wrote:
It's still unclear to me, if this should be considered to be the "same epoch" in the meaning of RFC7252.

I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but I could get clarification on that.
I think that we can agree that the current definition is
â not fully clear
â unrealistic in certain implementation environments (so it may not actually be implemented)
â unnecessarily restrictive.

Now the next question is what definition would
â make sense from an implementersâ point of view
â not be unnecessarily restrictive
â retain the desirable security properties of the current restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isnât fully baked yet).

(And then we have to figure out the process for fixing it â that is not too hard once we know the extent of the change that needs to me made. E.g., an RFC updating RFC 7252.)

GrÃŒÃe, Carsten

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

--------------------------------------------------------------------------------

Simon Bernard

2017-06-09 17:22:58 UTC

Permalink

This is the point. We agree that a new DTLS association must be
established. It's ok as generally this is the peer which has a dynamic
IP which will initiate this handshake. This is not optimal but this is
ok (some solution is explored to optimize that like the connection ID
proposed by Fossati draft-fossati-tls-iot-optimizations-00)

Let's suppose a peer with dynamic IP address is observed and send
notification. When its IP address changes a new observe relation should
also be established to respect the same epoch/same connection
constraint. If we don't, observe notifications should be dropped. The
issue : this time this is not the peer with the dynamic IP address
which must initiate the relation. Another issue : NAT timeout is
sometime around 60s so for some use case we need to re-established
observe relation each time we receive a notification ? This is not the
spirit of the observe feature.

Post by Kraus Achim (INST/ECS4)
Hi all,
Cookie = HMAC(Secret, Client-IP, Client-Parameters)
Cookie is related to the Client-IP address and used during DTLS handshakes.
If the IP address is changed just during handshanke stage, the
handshake will not continue.
Then it must start a new DTLS shandshake with the new IP address.
If the IP address is changed during DTLS record delivery after a successfule handshake,
the DTLS record carried in a new IP address would be treated to belong
to a different DTLS association.
In a receiving side with an unchanged IP address, the DTLS record
would be regarded as an invalide one to be discarded according to
RFC6347.
So, for CoAP Observe if the IP address is changed, a new DTLS
association must be establishied.
Regards,
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
*Sent:* Friday, June 09, 2017 6:35 PM
*Subject:* Re: [core] DTLS and Epochs
Hi,
We faced this issue when we tried to make observe work behind NAT in a LWM2M context.
My understanding is "same epoch" means implicitly "same DTLS
connection too" which is a real issue in dynamic IP address
environment (as DTLS connection is identified by IP address). "same
epoch" means "no TLS renegociation".
IMHO, "same epoch/connection" should be replaced by "same identity"
(PSK identity for PSK, public key for RPK, CN for certificate) for
authenticated peer or "same session" for non-authenticated. In case
you want to allow TLS renegotiation you should add "same cipher" too.
https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3
last time I looked at it.
I initially think about that for observe request, but maybe it can
be generalized to all request/response correlation.
- https://www.ietf.org/mail-archive/web/core/current/msg08019.html
- https://www.ietf.org/mail-archive/web/core/current/msg08004.html
Simon

Post by Carsten Bormann

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

weigengyu

2017-06-09 18:25:55 UTC

Permalink

Hi,

The issue : this time this is not the peer with the dynamic IP address which must initiate the relation.

As the IP address change at any side will invoke to establish a new DTLS association,
the CoAP Observe entity should handle One Observation over different DTLS associations.
In current Observe standard context, One Observation is implied to be delivered only over one-unchanged DTLS.

Another issue : NAT timeout is sometime around 60s so for some use case we need to re-established observe relation each time we receive a notification ?
This is not the spirit of the observe feature.

When the IP address is changed, it is Inevitable to establish a new DTLS association, the CoAP Observer entity have to handle this change to keep the observe relations,
something as mentioned the connection ID proposed by Fossati draft-fossati-tls-iot-optimizations-00.

Making the spirit of the observe feature available, the CoAP client and CoAP server needs to have some abilities:
1. to handle to establish a new DTLS association when IP address is changed;
2. to keep and understand an Observe relationship by some Identities;
3. to deliver the same Observation (Notifications) over different DTLS associations.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Simon Bernard
Sent: Saturday, June 10, 2017 1:22 AM
To: weigengyu ; Carsten Bormann ; Kraus Achim (INST/ECS4)
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

This is the point. We agree that a new DTLS association must be established. It's ok as generally this is the peer which has a dynamic IP which will initiate this handshake. This is not optimal but this is ok (some solution is explored to optimize that like the connection ID proposed by Fossati draft-fossati-tls-iot-optimizations-00)

Let's suppose a peer with dynamic IP address is observed and send notification. When its IP address changes a new observe relation should also be established to respect the same epoch/same connection constraint. If we don't, observe notifications should be dropped. The issue : this time this is not the peer with the dynamic IP address which must initiate the relation. Another issue : NAT timeout is sometime around 60s so for some use case we need to re-established observe relation each time we receive a notification ? This is not the spirit of the observe feature.

Le 09/06/2017 Ã 18:23, weigengyu a Ã©crit :

Hi all,

In DTLS there is a formal to calculate a cookie:
Cookie = HMAC(Secret, Client-IP, Client-Parameters)
Cookie is related to the Client-IP address and used during DTLS handshakes.

If the IP address is changed just during handshanke stage, the handshake will not continue.
Then it must start a new DTLS shandshake with the new IP address.

If the IP address is changed during DTLS record delivery after a successfule handshake,
the DTLS record carried in a new IP address would be treated to belong to a different DTLS association.
In a receiving side with an unchanged IP address, the DTLS record would be regarded as an invalide one to be discarded according to RFC6347.

So, for CoAP Observe if the IP address is changed, a new DTLS association must be establishied.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Simon Bernard
Sent: Friday, June 09, 2017 6:35 PM
To: Carsten Bormann ; Kraus Achim (INST/ECS4)
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

We faced this issue when we tried to make observe work behind NAT in a LWM2M context.

My understanding is "same epoch" means implicitly "same DTLS connection too" which is a real issue in dynamic IP address environment (as DTLS connection is identified by IP address). "same epoch" means "no TLS renegociation".

IMHO, "same epoch/connection" should be replaced by "same identity" (PSK identity for PSK, public key for RPK, CN for certificate) for authenticated peer or "same session" for non-authenticated. In case you want to allow TLS renegotiation you should add "same cipher" too. But TLS renegotiation seems to be not advisable for DTLS 1.2 : https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3 last time I looked at it.

I initially think about that for observe request, but maybe it can be generalized to all request/response correlation.

Here some discussion about this idea :
- https://www.ietf.org/mail-archive/web/core/current/msg08019.html
- https://www.ietf.org/mail-archive/web/core/current/msg08004.html

Simon

Le 08/06/2017 Ã 11:08, Carsten Bormann a Ã©crit :

On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4) mailto:***@bosch-si.com wrote:
It's still unclear to me, if this should be considered to be the "same epoch" in the meaning of RFC7252.

I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but I could get clarification on that.
I think that we can agree that the current definition is
â not fully clear
â unrealistic in certain implementation environments (so it may not actually be implemented)
â unnecessarily restrictive.

Now the next question is what definition would
â make sense from an implementersâ point of view
â not be unnecessarily restrictive
â retain the desirable security properties of the current restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isnât fully baked yet).

(And then we have to figure out the process for fixing it â that is not too hard once we know the extent of the change that needs to me made. E.g., an RFC updating RFC 7252.)

GrÃŒÃe, Carsten

weigengyu

2017-06-09 17:43:43 UTC

Permalink

Hi,

CoAP will work by current RFC7252 context.

The epoch would be changed if IP address is changed because the DTLS client
and server must start a new DTLS association.
If the IP address is changed just after a CON message is sent out, an ACK or
RST will not be precessoced properly.
Then a new DTLS association will be establishied under the CoAP.
After that, the "repeated" CON message must be treated as a new CON message.

It is a new CON message sent over a new DTLS association with a epoch
according to RFC7252 9.1.1,
"A message is the same when it is sent within the same DTLS session
and same epoch and has the same Message ID."
The ACK or RST will use the new epoch over the new DTLS association.
CoAP goes into the normal message exchanges' stage.

Suppose that the epoch is changed while the IP address is the same.
The epoch could be changed only during DTLS handshakes before CoAP message
is sent.

CoAP Observe is affected if the IP address is changed.
The CoAP Obsever needs to have an ablity to handle an Observation to the
same resource over different DTLS associations when the IP address is
changed.

So, I think that we can agree that the current definition is
— not fully clear

It would be better to add more explanations about how the CoAP entity to
handle such exceptions in RFC7252.
We wish to retain the desirable security properties of the current
restrictive definition.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Carsten Bormann
Sent: Thursday, June 08, 2017 5:08 PM
To: Kraus Achim (INST/ECS4)
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Post by Kraus Achim (INST/ECS4)
It's still unclear to me, if this should be considered to be the "same
epoch" in the meaning of RFC7252.
I pointed to that last summer
(https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but I
could get clarification on that.

I think that we can agree that the current definition is
— not fully clear
— unrealistic in certain implementation environments (so it may not
actually be implemented)
— unnecessarily restrictive.

Now the next question is what definition would
— make sense from an implementers’ point of view
— not be unnecessarily restrictive
— retain the desirable security properties of the current restrictive
definition
- be clear
- maybe also make sense for DTLS 1.3 (which isn’t fully baked yet).

(And then we have to figure out the process for fixing it — that is not too
hard once we know the extent of the change that needs to me made. E.g., an
RFC updating RFC 7252.)

Grüße, Carsten

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

Jim Schaad

2017-06-08 20:12:50 UTC

Permalink

Both your message and the one from Hannes that you referred to bring up some rather interesting questions.

From my original reading of the CoAP documents, I would say that a resumption establishes both a new session and a new epoch. The keys are different and thus it is not the same epoch. One of the potential problems is that you can resume a new session but keep the current session so it gets slightly ambiguous about what should be done.

The idea of doing a resumption to a different address and expecting things to be the same is a very strange, but possibly correct idea. I would agree that if you do a resumption then an Observe relationship really should be preserved. This might imply information that needs to be placed in resumption tickets but I would need to sit down and spend some time doing thought and design before I would be willing to commit to such an approach.

Jim

-----Original Message-----
From: Kraus Achim (INST/ECS4) [mailto:***@bosch-si.com]
Sent: Thursday, June 8, 2017 1:18 AM
To: weigengyu <***@vip.sina.com>
Cc: ***@ietf.org; 'Klaus Hartke' <***@tzi.org>; Jim Schaad <***@augustcellars.com>
Subject: RE: [core] DTLS and Epochs

Hi all,

Reviewing Cf. CoAP's source code, it becomes clear that the CoAP entity would read the DTLS epoch when it starts sending messages.

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate
requirement that all messages MUST be responded to using the epoch value.

It is really unfortunate requirements that the application protocol is
forced to be tied with the lower-layer variable.
Is there an intension to creat a cross-layer mechanim?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 11:38 AM
To: 'weigengyu' ; 'Carsten Bormann'
Cc: 'Klaus Hartke' ; ***@ietf.org
Subject: RE: [core] DTLS and Epochs

Section 9.1.1 of RFC 7252 in paragraph 2 has the unfortunate requirement
that all messages MUST be responded to using the epoch value. Without the
knowledge that the epoch value has changed this is not enforceable on either
end.

-----Original Message-----
From: weigengyu [mailto:***@bupt.edu.cn]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <***@augustcellars.com>; 'Carsten Bormann' <***@tzi.org>
Cc: 'Klaus Hartke' <***@tzi.org>; ***@ietf.org
Subject: Re: [core] DTLS and Epochs

Hi,

Right, and the question for me is: How do we get from the overly
restrictive spec in 7252 to something that is still secure and can be
supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally
thought that I would file an errata, but I do not believe that is a correct
use of the errata system. It is used for things which are unclear or
technically wrong. This is not wrong, just misguided. It might be easiest
to just do a delta RFC unless there is a good number of errata that need to
be rolled into an updated document.

Jim

Grüße, Carsten

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

weigengyu

2017-06-02 00:28:36 UTC

Permalink

Hi,

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said that it
does not tell me that the epoch has changed.
From a strictly security point of view there is no reason to do so if, for
example, the epoch changed just because the key was rolled over.

Post by Jim Schaad
Please note - I did not say that the epoch was not changed, I said that it
does not tell me that the epoch has changed. From a strictly security
point of view there is no reason to do so if, for example, the epoch
changed just because the key was rolled over.

Right, and the question for me is: How do we get from the overly
restrictive spec in 7252 to something that is still secure and can be
supported by TLS libraries that are out there.

[JLS] I believe that the only way is to do an update to 7252. I originally
thought that I would file an errata, but I do not believe that is a correct
use of the errata system. It is used for things which are unclear or
technically wrong. This is not wrong, just misguided. It might be easiest
to just do a delta RFC unless there is a good number of errata that need to
be rolled into an updated document.

Jim

Grüße, Carsten