Watson Ladd wrote this message on Tue, Sep 17, 2013 at 09:23 -0700:
> On Tue, Sep 17, 2013 at 9:09 AM, Mark Handley <[email protected]> wrote:
> >
> > On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote:
> >> Mark Handley <[email protected]> wrote:
> >>
> >> > The key reason for an approach at this layer in the stack is that it
> >> > gets you the most bang for the buck. By leveraging the TCP handshake,
> >> > you can get sessions encypted very easily with minimal infrastructure
> >> > deployment, and only a single change to the stack.
> >>
> >> I've tried to find (in the draft or in the paper) information on the
> >> server's entropy consumption, and the practical consequences.
> >>
> >> Can entropy generation become performance-limiting on servers that
> >> receive a lot of connection requests?
> >>
> >> What kind of source of randomness did you use in the experiments?
> >
> > That is a good question. I don't know what Andrea's implementation
> > currently does.
>
> > We could require the client supplies another random (encrypted) nonce
> > right after the key exchange. This would be sufficient to top up the
> > entropy pool in the presence of a passive eavesdropper, assuming entropy
> > generation is easier at the client. An active attacker could try to
> > deplete this entropy source by making a lot of connections and sending
> > known values of this nonce, but they'd have to drown out all the
> > legitimate clients, which would be difficult on a busy server, and would
> > likely reveal the presence of the attack. And they'd need to combine
> > this with eavesdropping very close to the server, or all they'd do is
> > add randomness to the pool from their packet arrival times.
>
> Exhibit A of why we need mathematicians on this list. The difference
> between AES in counter mode and
> actually random numbers is miniscule. Any server has enough entropy to
> reseed say once a second, which will be fine for
> less than 2^64 connections per second. Please, check what /dev/urandom
> actually does, and what actual cryptographers say
> about generating random numbers in practice.
Also, the randomness is only needed when a new client connects or we
decide to rekey an existing host. A single host can connect many
additional times w/o requiring additional entropy.
It does look like there cannot be a DoS attack against the entropy
pool as the sever doesn't need to generate N_S until the client has
responded to PKCONF and they must response w/ the proper ACKCOOKIE if
the server provided a SYNCOOKIE in the PKCONF packet.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
