Hi,
I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when we
start a resume handshake, or if we keep the last used value, or the last
used value+1 ? I can not any clue of that in the spec.
Any idea ?
Thx
Simon
___
TLS mailing list
I'm sorry to insist, but What did you mean by transport level connection
? For me UDP was a connectionless protocol.
Simon
Le 31/07/2015 18:53, Eric Rescorla a écrit :
On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard
mailto:cont...@simonbernard.eu>> wrote:
Thx.
What did
inue
with previous epoch ?
Le 17/08/2015 16:24, Eric Rescorla a écrit :
Please see RFC 6347 S 4.2.8
-Ekr
On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard
mailto:cont...@simonbernard.eu>> wrote:
I'm sorry to insist, but What did you mean by transport level
connecti
I support adoption. It should be useful to deal with this issue at DTLS
level.
Le 03/05/2021 à 17:44, Sean Turner a écrit :
Hi!
We would like to re-run the WG adoption call for "Return Routability Check for
DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of this draft as a
Hi,
Here are the scenarios we would be interested to see covered by this CID
extension.
1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID
Hi,
We are implementing DTLS with PSK over UDP and I would like to know how
"unknown identity" and "bad psk" should be handled
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)
> If the server does not recognize the PSK ide
demonstrated
reachability by completing a cookie exchange.
Should it be OK ?
Thx again for your time.
Simon
Le 06/04/2018 à 19:26, Eric Rescorla a écrit :
On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard
mailto:cont...@simonbernard.eu>> wrote:
Hi,
We are implementing DTLS w
Hi,
In DTLS 1.2 over UDP, I would like to know what is the
recommendation about using HELLO_VERIFY_REQUEST during an abbreviated
handshake.
Should we send it all the time ? or could we avoid to send it if
SESSION ID is known ?
Thx,
Simon
___
sumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification
isn't much of an issue.
Maybe I'm missing something though.
-Ekr
On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard <mailto:cont...@simonbernard.eu>
Hi,
Should "return_routability_check" use flight retransmission [1] ?
Should the heartbeat message be re-used instead of the proposed new
message exchange?
It sounds really similar, except that if heartbeat failed we
terminate the connection and for "return_routability_check" we update
Hi,
My 2 cents, I think a kind of overview page with status about
protocols, ciphers an others would helps a lot. Something near of what
is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
This would be the page to know to be updated about security
deprecation and plan
Hi,
The RFC6347, 4.2.4 [1] say :
"3. The implementation receives the next flight of messages: if
this
is the final flight of messages, the implementation transitions to
FINISHED. If the implementation needs to send a new flight, it
transitions to the PREPARIN
This makes me think about if this is feasible/desirable to use
connection id to do load balancing.
I think about use cases where you have a cluster of server behind only
one IP address. Often traffic will be load balanced by IP.
But with UDP and Nat environment, the IP can change.
Thx to CID,
13 matches
Mail list logo
