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

[Stephen Farrell <[e-mail]>]

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...)

On 21/11/2019 19:28, Daniel Kahn Gillmor wrote:
> 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.

Cool. Thanks.

> 
> 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?

Yep.

>    The draft currently contemplates this briefly for followup queries
>    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:-)

> 
>  - 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?

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

>    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

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.)

>    At the same time, for $COVER to publish this information potentially
>    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
>    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.

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

> 
>    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.

Ack. Will do.

> 
>  - 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.

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.



> 
> Regards,
> 
>         --dkg
>