On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote: > > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:= > > > > I am working on an implementation for NSS/Firefox and I know some > > > > others are working on their own implementations, so hopefully we can > > > > do some interop in Montreal. > > > > > > > > This is at a pretty early stage, so comments, questions, defect > > > > reports welcome. > > > > > > One thing I noticed: First there is this in evaluation: > > > > > > 7.2.4. Do not stick out > > > > > > By sending SNI and ESNI values (with illegitimate digests), or by > > > sending legitimate ESNI values for and "fake" SNI values, clients do > > > not display clear signals of ESNI intent to passive eavesdroppers. > > > > > > Is that suggesting to send fake ESNI values? If so, there is this in > > > endpoint behavior: > > > > > > > No, you would not send fake ESNI values. The idea here is that there is a > > group of IPs (associated with a big provider, then all ESNI-supporting > > clients will send ESNI to it. So the provider will stick out, but the use > > of site X versus site Y on the provider will not stick out. And the > > provider's IPs are reasonably well known through other mechanisms, so > this > > doesn't tell you much. Of course, this does not help big sites that > aren't > > using shared infrastructure (e.g., Facebook), but I don't know how to do > > that. > > What does "with illegitimate digests" mean then? > I didn't write this text, but I agree that it's in conflict with the requirement that you abort with an unknown key. We went through some design variants and this looks like a remnant of a previous one. -Ekr > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
