Re: session resumption, I would like to propose the following text:
6.1. Session Resumption
When the Responder is under attack, it MAY choose to prefer previously
authenticated peers who present a session resumption [RFC 5723] ticket.
The Responder MAY require such Initiators to include a
On Feb 9, 2015, at 4:03 AM, Paul Wouters p...@nohats.ca wrote:
On Sun, 8 Feb 2015, Yaron Sheffer wrote:
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find very
useful). But the weaker clients will
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find
very useful). But the weaker clients will always lose, no matter what
POW solution we choose. This has been a problem with this proposal from
day one and
On Feb 8, 2015, at 1:20 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find very
useful). But the weaker clients will always lose, no matter what POW solution
On Feb 8, 2015, at 3:21 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Yes, of course. It just needs to verify the integrity (MAC) of the received
ticket (as easy or easier than our proposed puzzle verification), and then
the rest of the exchange is lighter-weight than a typical IKE exchange.
On Feb 8, 2015, at 1:20 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find very
useful). But the weaker clients will always lose, no matter what POW solution
On Sun, 8 Feb 2015, Yaron Sheffer wrote:
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find very
useful). But the weaker clients will always lose, no matter what POW solution
we choose. This has been a
I can see two drawbacks with this approach.
First, to make it aligned with algorithm agility, we need to
negotiate not only PRF, but also the encryption algorithm.
And the selection criteria would become more complex.
And second - it significantly increases the size of IKE_SA_INIT
response
Before I respond, here’s one more data point: I’ve compiled OpenSSL 1.0.2 for
ARM and got ~60,500 SHA-256 hashes (it’s close enough to not matter to the
result for HMAC-SHA-256) per second.
That says that assuming 1 second as the “reasonable” time to solve a puzzle, we
can expect to do about
OK, now I’ve got a chance to test on an ARM appliance (similar in power to a
2-3 year old phone, I think.
Again these are single-core results, but there’s an extra bit of badness here
in that this is a C implementation of SHA256. We could probably gain around 2
extra bits with an
Valery Smyslov writes:
You are describing a situation where the server simply has
multiple queues, I think. One for 20 bits, and probably one for
each of 19,18,17,16, and then one for all solutions 16, including
not supporting puzzles at all.
Yes, but the queues are virtual, the server
Are we going into the right direction?
Is it worth to solve the task of making
puzzle difficulties less erratic if the computing power
of clients may differ by the order of magnitude (or even magnitudes)?
Can we make the process more flexible?
For example - the server may indicate two difficulty
Hi Michael,
Can we make the process more flexible?
For example - the server may indicate two difficulty levels in
puzzle
request - the desired one and the acceptable one.
For example, the desired level is 20 bits and the acceptable level
is 16
bits.
You are
Results are actually way better, with the 4X changed into 2X. However it
seems to me that Scott's proposal is better - slightly more complex but
certainly more deterministic.
Thanks,
Yaron
On 02/02/2015 08:31 AM, Yoav Nir wrote:
The three-sigma rule applies even with a non-normal
On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote:
On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
What I would suggest is: we give the client a single puzzle, and ask it to
return 16 different solutions. Indeed each puzzle then should be 16X
And now it’s really attached.
data.xlsx
Description: MS-Excel 2007 spreadsheet
On Feb 1, 2015, at 11:45 AM, Yoav Nir ynir.i...@gmail.com wrote:
On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote:
On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Hi Yoav,
This is good, but I'm not sure if it's good enough. The ratio between
min and max (which I trust more than the mean +/- 3s rule, because
this is not a normal distribution) is consistently around 4. So if you
have to design your timeouts on a particular machine, you would still
have
computations; however, you are free to disagree).
-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer
Sent: Sunday, February 01, 2015 12:37 PM
To: Yoav Nir
Cc: IPsecME WG; Valery Smyslov
Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash
Hi Yoav,
This is good
The three-sigma rule applies even with a non-normal distribution.
Anyway, I tried the 64-key sample. Results are slightly better.
Yoav
data64.xlsx
Description: MS-Excel 2007 spreadsheet
On Feb 1, 2015, at 7:36 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Hi Yoav,
This is good, but
On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
What I would suggest is: we give the client a single puzzle, and ask it to
return 16 different solutions. Indeed each puzzle then should be 16X easier.
The nice thing is, the server should only check *one* of them, at
Valery Smyslov writes:
I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of
To clarify: I am NOT suggesting that the responder should generate 8
puzzles (8 cookies). I am suggesting that the initiator should send 8
different solutions to the same puzzle, using something like Tero's
proposal.
It is true that the execution time (a.k.a. client-side cost) will
average
*Sent:* Friday, January 30, 2015 2:41 AM
*Subject:* Re: [IPsec] DDoS puzzle: PRF vs Hash
Interesting. I’ve tried with a few different “cookies”.
Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1 PRF=…4c82f8b8 #zeros=19 time=0.025
Key=…0002ea6c PRF
: Re: [IPsec] DDoS puzzle: PRF vs Hash
Interesting. I’ve tried with a few different “cookies”.
Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1 PRF=…4c82f8b8 #zeros=19 time=0.025
Key=…0002ea6c PRF=…5faafb80 #zeros=23 time=0.250
Key
puzzle: PRF vs Hash
Interesting. I’ve tried with a few different “cookies”.
Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1 PRF=…4c82f8b8 #zeros=19 time=0.025
Key=…0002ea6c PRF=…5faafb80 #zeros=23 time=0.250
Key=…0124159c PRF=…9136e500
Hi all.
Following Valery’s suggestion, I’ve created a pull request for replacing the
puzzle mechanism:
OLD: appending a string to the cookie so that the hash of the extended string
has enough zero bits at the end.
NEW: finding a PRF key such that PRF(k, cookie) has enough zero bits at the end.
Interesting. I’ve tried with a few different “cookies”.
Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1 PRF=…4c82f8b8 #zeros=19 time=0.025
Key=…0002ea6c PRF=…5faafb80 #zeros=23 time=0.250
Key=…0124159c PRF=…9136e500 #zeros=24 time=26.013
27 matches
Mail list logo
