Subject: [core] DTLS and Epochs

From: "weigengyu" <[email-masked]>
Date: Thu, 1 Jun 2017 23:14:14 +0800

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: "weigengyu" <[email-masked]>
Date: Fri, 2 Jun 2017 08:28:36 +0800

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