Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI...

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 22 Nov 2019 03:28:49 +0800

On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote:
> It doesn't take much to encourage me so I just
> pushed out that idea in I-D form:-) [1]
 […]
> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00

Thanks for this (and for the -01 update for the draft).  I like this
work, and i think we should pursue it in the WG.

A couple notes/questions:

 - Clients might use this, not just "zone factories".  For instance,
   consider a client with limited access to the DNS that makes an
   initial direct connection to the hidden host, leaking SNI.  If, in
   that connection, it also fetches this record, it could use that to
   bootstrap future connections to the host, right?

   The draft currently contemplates this briefly for followup queries
   for some clients, but it doesn't go into it in more detail.

 - Why is it hosted on the cover server, instead of on the hidden
   server?  is that just so that the zone factory doesn't leak $HIDDEN
   to the network?

   Surely on a zone factory update, the zone factory already knows the
   eSNI for $HIDDEN so it could make the request with eSNI to
   https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to
   https://$COVER/.well-known/esni/$HIDDEN.json

   At the same time, for $COVER to publish this information potentially
   puts $COVER at more risk, right?  And, a $COVER could *claim* to be a
   cover for $HIDDEN without approval of the $HIDDEN site by publishing
   these records; if anyone believes that claim, it could cause traffic
   to be re-routed through the ersatz $COVER.  If it's going to be
   hosted at $COVER and not $HIDDEN, we should be explicit about what
   defends against such an attack.

   There could be an "obvious" reason for the choice of hosting it at
   $COVER instead of at $HIDDEN, but it should be spelled out in the
   draft.

 - If this is treated as a separate/independent source of authority
   about ESNI data for a host from the DNS (e.g. in the client examples
   contemplated in my first point above, not just the "zone factory"),
   then the draft probably needs some text discussing what to do when
   discovering a discrepancy between what's in the DNS and what's found
   at .well-known.

Regards,

        --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Nov 2019 05:13:13 +0000

Hiya,

(As per the meeting discussion, I'll plan to revise the
individual draft in the next while and then the WG can
consider what to do about it. If ESNI/ECHO draft-06 is
out first, I'll change to align with that. If not, we
can worry about that later. In the meantime...)

> work, and i think we should pursue it in the WG.

Cool. Thanks.

>    bootstrap future connections to the host, right?

Yep.

>    for some clients, but it doesn't go into it in more detail.

Right. I wasn't sure if people would like, or be freaked
out by, that:-)

>    server?  is that just so that the zone factory doesn't leak $HIDDEN

Yes. Also - if adding a new $HIDDEN then first time around
the zone factory can't use ESNI/ECHO to $HIDDEN.

>    https://$COVER/.well-known/esni/$HIDDEN.json

Other than first time, as noted above. I've also had cases
where things got out of whack (because I'd broken stuff)
that meant ESNI stopped working to $HIDDEN for a bit. (The
specific failures I've seen don't make a real difference
to answering your question, as the zone factory does try
out the new keys with $HIDDEN as part of it's work, but
maybe some other failure cases might matter more.)

>    puts $COVER at more risk, right? 

Yes. If $COVER is the public_name from the ESNIConfig
though it doesn't seem much more of a risk.

> And, a $COVER could *claim* to be a

Sure. In my case, the zone factory knows all the names but
yes, discussion of the more general case is needed.

>    $COVER instead of at $HIDDEN, but it should be spelled out in the

Ack. Will do.

>    discovering a discrepancy between what's in the DNS and what's found

True. In the zone factory case, such discrepancies are of
course nominal. Otherwise, I can envisage a number of
different client scenarios (client DoH/DoT availability
can be yes, no or dunno; the client might have old
ESNIConfig values or not, and HTTPSSVC might or might
not be available etc.)

And I guess there's even the case (that probably will freak
someone out) where $HIDDEN might not even exist in the
DNS at all if it is covered by a wild-card cert and if
$HIDDEN is in the client's /etc/hosts or equivalent. (I
think I could support that now in my servers but haven't
actually deployed such a vhost - maybe I should:-)

I'm not sure if this draft ought specify behaviour for
such clients, but I can try add text describing the various
cases I guess. (If that text were to stay in, then I'd
guess that it'll make this document too long to include
in the base ESNI/ECHO draft thus taking that option off
the table maybe.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Nov 2019 05:13:14 +0000

Hiya,

Cool. Thanks.

Yep.

Ack. Will do.

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 22 Nov 2019 16:12:50 +0800

> in the base ESNI/ECHO draft thus taking that option off

The other option would be to make non-"zone factory" clients explicitly
out of scope, and spend a couple sentences describing why.  And then
note how if you're going to play these games as a non-"zone factory"
client you really need to think it through a lot more than this draft
does.

     --dkg

---

From: Hans-Christoph Steiner <[email-masked]>
Date: Fri, 22 Nov 2019 12:10:51 +0100

> client you really need to think it through a lot more than this draft

That seems reasonable to me, since this is obviously useful in the zone
factory use case, while other strong use cases haven't really arisen
yet, from what I've seen.  Such a use case could come along though.

> puts $COVER at more risk, right?

I think it is also important to note that for the obvious use case, I
don't think this adds risk to $COVER.  If $COVER is megacdn.com where
$HIDDEN is hosted, then megacdn.com assumes no new risk since it is
already clear that megacdn.com is hosting $HIDDEN.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 22 Nov 2019 21:05:01 +0800

>    for some clients, but it doesn't go into it in more detail.

Hopefully this use case is covered by the "esniconfig" Alt-Svc parameter (
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01#section-8).

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>