Re: [core] DTLS and Epochs

["weigengyu" <[e-mail]>]

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



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

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