Re: [core] DTLS and Epochs

[Jim Schaad <[e-mail]>]

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