Subject: Re: [core] DTLS and Epochs

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Jun 2017 09:10:14 -0700

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:[email-masked]] 
Sent: Thursday, June 1, 2017 12:13 AM
To: Jim Schaad <[email-masked]>; 'Klaus Hartke' <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi Jim,

> 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: [email-masked]
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:[email-masked]]
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
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

On 15 May 2017 at 06:21, Jim Schaad <[email-masked]> wrote:
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Jun 2017 18:36:23 +0200

> 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 e…

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Jun 2017 10:45:26 -0700

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

[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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Jun 2017 20:38:06 -0700

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:[email-masked]] 
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi,

> 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
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; 
[email-masked]

On Jun 1, 2017, at 18:10, Jim Schaad <[email-masked]> wrote:
>
> 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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Jun 2017 21:10:14 -0700

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:[email-masked]] 
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
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

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

On Jun 1, 2017, at 18:10, Jim Schaad <[email-masked]> wrote:
> 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

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 5 Jun 2017 19:54:01 +0800

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
-----原始邮件----- 
From: Jim Schaad
Sent: Friday, June 02, 2017 12:10 PM
To: 'weigengyu'
Cc: 'Klaus Hartke' ; [email-masked]
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:[email-masked]]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi Jim,

> 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
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 11:38 AM
To: 'weigengyu' ; 'Carsten Bormann'
Cc: 'Klaus Hartke' ; [email-masked]
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:[email-masked]]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; 
[email-masked]

Jim

Grüße, Carsten

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Thu, 8 Jun 2017 08:17:33 +0000

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:[email-masked]] On Behalf Of weigengyu
Sent: Montag, 5. Juni 2017 13:54
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'Klaus Hartke' <[email-masked]>
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
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 12:10 PM
To: 'weigengyu'
Cc: 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

Jim

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Regards,

Gengyu WEI

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; 
[email-masked]

Jim

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Jun 2017 11:08:35 +0200

> 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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 8 Jun 2017 13:12:50 -0700

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:[email-masked]] 
Sent: Thursday, June 8, 2017 1:18 AM
To: weigengyu <[email-masked]>
Cc: [email-masked]; 'Klaus Hartke' <[email-masked]>; Jim Schaad <[email-masked]>
Subject: RE: [core] DTLS and Epochs

Hi all,

 Achim Kraus

(INST/ECS4) 

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

Hi Jim,

Regards,

Gengyu WEI
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 12:10 PM
To: 'weigengyu'
Cc: 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

Jim

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 8:58 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi Jim,

Regards,

Gengyu WEI

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 5:27 PM
To: Jim Schaad <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: 'Klaus Hartke' <[email-masked]>; [email-masked]
Subject: Re: [core] DTLS and Epochs

Hi,

Regards,

Gengyu WEI
-----原始邮件-----
From: Jim Schaad
Sent: Friday, June 02, 2017 1:45 AM
To: 'Carsten Bormann'
Cc: 'weigengyu' ; 'Klaus Hartke' ; [email-masked]
Subject: RE: [core] DTLS and Epochs

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, June 1, 2017 9:36 AM
To: Jim Schaad <[email-masked]>
Cc: weigengyu <[email-masked]>; Klaus Hartke <[email-masked]>; 
[email-masked]

Jim

Grüße, Carsten

---

From: Simon Bernard <[email-masked]>
Date: Fri, 9 Jun 2017 12:35:14 +0200

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)<[email-masked]>  wrote:

---

From: "weigengyu" <[email-masked]>
Date: Sat, 10 Jun 2017 00:23:49 +0800

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

From: Simon Bernard 
Sent: Friday, June 09, 2017 6:35 PM
To: Carsten Bormann ; Kraus Achim (INST/ECS4) 
Cc: [email-masked] 
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.

Simon

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

Grüße, Carsten

--------------------------------------------------------------------------------
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Simon Bernard <[email-masked]>
Date: Fri, 9 Jun 2017 19:22:58 +0200

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 :
> 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.
> *From:* Simon Bernard <mailto:[email-masked]>
> *Sent:* Friday, June 09, 2017 6:35 PM
> *To:* Carsten Bormann <mailto:[email-masked]> ; Kraus Achim (INST/ECS4) 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [core] DTLS and Epochs
>
> Hi,
>
> 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".
>
> 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 : 
>   I initially think about that for observe request, but maybe it can 
> be generalized to all request/response correlation.
>
>> On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4)mailto:[email-masked]  wrote:
> ------------------------------------------------------------------------

---

From: "weigengyu" <[email-masked]>
Date: Sat, 10 Jun 2017 01:43:43 +0800

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
-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, June 08, 2017 5:08 PM
To: Kraus Achim (INST/ECS4)
Cc: [email-masked]
Subject: Re: [core] DTLS and Epochs

On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4) <[email-masked]> 
wrote:
> 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.

— retain the desirable security properties of the current restrictive 
definition

(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

---

From: "weigengyu" <[email-masked]>
Date: Sat, 10 Jun 2017 02:25:55 +0800

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

From: Simon Bernard 
Sent: Saturday, June 10, 2017 1:22 AM
To: weigengyu ; Carsten Bormann ; Kraus Achim (INST/ECS4) 
Cc: [email-masked] 
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.

  Hi all,

  Regards,

  Gengyu WEI

  From: Simon Bernard 

  Hi,

  Simon

Grüße, Carsten

------------------------------------------------------------------------------
  _______________________________________________
  core mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/core