> Any big issue keeping N=8
>
Regarding the length of N, I gather that the trade-off is that if it is too
short, the probability of collisions between the signal and randomly generated
server randoms becomes significant,
and so does the probability of an active MitM forging the signal. Is there
2020-09-12 05:48 GMT+02:00 Peter Gutmann :
> Filippo Valsorda writes:
>
> >I feel like there should be nothing controversial in the context of TLS.
> >
> > Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a
> > MUST NOT, because they can't be implemented securely.
> >
> >
On Sat, Sep 12, 2020, at 21:55, Karthik Bhargavan wrote:
> > Any big issue keeping N=8
>
> Regarding the length of N, I gather that the trade-off is that if it is
> too short, the probability of collisions between the signal and
> randomly generated server randoms becomes significant,
> and s
Hi,
I get a weird feeling that the internet is being hijacked and soon it
will be impossible to reverse course. I have not followed the
development of TLS 1.3 but it seems very different from TLS 1.2. Also
TLS 1.2 is very different from TLS 1.0/1.1 (which are being
deprecated). QUIC looked
> Karthik: That approach works, but unless the ECH echo is universally
> deployed, it still reveals to a passive observer whether the server is
> ECH-enabled. That means, at least for several years, exchanges that are
> using ECH will likely "stick out" to a passive observer. This is something
The ServerHello ECH extension approach has lots of good properties, but
also one big risk. What if a server decides that ECH is not needed for
this connection, and does not send the extension at all? The connection
will work just fine, because for the client absence of the extension
implies "using
I agree with Christian. The reason to use the ServerHello.random trick is
to make real ECH connections look like connections in which the client
sends a dummy ECH extension to a non-ECH server. In particular, this design
pattern is needed for property (1).
Property (2) is achievable if the ECH con
Hi Mike,
This is a pretty big topic that’s been explored quite a bit. The long term
impact of these changes could be very positive. I just published a book on the
topic of embracing E2E among other topics after exploring the impact on
operators in RFC8404. In other words, both directions wer