Hi,
I'm still wondering, why the "clashing" calculations (section 4) are only based
on the number of clients and not also on the length of the hash chain.
As I understood the hash chain, the DTLS server and client calculates a list of
CIDs. Though the client chose one, the server has to prepare
Thanks for pointing out the line in Appendix D.1. I also agree that the
proposal requires no changes to the current 1.3 specification, which is very
much a point in its favor.
I don’t think there is a desired action from the TLS-WG. The goal is simply to
have a document that other implementers
Isn’t possible to achieve the goals of this proposal without re-using DH
secrets?
For example, let DH_secret = KDF ( monitoring_key, server.hello ,
client.hello), or something similar. Ideally, the monitoring_key should be
updated frequently as possible (while keeping it synchronized).
From:
> Isn’t possible to achieve the goals of this proposal without re-using DH
> secrets?
> For example, let DH_secret = KDF ( monitoring_key, server.hello ,
> client.hello), or something similar. Ideally, the monitoring_key should be
> updated frequently as possible (while keeping it synchronized
Hi Dave,
We are wondering because of this piece of text from the RFC EDITOR just above
paragraph 4.1.4 on Hello Retry Request:
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft
versions (see Section 4.2.1.1) of this specification SHOULD NOT implement this
mechanism on
This paragraph refers to the anti-downgrade mechanism described in 4.1.3.
-Ekr
On Wed, Nov 9, 2016 at 6:56 AM, Roel Peeters
wrote:
> Hi Dave,
>
> We are wondering because of this piece of text from the RFC EDITOR just
> above paragraph 4.1.4 on Hello Retry Request:
>
> RFC EDITOR: PLEASE REMOV
