Subject: [TLS] Alternative ESNI?

From: Nico Williams <[email-masked]>
Date: Fri, 14 Dec 2018 20:53:47 -0600

OpenSSL extracts and uses SNI from session resumption tickets.

This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
on their behalf.

Also, while we're at it, I'd like to note that SNI is not the only thing
requiring privacy protection from the client.  There's also the PSK
identity payload for non-resumption PSKs...  Not as important as SNI,
perhaps, nonetheless I think we should maximize privacy, else we'll be
engaging in repeated encrypted-{fill-in-the-blank} exercises.

Our proposal makes DNS optional (for co-tenancy fronting discovery) and
DNSSEC not necessary.

The basic idea is to use a HelloRetryRequest to make a handshake traffic
secret available to the client for it to use in its subsequent hanshake
messages.  This form is susceptible to an SNI disclosure active attack
-- same as the current ESNI proposal w/o DNSSEC.  This variant adds one
round-trip to full handshakes.

We can then optionally piggy-back the server's Certificate and
CertificateVerify along with the HelloRetryRequest (provided the
client's initial key_share is acceptable to the server), and now we have
authenticated the server under its fronted name, which means there is no
active attack on the ESNI.  This still only adds just the one round-trip
to full handshakes.  And look ma', now w/ no DNSSEC requirement to avoid
active attacks.

And if the client already knows about the co-tenancy of the fronting
and desired servers, then no DNS lookups are needed to discover it.
E.g., dissidents might learn this by word of mouth.

The second variant can, sadly, add an extra round-trip when the server
finds the client's initial key_share unacceptable.

As to resumption, the real SNI should be the one from the original full
handshake, and the SNI in the resumption should be the fronting
service's name.  Resumption retains the same latency as in RFC 8446.

Below are the flows for the three cases, all of these being full
handshakes.  Naturally, these should be read after first reading figure
2 from RFC 8446.

        ClientHello
        + key_share             -------->
                                                  HelloRetryRequest
                                <--------               + key_share      
        ClientHello
        {EncryptedExtensions}
        + key_share             -------->
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                      {Certificate}
                                                {CertificateVerify}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

             Figure 1: Alternative ESNI w/o active protection

        ClientHello
        + key_share             -------->
                                                        ServerHello
                                                        + key_share
                                             {EncryptedExtensions*}
                                                      {Certificate}
                                                {CertificateVerify}
                                <--------       {HelloRetryRequest}
        ClientHello
        + key_share
        {EncryptedExtensions}   -------->
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                      {Certificate}
                                                {CertificateVerify}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

              Figure 2: Alternative ESNI w/ active protection

        ClientHello
        + key_share             -------->
                                                  HelloRetryRequest
                                <--------               + key_share
        ClientHello
        + key_share             -------->
                                                        ServerHello
                                                        + key_share
                                             {EncryptedExtensions*}
                                                      {Certificate}
                                                {CertificateVerify}
                                <--------       {HelloRetryRequest}
        ClientHello
        + key_share
        {EncryptedExtensions}   -------->
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                      {Certificate}
                                                {CertificateVerify}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

             Figure 3: Alternative ESNI w/ active protection,
                          with worst-case latency

Thoughts?  Is this horrible somehow?  Has this been discussed and
discarded for some reason?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Dec 2018 20:01:35 -0800

> round-trip to full handshakes.

We looked at this class of design during the initial work on TLS 1.3 because
(a) it has trivial active attacks, as you note and (b) we don't want people
to
have to accept an extra round trip in order to get ESNI, because that's a
major disincentive to doing it.

WRT to the active attack point, DNSSEC isn't necessary with the current ESNI
design. What's necessary is that the client be able to get the ESNIKeys
record
(and the A/AAAA records) securely wrt to the attacker trying to get the SNI.
However, in a large number of cases (e.g., an attacker on your local
network,
there are non-DNSSEC ways of obtaining this property, such as using DoH.
In addition, if the attacker controls DNS (or generally can observe DNS
traffic)
then getting the SNI encryption key securely isn't sufficient because the
attacker
can just learn the domain name from the DNS lookup (or return a unique
IP for each query and then use that to look up the SNI from the IP).

> to full handshakes.  And look ma', now w/ no DNSSEC requirement to avoid

This seems like a more invasive version of what David Benjamin et al.
proposed the
other day, just without the ESNI key at all. I don't think this is an
acceptable
general solution for latency reasons (as opposed to fallback), and of course
you still need some way to securely obtain the domain name you put in
the SNI, and if this isn't done with DNS, then you end up with a situation
where very few people use ESNI and so you stick out.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Dec 2018 23:48:37 -0600

On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> We looked at this class of design during the initial work on TLS 1.3
> because (a) it has trivial active attacks, as you note and (b) we
> don't want people to have to accept an extra round trip in order to
> get ESNI, because that's a major disincentive to doing it.

One of the two has no active attack, and the extra round trip is already
possible due to the existing HelloRetryRequest flow.  The variant that
is resistant to active attack has a worst case additional round-trip,
but again, only on initial handshake.

BTW, the flows I presented have no multi-CDN keyshare private key
distribution issues because there are no keyshares to publish in the
DNS.

> WRT to the active attack point, DNSSEC isn't necessary with the
> current ESNI design. What's necessary is that the client be able to
> get the ESNIKeys record (and the A/AAAA records) securely wrt to the
> attacker trying to get the SNI.  However, in a large number of cases
> (e.g., an attacker on your local network, there are non-DNSSEC ways of
> obtaining this property, such as using DoH.  In addition, if the

DoH?

> attacker controls DNS (or generally can observe DNS traffic) then
> getting the SNI encryption key securely isn't sufficient because the
> attacker can just learn the domain name from the DNS lookup (or return
> a unique IP for each query and then use that to look up the SNI from
> the IP).

Sure.  DPRIV is still needed, no doubt.

> proposed the other day, just without the ESNI key at all. I don't
> think this is an acceptable general solution for latency reasons (as
> opposed to fallback), and of course you still need some way to

Again, it's comparable to the existing HelloRequestRetry flow case.

> securely obtain the domain name you put in the SNI, and if this isn't
> done with DNS, then you end up with a situation where very few people
> use ESNI and so you stick out.

Granted.  But not having to coordinate privte keys for the keyshares to
be published in the DNS seems like a very big win.

Nico
-- 

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Dec 2018 13:08:50 +0000

Hi Nico,

> This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here

I agree this is worth exploring, though am not sure if it'd be
better in the end. (I chatted with Viktor about this and said
I'd try see if I could make it work once I've gotten further
along coding up the current draft.)

I don't see any point in considering the variant with the easy
active attack though; as ekr said, I think that was considered
before and I'd say that'll just confuse matters and is better
omitted, so I'm only really considering your figure 2 below.

...snip...

>               Figure 2: Alternative ESNI w/ active protection

Some questions:

- How are you proposing the client knows of the existence of the
  hidden service? (Aside from local configuration, which is always
  possible.)
- How does the server know to include the HRR in it's answers? (IOW,
  what ESNI signal is present in the client's 1st flight?
- Ought that be some more general signal? e,g. "client wants to send
  some EncryptedExtensions, let's do an extra RTT." (I'd like that
  I think, but the counter argument might be that that's overreach
  and we'd be better to just stick with an ESNI model that we're
  confident can get some deployment.)
- Given HRR was a kludge for backwards compatibility could changing
  where that occurs in the protocol trigger more middlebox messes?
- This seems like supporting the split mode behaviour [1] could be a
  lot more complex, as this scheme is more embedded in the h/s. Is
  that fair? (Note: I'm not sure the split mode is really easy in
  any circumstances though, so that mightn't be a killer argument.)
- In tls1.3 the HRR has an accompanying key_share, if pursuing this
  further I'd say you'd want to consider whether or not that is
  better to include. (That is, your server's first flight above has
  a SH and then HRR but only one key_share - it might be better to
  have a key_share in each, and that might even enable a more
  tractable split mode model if the cover server could handoff the
  rest of the h/s after that maybe.)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-5.4

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 15 Dec 2018 05:22:37 -0800

On Fri, Dec 14, 2018 at 9:48 PM Nico Williams <[email-masked]> wrote:

> One of the two has no active attack

It only doesn't have an active attack because you have assumed away
some method of distributing the name to put in the SNI in the clear.

and the extra round trip is already
> possible due to the existing HelloRetryRequest flow.

Yes, but we expect that HRR is going to be quite rare. If it's not,
other things have generally gone wrong.

> distribution issues because there are no keyshares to publish in the

No, but they have similar problems in terms of coordinating the SNI
you put in the clear. Consider the case where domain X desires to
use ESNI and is hosted on CDN 1, which also hosts domains A, B, and
C, and CDN 2, which also hosts domains U, V, and W. What domain
does it put in the cleartext version of the SNI?

> > obtaining this property, such as using DoH.  In addition, if the

DNS over HTTPS.

> Again, it's comparable to the existing HelloRequestRetry flow case.

A case which we try to avoid.

> be published in the DNS seems like a very big win.

As noted above, I don't think you're meaningfully avoiding this,

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Dec 2018 15:00:03 -0500

> On Dec 15, 2018, at 8:08 AM, Stephen Farrell <[email-masked]> wrote:
> 
> active attack though;

For the record the easy MiTM attack requires on-path TCP termination,
only discloses the SNI name, and the full handshake then fails.  It
looks to me like the same happens with the current draft when the
fronting key_share is not DNSSEC-validated.  And the attack on DNS
can be done cheaply at scale as we saw with the MyEtherWallet BGP
re-route back in April.

The present draft puts keys in DNS that for many site operators
will be difficult to rotate frequently, so there is a considerable
loss of forward-secrecy.  Absent DNSSEC, and even with DoH/DoT,
MiTM attacks are not precluded by the current draft.  The attacker
just has to compromise the traffic between the DoH/DoT recursive
resolver and the authoritative server.

Yes, if the same provider operates both of:

   * The user's selected DoH/DoT upstream DNS resolver
   * The authoritative DNS for the ultimate target domain

do we really want this much centralization?

> as ekr said, I think that was considered

It seems to me that in this space we can't realistically have
perfection, there are only trade-offs.  If we want the protected
domains to not stand out by being a tiny fraction of the traffic
to the fronted server, then low adoption barriers are essential
to getting any security here, MiTM or not.

Obviating the need to put server keys in DNS, and synchronize the
key shares across the server farm, ... IMHO does more to ensure
SNI privacy than an MiTM-resistant but more difficult to deploy
model.

>  hidden service? (Aside from local configuration, which is always

For opportunistic discovery, yes also DNS, but the DNS record would
just hold a stable indication of support for the protocol.

  * It could be just a boolean, with the SNI name sent to the CDN
    being a well-known placeholder (but only in the case that we
    forgo authenticating the CDN and accept MiTM SNI disclosure).

  * It could be a list of fronting server names (similar to SRV) with
    the appropriate SNI name sent to each server, prior to switching
    to an encrypted SNI.  This supports multi-CDN deployments, but
    the load-balancing across CDNs is then handled client-side.

>  what ESNI signal is present in the client's 1st flight?

It could be a specially designated sentinel key_share algorithm, or
it could be an extension that solicits HRR.  If this proposal merits
further discussion, then we can get into the details, for now it is
perhaps best to consider the broad outline, and see whether that has
any merit.

>  confident can get some deployment.)

Either is possible.

>  where that occurs in the protocol trigger more middlebox messes?

It could.  This would need to be explored.

>  any circumstances though, so that mightn't be a killer argument.)

Yes, it is not immediately obvious how/whether split mode works.
I've not given it much thought.  Presently just wanted to see
whether using ephemeral keying for ESNI is a viable alternative.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Dec 2018 20:40:12 +0000

Hiya,

On 15/12/2018 20:00, Viktor Dukhovni wrote:
>>e
> fronting key_share is not DNSSEC-validated.  

Yes. The significant difference though, for me, is that I can
see how to mitigate the attack in the case of the current draft
(deploy DNSSEC and/or DoH/DoT covering the bits of network about
which you're worried). Whereas the HRR scheme without the step
of authenticating the cover site inherently cannot have such a
mitigation as far as I can see.

Personally, I think that's a winning argument against the HRR
scheme with no cover-server authentication prior to exposing the
ESNI.

> And the attack on DNS

I agree that the current content specified for putting in the
DNS and the potential centralisation that may cause are both
undesirable.

I'm not convinced the HRR scheme is a better replacement. (But
I do think it is worth considering, as I said before.)

If browsers found one of the schemes attractive and the other
not, that'd I think be a winning argument - unfortunately, but
realistically, that'd win all arguments about trade-offs in
terms of potential for privacy improvement.

> just hold a stable indication of support for the protocol.

Isn't the easiest attack on ESNI then to just block visibility
of that boolean at which point a client will use SNI and not ESNI
and it's game-over? That seems to imply the HRR scheme isn't
any less dependent on DNS really, as I think ekr implied. (The
HRR scheme could be much nicer in terms of operating DNS, but not
more secure.)

Cheers,
S.

PS: Thanks for the other answers below, I think they're clear
enough.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 15 Dec 2018 16:06:06 -0500

[ After this comment, stepping back for a while, I want to hear what others
  think about the general shape of the alternative... ]

> On Dec 15, 2018, at 3:40 PM, Stephen Farrell <[email-masked]> wrote:
> 

The HRR scheme has better support for out-of-band local policy, that
resists the above attack, since the data that would be obtained via
DNS is comparatively stable, and could just be a local setting in
the user agent.

If one is willing to forgo authenticating the fronting server
(trade-off), the use of ESNI could simply be on by default,
discovered in-band by observing whether the server's HRR carries
an appropriate extension.

  * Send sentinel client key_share that triggers HRR
  * Omit all sensitive extensions.
  * Send sentinel SNI
  * Check server HRR for extension that indicates support
    for encrypted extensions in client HELLO after HRR
  * If present, encrypt all the client extensions including SNI.
  * If absent, then proceed as before.

In this mode, there are no new DNS lookups, but we end up doing
an extra round-trip for all servers, even those that are not behind
CDNs and don't support the extension.

That is of course great news for not standing out of the crowd,
all traffic looks the same whether behind a fronting CDN or not,
*but* this forgoes the opportunity to learn (via a secure out
of band channel) the fronting server's name and authenticate it,
so the MiTM SNI disclosure attack is back.

We can trade-off broad deployment against active attack resistance,
but it seems difficult to have both.  I'd be inclined to favour
broad deployment, and rely on Tor and the like (in combination
with ESNI) to make SNI disclosure through active attack less
useful to the attacker.

-- 
-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 15 Dec 2018 13:27:04 -0800

> terms of potential for privacy improvement.

I can't speak for anyone else, but as I said, we discussed this topic during
the initial design phase of TLS 1.3 and the conclusion was that taking
an extra round trip to get ESNI was prohibitive and that people wouldn't
be willing to turn it on by default (and we ultimately hope that ever TLS
connection will have ESNI). do not believe Firefox would be willing
to do so. Perhaps otehr browsers feel differently.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 15 Dec 2018 13:30:18 -0800

> fronting key_share is not DNSSEC-validated.

As I said in my response to Nico, it depends on the threat model. If your
concern is the local network (which is quite common), then DoH addresses
the issue.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Dec 2018 14:45:00 -0500 (EST)

On Fri, 14 Dec 2018, Eric Rescorla wrote:

> However, in a large number of cases (e.g., an attacker on your local network,

Data origin authenticity is not the same as transport security.

DoH offers no guarantee that the non-dnssec protected information you
received is not modified.

Unfortunately, I keep needing to say this on various IETF lists. The
move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided
and just moving the goal post. It is very concerning now that we see
browser vendors to start moving DNS from the endpoint to trusted
servers elsewhere on the internet under the control of very few, mostly
US based, for profit entities.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Dec 2018 12:29:07 -0800

> Data origin authenticity is not the same as transport security.

Yes, I'm quite aware of this fact.

> received is not modified.

As with all things security, it depends on your threat model. If the
attacker you
are concerned with is between you and the DNS server, then in fact it does
provide protection.

> and just moving the goal post.
>

I don't think this is a very accurate characterization of the situation. At
present,
the vast majority of DNS information is not DNSSEC protected [0], and yet we
have to rely on it. If there's a "blindly trusting" in this discussion,
it's that. DNS
over HTTPS is designed to improve the situation, though of course it's not
a panacea.

However in *this* case, it actually covers a pretty large fraction of the
threat
model, because (1) many attackers are close to the user and (2) if the
attacker
controls your DNS server, then they learn which site you are going to in
any case even before you send SNI. Even if all the attacker can do is
*modify*
records rather than observe queries, this is often enough. For censorship
applications,
they just serve a blackholed IP address, and for surveillance applications,
an
attacker with significant network capabilities can serve a dedicated IP for
each
server name and then forward the traffic.

Note that DNSSEC does not help very much in this case. If the attacker is
the server, they don't need to modify records, and if they are not the
server,
then DNSSEC protection relies upon the client hard-failing on DNSSEC
failures,
which generic clients do not do because it would cause unacceptable failure
rates.

-Ekr

[0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf provides an overview
of the extremely depressing state of play; only 1% of .com is properly
signed
and about 30% of domains which have DNSSEC don't publish all the records
needed to verify the domain.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Dec 2018 17:33:14 -0600

> along coding up the current draft.)

Perhaps this alternative ESNI protocol can complement the current ESNI
proposal.

The idea would be to allow sites that cannot orchestrate ESNI keyshares
across multiple CDNs to opt for this alternative by publishing in DNS
only the fronting domainname(s).  Only then would one pay the extra
round trip price to get ESNI, and only if the client wants it (but the
client should want it).

A client that finds a domain's fronting domain but not ESNI keys would
engage in the active attack resistant variant I posted with the fronting
domainname as the public SNI, and the server would know to respond with
the HRR.

The key is that we need to be able to deploy an ESNI protocol widely and
easily, but if ESNI keyshare orchestration is a big brake on deployment,
then it might take a long time to get traction.

(Note that I never said that DoH/DPRIV would not be needed.  The
alternative would allow simple manual, local configuration, whereas
publishing ESNI keyshares does not.)

> active attack though; as ekr said, I think that was considered

Agreed.  I included it mostly to show how we got to the one that is
resistant to active attacks.  I thought it'd be useful to do that, but
instead it seems to have given everyone something bad to latch onto :(

> omitted, so I'm only really considering your figure 2 below.

I agree.

>   hidden service? (Aside from local configuration, which is always

DNS (DPRIV, DoH).

Local config isn't really possible if it means the user has to type in
keyshares.

>   what ESNI signal is present in the client's 1st flight?

The client uses the fronting domainname as the public SNI payload.  The
server, knowing via local configuration that it has no ESNI keyshares in
DNS, responds with the HRR as above.

>   confident can get some deployment.)

Yes and no.  In order to get ESNI widely adopted it will probably help
to have a way to trigger this denies the censors an unambiguous "pst,
hey, let's do this thing so the censors don't know your name" signal.

But for that I would think that yes, we'd want a general signal about
this.

>   where that occurs in the protocol trigger more middlebox messes?

Dunno.

>   any circumstances though, so that mightn't be a killer argument.)

See above, and below.

Maybe we do both, the current ESNI proposal and this as an alternative
for when ESNI keyshare orchestration is difficult, and in that case you
don't get to do split mode.

>   rest of the h/s after that maybe.)

Ohhh, nice!  That's brilliant!  One of the keyshares (the HRR's) could
be the one shared with the middlebox for split mode.  The client would
derive two sets of handshake traffic keys then.  (If split mode is not
used then the HRR can have the same keyshare as the SH, then only one
set of handshake traffic keys need be derived.  In encrypted extensions
we'd need to identify which key was used -- maybe, the recipient can
always try decrypting with both keys.)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Dec 2018 01:58:53 +0000

> don't get to do split mode.

Interesting that the above overlaps a bit with the PR davidben
just posted. That seems promising.

That said, I'd bet we're all generally unkeen on "do both" but
maybe the above-mentioned PR avoids that by casting the HRR-mode
as way to better handle a likely operational failure mode.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Dec 2018 21:47:22 -0500

> On Dec 17, 2018, at 8:58 PM, Stephen Farrell <[email-masked]> wrote:
> 

I guess the reason I started thinking along the lines of the alternative
proposal is because it would doing it *at all* might be too complex for
many sites, and privacy protection that is mostly not deployed is then
not very effective.

Thus, instead of trying to work around glitches caused by key management
glitches, my thinking was to avoid them entirely, by using ephemeral keys.

I don't dispute the obstacles:

  * Additional round-trip for full handshakes.
  * Possible middle-box concerns that I can't speak to.

The potential upside is:

  * Supports stable local policy (no keys, means client used by users
    with critical need can have a static fronting server config).
    
  * Better forward secrecy.

  * Much simpler operationally, so could have much broader deployment.

I'll take a look at David Benjamin's PR, to see whether it resolves
any of the motivating reasons for the alternative...

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Dec 2018 21:01:22 -0600

> as way to better handle a likely operational failure mode.

I have no dog in this hunt, but ISTM that anything we can do to simplify
deployment will help a great deal.  The ESNI keyshare orchestration
strikes me as a big impediment to deployment, but I understand too that
adding a round trip to every initial handshake is a bit much.  A
combination of options, or some new thing -- it's all the same to me, as
long as it gets us ESNI.

Oh, and not just ESNI.  I also want the PSK identity payloads for
non-resumption handshakes encrypted.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Dec 2018 12:19:40 -0600

>              Figure 1: Alternative ESNI w/o active protection

Figure 1 was expositional.  Please forget it.

>              Figure 3: Alternative ESNI w/ active protection,

There's a different way to do the third case _without_ an extra round
trip in the worst case.  Now there are no cases with worse latency than
the worst latency in RFC 8446.

This is the case where the client's initial key_share is not acceptable
to the server.

The key observation is that we can send the server's Certificate and
CertificateVerify in the clear when they are for the fronting name,
which means we can authenticate the server in the first flight, which
means that we can have handshake traffic keys in the second flight:

        ClientHello
        + key_share             -------->
                                                        ServerHello
                                                        + key_share
                                                        Certificate
                                                  CertificateVerify
                                <--------         HelloRetryRequest
        ClientHello
        + key_share
        {EncryptedExtensions}   -------->
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                      {Certificate}
                                                {CertificateVerify}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

             Figure 4: Like figure #2 but with initial client
               key_share that is unacceptable to the server

Note that the server's Certificate and CertificateVerify goes
unencrypted.  Why?  Well, it is the Certificate for the *fronting*
name, the one that went unencrypted in the ClientHello, so it doesn't
really need protection.

As Stephen Farrell points out, we get to have *two* server key_shares,
one from the SH and one from the HRR, which gives us the opportunity to
have one of them be something of a static key share shared with a
traffic director.  So we get to have *two* sets of handshake traffic
keys, one that gives a traffic director visibility, and one that does
not.

Do we ever need confidentiality protection relative to the traffic
director?  If so we'll need notation for indicating which handshake
traffic key set to use for what encrypted extensions.

Nico
--

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 18 Dec 2018 13:53:56 -0500

Just a clarifying question inline
On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla <[email-masked]> wrote:

> I don't think this is a very accurate characterization of the situation.
> At present,
> any case even before you send SNI.
>

This is written as a pretty broad statement.  Did you intend to say that
the attackers for this threat vector are close to the user or many
attackers? Asking as this could sway opinions and the current solution is
well suited to CDNs, not necessarily others.

Even if all the attacker can do is *modify*
> they just serve a blackholed IP address, and for surveillance
> applications, an
> attacker with significant network capabilities can serve a dedicated IP
> for each
> which generic clients do not do because it would cause unacceptable
> failure rates.
>
> -Ekr
>

This is probably a bit better as a reference as it appears to be kept
current:
https://www.internetsociety.org/deploy360/dnssec/statistics/

and includes links to others providing statistics for reference as well.
The validation statistics look a bit better in the following study:
https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0
where worldwide, they say 16% DNSSEC validates.

-Kathleen

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

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Dec 2018 13:48:12 -0800

On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty <
[email-masked]> wrote:

> attackers?

I'm not sure I understand the question you are asking. A lot of the threats

Asking as this could sway opinions and the current solution is well suited
> to CDNs, not necessarily others.
>

Yes, the current solution is generally designed to fit into CDN-like
scenarios. However, ESNI is generally not that useful unless you have a lot
of origins on the same domain (otherwise the IP address itself reveals your
destination), and there are a limited number of scenarios of this type
(CDNs, hosting providers, application servers, etc.)

> https://www.internetsociety.org/deploy360/dnssec/statistics/

Thanks.

> where worldwide, they say 16% DNSSEC validates.

I believe this is measuring something different, which is the fraction of
the Internet which is covered by validating resolvers. However, that
doesn't reflect end-to-end validation, but (typically) recursive resolver
validation, which is a rather different matter. To my knowledge, no generic
browser client does DNSSEC validation, for the reason that when people have
looked at it it created unaceptable failure rates.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Dec 2018 17:04:56 -0500

> On Dec 18, 2018, at 4:48 PM, Eric Rescorla <[email-masked]> wrote:
> 
> To my knowledge, no generic browser client does DNSSEC validation, for the reason that when people have looked at it it created unaceptable failure rates.

Agreed.  That's a pretty safe bet.  The last-mile problem is still with us for
now, though of course DoH/DoT change that too.  The failure rates are almost
never on the backbone, but rather between the user and a crippled local resolver.
To the extent that ESNI presumes DoH/DoT, DNSSEC might become more viable, but
we're certainly not there yet.

And even though public recursive resolvers often do validation, most domains
are as yet unsigned, the signed domains are still heavily concentrated at
a few registries and hosting providers in Northern Europe, and separately Brazil.

Adoption elsewhere is still light, adoption barriers at registries and registrars
are are a major obstacle, that is slowly starting to change as some start to
implement CDS (RFC8078) support.

-- 
	Viktor.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Dec 2018 10:04:22 -0500

Hey EKR,

Sent from my mobile device

>> On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty <[email-masked]> wrote:
>>> As with all things security, it depends on your threat model. If the attacker you
>>> I don't think this is a very accurate characterization of the situation. At present,
>>> have to rely on it. If there's a "blindly trusting" in this discussion, it's that. DNS
>>> However in *this* case, it actually covers a pretty large fraction of the threat
>>> model, because (1) many attackers are close to the user and (2) if the attacker
>> This is written as a pretty broad statement.  Did you intend to say that the attackers for this threat vector are close to the user or many attackers?
> 

It’s a broad statement.  If I were to give that acting in a CISO role, it would sound like FUD and I either wouldn’t get very far or wouldn’t get anywhere towards goals the next time around.  Crisping it up to the exact threat, point of risk, quantifying, and prioritizing would help.

I’m hearing from concerned people in the threat detection/response side on this (eSNI) who are not willing to speak up.  This point is also where they sit on a network , typically one they manage and users consent to monitoring in their employment agreement.  They are watching for attackers, including nation-state threat actors.  

When ‘many’ attackers are listed, it sounds ominous.  However, if it were quantified and the exact threat were listed, then judgement calls could be made.  Maybe the threats you are referring to are far worse than nation state supply chain attacks or are ones that TLS as a WG prioritizes.  It would be good to either leave out generic statements or to list something more specific (or a list or point back to the draft that covers this topic).

It’s likely that incident responders will just need to adapt, but keeping a prioritized list of threats and point of defense could be helpful to many.

Best,
Kathleen 
> 
> 
>> Asking as this could sway opinions and the current solution is well suited to CDNs, not necessarily others.
> 
> Yes, the current solution is generally designed to fit into CDN-like scenarios. However, ESNI is generally not that useful unless you have a lot of origins on the same domain (otherwise the IP address itself reveals your destination), and there are a limited number of scenarios of this type (CDNs, hosting providers, application servers, etc.)
> 
> 
>>> 
>> This is probably a bit better as a reference as it appears to be kept current:
>> and includes links to others providing statistics for reference as well.  The validation statistics look a bit better in the following study:
> I believe this is measuring something different, which is the fraction of the Internet which is covered by validating resolvers. However, that doesn't reflect end-to-end validation, but (typically) recursive resolver validation, which is a rather different matter. To my knowledge, no generic browser client does DNSSEC validation, for the reason that when people have looked at it it created unaceptable failure rates.
> 
> -Ekr
>