Subject: [core] DTLS and Epochs

From: Jim Schaad <[email-masked]>
Date: Sun, 14 May 2017 21:21:44 -0700

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

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 15 May 2017 14:01:55 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 May 2017 14:49:32 +0200

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

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 15 May 2017 14:57:08 +0200

> Anything more powerful that what we have now probably requires substantial analysis.

+1

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 May 2017 08:26:50 -0700

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:

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:
> 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.
>
> 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.
>