Re: [core] DTLS and Epochs

[Jim Schaad <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, June 8, 2017 1:18 AM
To: weigengyu <[e-mail]>
Cc: [e-mail]; 'Klaus Hartke' <[e-mail]>; Jim Schaad <[e-mail]>
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.

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:[e-mail]] On Behalf Of weigengyu
Sent: Montag, 5. Juni 2017 13:54
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; 'Klaus Hartke' <[e-mail]>
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' ; [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





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