Subject: [TLS] About encrypting SNI

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Apr 2014 10:29:31 -0400

I have concerns some about SNI encryption.

First, I think it addresses a problem that is actually not that important for most. There are comparatively few sites on the web that have multiple properties served from a single host (or cluster). Certainly the biggest sites that received the most publicity for being under attack by the NSA -- Microsoft, Google, Yahoo, etc. -- are really a few to smallish number of services. And those companies have the wherewithal to deploy separate identities and IP addresses for their properties.

Second, it potentially disadvantages a portion of the net: large CDN's and their customers. My employer, for example, serves thousands of sites on its TLS network, and encrypting SNI requires us to either have a single long-lived keypair for all customers, or require an extra RTT for clients to fetch an EDH key, perhaps still shared, but hopefully more secure. The latter is particularly off-putting since customers paying for a "faster, better" end-user experience are now at a disadvantage. Some in this community might not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame.

Third, we have not heard from the real potential community of consumers of this. I posit that they are mid-size sites with a "handful" of hosted properties. They are currently adequately served by virtual IP's, and even more so in the future by IPv6. And in terms of adversaries, does it matter which property within peacefire, for example, a user is contacting?  A site under surveillance by a national-scale adversary will have *everything* scooped up anyway.

Let me put some numbers on the previous points. We deliver content for around 10K domains, each with its own RSA keypair, out of 1500 locations. Without SNI, that means we need 15Million IP addresses, while being able to use SNI we only need one per location (region in our terminology). With SNI encryption we either need to share keys (bad for security, and perhaps not compliant with some regulations) or fragment IPs (bad for the web long-term). And that's just us.  Add in all the CDNs, hosting companies, cloud providers... it's big.  Do we know what people like AWS, Rackspace, IBM Cloud, etc., think about this?

Fourth, it potentially "unlevels" the playing field. Organizations that have both a browser and servers of interest could, trivially, arrange to push out keys on a regular basis. I am not suggesting that anyone is planning on doing this, but I fear the temptation to do so in the name of "improving the user experience" will prove too great. In darker moments, I extrapolate the " browser list of  CA's" story and imagine a future where Chrome talking to Google will be faster than IE talking to Bing, and Firefox will end up selling slots in its EDH store (sic) to attract revenue.

Fifth, it introduces unknown security and trust implications in browsers. It took years to make "certificate stores" actually secure. And we are potentially opening up a new avenue of active attacks over the network while increasing the expectation that things are more secure. We are also increasing the client-side attack surface.

Sixth, it adds an extra burden to servers. I think it also improves potential DoS attacks, since they could start at the first PDU exchange.

Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Host header, the virtual hosting industry was created. Until virtual IP's were well-known and SNI was widely adopted (I'm being charitable here), adoption of TLS among hosting providers had significant drag. If SNI is routing, then routing is plaintext and we are now going hide it without understanding the trade-offs. 
 
Finally, it is a lot of mechanism.  As ekr said in London, "you have to do all this if you want to protect the SNI." It's not worth it.

I think we're going too far, and we should come down on the side of simplicity, not for its own sake, but for security's sake.

	/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 10:36:18 -0700

Rich,

Did you consider the solution proposed by dkg at the meeting?  That
is, embed routing information in the server_key_label [1].  That means
that you can identify flows as precisely as you need prior to
decrypting.  No need then for 15m IP addresses, certainly.

--Martin

[1] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.4.3

On 7 April 2014 07:29, Salz, Rich <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Apr 2014 14:59:34 -0400

> Did you consider the solution proposed by dkg at the meeting?  That is, embed routing information in the server_key_label [1].

Yes we looked at it. What we need and want is the SNI.  Not a custom re-creation of it.

	/r$

---

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Apr 2014 07:40:42 -0700

> I think we're going too far, and we should come down on the side of simplicity, not for its own sake, but for security's sake.

Furthermore, it doesn't actually protect the SNI in the current
envisioning. Censorship-resistance and privacy can come from TOR,
which you need to use anyway to get both.

I think Rich Salz has outlined very compelling reasons not to support SNI.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Apr 2014 10:51:23 -0400

> I think Rich Salz has outlined very compelling reasons not to support SNI.

While I might quibble with a detail here or there, I do agree with the conclusion.  If you need to protect SNI, then TOR or to a lesser extent TLS-in-TLS can be used.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2014 10:13:36 -0700

On Mon, Apr 14, 2014 at 7:51 AM, Russ Housley <[email-masked]> wrote:

> While I might quibble with a detail here or there, I do agree with the
> conclusion.  If you need to protect SNI, then TOR or to a lesser extent
> TLS-in-TLS can be used.
>

I'm not sure that this addresses the requests I have heard for SNI
encryption which is to conceal the sites people are going to by default
rather than as a special case for the privacy conscious. Hopefully
some of the people who have asked for this (e.g., dkg) will weigh in
but as I understand it, the concern is that if the only people who
attempt to conceal the site being connected to are the privacy
conscious, then that's a signal that those connections are worth
monitoring.

It's certainly the case that there are some additional changes that
would be required to make concealing SNI worth doing
(principally encrypted name resolution, but also a clear model
for how to do traffic padding and other things), but conversely
if we don't change TLS to permit concealing the SNI, then we
won't get as much value from encrypted DNS.

I'm not saying that either of these are slam dunk arguments, but
I wanted to make sure they were on the table.

-Ekr

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 14 Apr 2014 14:18:27 -0400

Eric Rescorla <[email-masked]> writes:

>     While I might quibble with a detail here or there, I do agree with
>     the conclusion. If you need to protect SNI, then TOR or to a
>     lesser extent TLS-in-TLS can be used.
>
> encryption which is to conceal the sites people are going to by
> default rather than as a special case for the privacy conscious.

It sounds like the information about who is visiting which sites will
leak to a passive adversary either from DNS, or from unencrypted SNI, or
from which server IP address is used---as long as servers have different
opinions about crypto.  And as long as the Fed-compliant sites have NIST
crypto and the "subversive" sites avoid NISt crypto, they'll have to be
on different addresses.

A design to preserve anonymity-style privacy from even purely passive
adversaries can't fit into the TLS layer---or else Tor wouldn't have so
hard a problem.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 14 Apr 2014 19:39:30 +0100

> default rather than as a special case for the privacy conscious.

Precisely.

Tor (for example) wants to look like a common-or-garden browser to
avoid Eve fingerprinting it (and real, actual jackboots knocking doors
in as a result). This means, say, browsers should make - and be able
to make - the most privacy-preserving choices, too. That benefits
everyone.

Plaintext SNI makes it really easy to demux connections to the same
ip:port tuple without needing state from DNS lookups. That's an
advantage for Bob, where Bob has a lot of servers (like Rich does) -
but it's also a huge advantage for Eve and Mallory.

We should also consider if we can use the same method to protect
returned certificates, and any other plain-text ClientHello fields
(notably ALPN). We do want that if we can get it practically, so maybe
we want something slightly more general than just for SNI.

> It's certainly the case that there are some additional changes
> that would be required to make concealing SNI worth doing 
> (principally encrypted name resolution, but also a clear model for
> how to do traffic padding and other things), but conversely if we
> don't change TLS to permit concealing the SNI, then we won't get as
> much value from encrypted DNS.

What I'm worried about is the circular argument of doom and defeat:

· We don't have encrypted DNS requests, so why encrypt SNI?
· We don't have encrypted SNI, so why encrypt DNS?
· We don't have encrypted IP: why encrypt over TCP which can be RST'd?
· Privacy is hard: let's go shopping.

Maybe we should worry less about what we don't have yet: and instead,
let's do what we can to build the things we don't have to make Eve's
life a little harder in steps.

Counterbalancing our wishes of course is how much is useful,
practical, and technically feasible, especially at the scales Rich
needs to worry about. And I empathise with his troubles there. (I
seriously doubt any solution that requires iteration in linear-time
with the number of hosted domains is workable, for example!)

How can we protect the Hellos in general from Eve and Mallory as much
as we can without making Bob's (or, to a lesser extent, Alice's) life
too hard? Can we do that in a backward-compatible way? (I'm getting
the vague sense that if we can't, things look more like TLS 2.0?)

But I don't think we should give up on doing it just because it's a
tough problem to solve. It's literally the first thing listed in the
WG charter as a "do want" for TLS 1.3: so if we can't deliver that
easily, then I think we need to try harder!

I'll let you know if any sudden epiphanies arise. Anyone got any
bright ideas?
- -- 
/akr

---

From: Nick Mathewson <[email-masked]>
Date: Mon, 14 Apr 2014 14:56:50 -0400

On Mon, Apr 14, 2014 at 2:39 PM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

[marginally offtopic from the rest of the thread.]

In the case of Tor, that's no longer exactly the case.  We don't want
to deviate _too much_ from typical browser behavior, but we no longer
consider "emulate a browser talking TLS to a webserver" to be a viable
way to achieve censorship-resistance.  We've found, over the years,
that there are simply too many degrees of freedom in TLS and X.509 to
make this trick work well.

Our current link-anticensorship architecture relies instead on a
pluggable layer to handle superencipherment and protocol
obfuscation/emulation.

I don't claim to know what implications this might or might not have
for SNI (non-)encryption.

cheers,
-- 
Nick Mathewson

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Apr 2014 15:56:10 -0400

Hi Rich, all--

I want to speak up in favor of encrypting SNI (and the rest of the TLS
handshake) if at all possible.  It would be a shame if TLS did not
support sites who wanted to be private except to their clients.  If we
drop plans to encrypt SNI, we make the tasks of would-be censors and
surveillance operators much easier.

On 04/07/2014 10:29 AM, Salz, Rich wrote:

> First, I think it addresses a problem that is actually not that important for most. There are comparatively few sites on the web that have multiple properties served from a single host (or cluster).

Measured by traffic, you may be correct.  But if you measure by number
of web sites, the opposite is likely to be true.  Far more small sites
(each with low amounts of traffic) are aggregated on shared hosting
providers that re-use IP addresses between sites.  These are sites that
we will want to protect from passive monitoring.

If the default is to protect SNI information from passive eavesdropping,
websites which share IP addresses with other sites will be able to
remain "dark".  (yes, the dns-privacy project will also have to come up
with a reasonable fix to that leak).

If there is no expectation that servers should be able to handle
encrypted SNI, then clients will be unable to hide the identity of the
web site they visit from an eavesdropper.

For web sites whose names themselves are cause for concern to censors or
surveillance operators, and who may evade network address based
censorship or monitoring by changing IP addresses fluidly, encrypted SNI
is an important mechanism.

> Second, it potentially disadvantages a portion of the net: large CDN's and their customers.

I appreciate that large CDNs and their customers face special
operational concerns.  They already do, whether we encrypt SNI or not.
Large CDNs are also uniquely positioned to be able to sort out technical
solutions to the challenges posed by encrypted SNI to their business model.

On the other hand, If we don't support a mechanism that permits
encrypted SNI, then instead we instead severely disadvantage smaller
sites that are more vulnerable to censorship and surveillance, and those
smaller sites have little recourse other than requiring their guests to
use Tor, which comes with its own set of concerns.  This is a bad tradeoff.

>  encrypting SNI requires us to either have a single long-lived keypair for all customers, or require an extra RTT for clients to fetch an EDH key, perhaps still shared, but hopefully more secure. The latter is particularly off-putting since customers paying for a "faster, better" end-user experience are now at a disadvantage. Some in this community might not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame.

The discussion of possible handshake flows suggests that the extra RTT
does not need to be in every handshake; several proposals for
"semi-static" DHE keys have been put forward already, and
second-connections need not have the extra RTT.

Depending on how we define the mechanism, the initial SNI-protecting DHE
key could even be per-IP address, rather than per-domain, which would
allow further reductions in RTT for sites hosted on large farms with a
few public-facing IP addresses.

> Third, we have not heard from the real potential community of consumers of this. I posit that they are mid-size sites with a "handful" of hosted properties. They are currently adequately served by…

A major goal is to make traffic to a domain that would be censored as
indistinguishable as possible from traffic that would not be censored.

If the "solution" is to give each site its own IP address, then we've
lost that goal: a censor simply blocks based on IP address.

> Let me put some numbers on the previous points. We deliver content for around 10K domains, each with its own RSA keypair, out of 1500 locations. Without SNI, that means we need 15Million IP address…

You're describing this as though encrypting SNI would mean no more SNI,
or one IP address needed per web site.  This is not the proposal.

> Fourth, it potentially "unlevels" the playing field. Organizations that have both a browser and servers of interest could, trivially, arrange to push out keys on a regular basis. I am not suggestin…

???  If browser vendors want to play these kinds of games, there are
already many ways they can play them, up to and including deliberate
miscommunication with a competitors' services or software.  they're
generally not doing that, because it's bad for business.  If speed is
critical enough to encourage vendors to publish DHE keys for specific IP
addresses on a regular basis, they'll want to do this in a standard way
that browsers and web site operators could collaborate on.

> Fifth, it introduces unknown security and trust implications in browsers. It took years to make "certificate stores" actually secure. And we are potentially opening up a new avenue of active attack…

I'm not convinced that certificate stores are "actually secure" if we
look at them from a usability perspective, but i think that's a tangent
to the SNI point.  I think the "new avenue of active attacks" you
describe are attacks that:

 a) are likely to result in connection failures if we design the
protocol well

 b) require timing-sensitive, active control on the 'net, and

 c) result in revealing server name indication and other handshake
parameters.

If we opt to avoid encrypting SNI or other parts of the handshake, then
a simple passive attacker gets (c) for free, and doesn't need to bother
with their own increased visibility (a) or technical difficulty (b).  I
don't see how avoiding encrypted SNI is a security win, when seen from
this perspective.

> Sixth, it adds an extra burden to servers. I think it also improves potential DoS attacks, since they could start at the first PDU exchange.

I agree, we need to consider this computational burden.  Whatever we can
do to ensure that DoS amplification is minimal would help legitimate
deployments.

> Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Host header, the virtual hosting industry was created. Until virtual IP's were well-known and SNI was widely adopted (I'm bei…

SNI is communications metadata.  If we've seen anything from the
discussions and information leaked over the last year, it's that
communications metadata is of deep and abiding interest to global
surveillance regimes, including those whose activities the IETF has
clearly indicated are worth treating as an attack on the 'net.

One of the oft-cited complaints about attempts to secure e-mail in an
end-to-end fashion is that the header information is not protected.

We should avoid leaving TLS in that same state if we can help it.

I'm happy to work with folks who have performance and operational
concerns to make sure we can address them with an encrypted handshake.
These are design tradeoffs that lend themselves to gradual improvement,
whether through caching or preloading or other mechanisms.  But if we
design a new version of TLS that does not encrypt the handshake
properly, we leave critical pieces of metadata exposed on the wire for
passive attackers, and there are no clear ways to avoid the leakage for
people who care about it.

Regards,

	--dkg

---

From: "Sniffen, Brian" <[email-masked]>
Date: Mon, 14 Apr 2014 16:38:21 -0400

> few public-facing IP addresses.

More narrowly to that point:

We are in a historically rare position of having one suite of generally-agreed good crypto: ECDHE, ECDSA*, AES, SHA2.  That hasn't been true most days since the creation of SSL; we've wondered about export vs. not, 3DES vs RC4, DSA vs RSA, and so on.  We're probably going to end up in that conflicted and confused world again, in which reasonable people can disagree about their cipher suite choices.  Encrypted SNI means that every site on an address must agree on certain parts of their cipher suite.

In a world where I'd like to operate a backwards-compatible site for vehicle firmware upgrades, prominent social media sites, and mobile app back-ends off of one address, that means I'm stuck!  I expect to see that around ECDSA (required by governments) vs. Ed25519 (required by those frightened by governments), AES (for GCM to computers > 1 kg) vs. ChaCha (for Poly1305-AEAD to computers < 1 kg), and similar.  

I don’t see a path to low-RTT protection of the host identity that doesn’t require all hosts in an identity-group to share their cryptographic politics on many dimensions.  And at that point, I can’t tell whether you’re talking to HRW or AI, but if you’re doing it from Tibet, you’re dead anyway.

-Brian

* With carefully chosen nonces

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Apr 2014 00:40:08 +0300

Hi

While I understand dkg’s argument for privacy in accessing sites on shared hosting, I don’t find that argument compelling.

What both web hosting providers and CDNs offer is not server name privacy. What they sell is cost reduction (because getting however many 9s they give you on your own servers would be way more expensive), and CDNs add reduced latency to that. Tacking on a security feature onto somebody else’s cost-cutting feature is not likely to provide good security (or privacy).

Hiding the SNI only helps if the same IP address has multiple properties, and access to those properties cannot be distinguished except by looking at the SNI. Suppose for example that the one “subversive” site on a server has a landing page with a certain size for the main HTML resource. Assuming everyone who lands there fetches the HTML page and none of the other sites has a landing page of the same size, you can pretty much find these people by traffic analysis. The hosting providers or CDNs will have to actively help make the sites resistant to identification through traffic analysis, and that is expensive to do and it is not what they’re selling. 

On balance, I think hiding SNI offers very little for the trouble it would take to make it happen. Perhaps a better privacy option would be to avoid sending SNI and then have the server demux based on an HTTP Host header. You will need some mechanism to associate the certificate that you’re getting with the property, and a DANE record might be able to help there.

Yoav

---

From: Seth David Schoen <[email-masked]>
Date: Mon, 14 Apr 2014 16:36:14 -0700

> What both web hosting providers and CDNs offer is not server name privacy. What they sell is cost reduction (because getting however many 9s they give you on your own servers would be way more expe…

It seems like this argument leads to some odd places if applied
beyond the HTTP context.  For example, we could say that the ideal
is for everyone's e-mail to be hosted on a separate server (indeed,
there are some projects that are trying to move in that direction by
making it easier for individuals and very small organizations to host
their own mail).  This suggests that the reason that many people share a
single mail server today is cost savings (the costs of mail hosting are
amortized, as when many people can share the administration services of
a single administrator or staff of administrators, for example).

The next step from this observation might be to say that a shared mail
host like Gmail or Yahoo Mail or GMX is merely offering cost savings
(because it would be expensive to pay for an entire dedicated colocated
server, sysadmins doing spam filtering, etc., for each of their millions
of users).  Since the core consideration that underlies the mail hosting
architecture is cost efficiency and economies of scale, it must not be
very important to provide confidentiality for who e-mails whom, right?
If they cared a lot about that, they could, after all, each use their own
mail server.  (Oops, now the adversary can see which mail servers
connect to one another and figure out who's e-mailing whom from _that_
traffic!)

It seems appropriate to me to consider separating the historical and
economic reasons that particular hosting arrangements arose from the
potential privacy benefits that protocol design decisions can offer to
their users today.  Traffic analysis wasn't a consideration at all in
the emergence of HTTP virtual hosting (or CDNs), and it may not have
been a consideration in the original SNI specification either.  Still,
it's something that these layers may be in a position to facilitate --
or mitigate -- today.

> Hiding the SNI only helps if the same IP address has multiple properties, and access to those properties cannot be distinguished except by looking at the SNI. Suppose for example that the one “subv…

I think Alyssa Rowan's concern elsewhere in this thread about the
"circular argument of doom and defeat" applies here too.  If we were
off in the HTML or HTTP working groups talking about defeating traffic
analysis, someone might well say that it was impossible to defeat traffic
analysis in a virtual hosting environment because of SNI (!).

If there are, let's say, five or seven standards that bear on defeating
traffic analysis of Internet communications, each of them can avoid or
postpone making changes to address that because the other ones haven't.
Meanwhile, some of them could protect against at least some threats
even without fixing the others.  For example, people here in the TLS WG
have regarded unencrypted DNS as a reason that securing SNI may not be
much of a win.  That's definitely true for, say, a user on a corporate
LAN who's concerned about surveillance by their employer.  But in other
cases the person in a position to see the SNI data isn't necessarily
on-path with respect to DNS queries.  (For example, an attacker might
be spying on the network links into a particular data center, but DNS
queries might never go through that data center at all, and indeed might
already be cached quite close to the client.)

There is research beginning about mitigating traffic analysis of HTTP
that relies on the volume of traffic flow.  If we imagine that Wikimedia
decides to adopt some mitigations for this by padding replies upward to
fill some bucket, the ability to protect SNI data could be extremely
relevant to _reducing_ the overall amount of padding data required,
because the appropriate choice of bucket sizes might depend quite directly
on how much other contextual information an adversary can observe about
which Wikimedia service a client is accessing.  For example, if the
network adversary doesn't know whether a user is visiting de.wikipedia.org,
fr.wikipedia.org, pt.wikipedia.org, or ko.wikipedia.org, there's a much
higher initial uncertainty about which possible encyclopedia article the
user is downloading, and so it may be possible to add only a small amount
of padding to make the adversary extremely uncertain.  (Maybe each of those
Wikipedias turns out to already have two images, and between one and five
text articles, of between 7160 and 7168 bytes.)  By contrast, if the
adversary is starting with knowledge that the user is definitely reading
a particular language Wikipedia, the set of possible pages is initially
tiny and a larger amount of padding traffic might be required.

So it's possible to imagine that, if a site takes traffic analysis
resistance as an explicit goal, protecting SNI will actually make their
hosting requirements _milder_ and reduce load by some metrics.

There are clearly upper bounds on how uncertain a server can make the
adversary about what the user is doing (for example, the Wikimedia
Foundation couldn't convince the adversary that the user was actually
playing World of Warcraft as opposed to reading Wikipedia).  Protecting
SNI, like any localized traffic analysis mitigation, can't make those
bounds infinite, just higher than they could conceivably be with
cleartext SNI.

-- 
Seth Schoen  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Apr 2014 23:08:59 -0400

> I think Alyssa Rowan's concern elsewhere in this thread about the "circular argument of doom and defeat" applies here too.

I think it's a little too simple a way to view things. Our goal isn't to make Eve's job as hard as possible, it's to make the best set of trade-offs we can, for the ovewrall Internet.  As myself and others have pointed out, encrypting the SNI has some real drawbacks and might not accomplish what is desired. If we decide to not support it, it can purely be an evaluation of the trade-offs.

	/r$

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Apr 2014 00:00:53 -0500

> While I might quibble with a detail here or there, I do agree with the conclusion.  If you need to protect SNI, then TOR or to a lesser extent TLS-in-TLS can be used.

That's... renego, in so many words.  I know, if the composition (with
channel binding!) is left to the application then it's not renego in
the sense that most people think of it.  I'm OK with that.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Apr 2014 22:21:47 -0700

> I think it's a little too simple a way to view things. Our goal isn't to make Eve's job as hard as possible, it's to make the best set of trade-offs we can, for the ovewrall Internet.  As myself an…

It all depends on the mechanism that is proposed, and how that works.
The mechanism in the current TLS 1.3 doesn't actually work: a censor
can break a few connections to see what you are looking at, then take
a look himself to see if they want to censor it. Even if we did have a
magic mechanism that encrypted the handshake without knowing to whom
it was to be encrypted (I'm sure someone will dig up an IACR paper
that presents a wildly impractical solution using fully homeomorphic
encryption) a censor could probably take a good guess as to what
everyone was looking at, especially from interaction patterns.

Censors are generally insensitive to collateral damage. Turkey denied
access to all of Twitter, and Pakistan all of Youtube (for everyone
worldwide once) over a small amount of subversive content on each. Not
to put anyone on the spot, but if you think a major hosting provider
is going to bat for you while getting bomb threats and periodically
sitewide blocks, you're nuts. They aren't. It isn't their business,
and the ones who make it their business are usually collateral damage
for a censor as people who don't want to take the cost of getting
blocked.

Frequently changing IP address and using DNS to send people there
doesn't work: the censor knows how to find DNS entries also. I'm not
sure what the threat that encrypted SNI is supposed to protect against
is: a passive observer looking for connections to a website on shared
hosting, insensitive to collateral damage? A merely curious teenager
armed only with wireshark, and no idea of what the websites look like?
The Great Firewall of China?

Finally, a sufficiently motivated censor could cut off all TLS 1.3
entirely if they couldn't break it. Browsers would fallback to TLS
1.2. Some censors are that motivated: they threaten publishers with
death and dismemberment

Now, the best mechanism I can think off would be to use DNS to preload
a per-IP SNI encryption key, or have the handshake optionally involve
getting one. But I still can't figure out how to authenticate the
gotten key without a lot of complexity. The best solution is for the
client and server to do a DH, then pass the desired website (which
might get you investigated when the initial handshake is intercepted),
and have that cert sign the handled DH, then go back and do a TLS
connection. Ugh.

Make a clean, per-IP solution, and you solve the big problem. However,
I think censors are going to not care about collateral damage, and may
very well send a clear message by blocking TLS 1.3.

I would love to have a nice, simple, censorship resistance
improvement. Maybe there is low-hanging fruit we missed. It's worth
still thinking about. But at this moment I don't see a useful way to
achieve the goal.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Apr 2014 09:42:55 -0400

What if the client doesn't send SNI, but instead the hosting service has a single wildcard cert?  What changes in the privacy and trust model?  Why isn't that acceptable?

	/r$

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Apr 2014 16:52:50 +0300

Currently HTTPS requires the name in the cert (CN or alt-name) to match the dns name, and a wildcard can cover only one qualifier.

So if you’re hosting like tumblr, you can do yoavnir.tumblr.com and richsalz.tumblr.com and have a *.tumblr.com certificate.

But you can’t host www.yoavnir.com (not mine!) and www.imperialviolet.com like that. There is no valid certificate that won’t generate red screens that covers both of those.

So we’d have to change the way certificates are matched to domain names if we wanted that. Perhaps we could have a certificate with the name “www.myhostingsite.com”, and a new DNS record for www.yoavnir.com that says that this site is hosted with the name “www.myhostingsite.com”.  For a site that published this DNS record, the browser would not send a (clear) SNI.

This is a significant change, though. One that affects previous versions of TLS as well.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Apr 2014 09:56:31 -0400

> So if you're hosting like tumblr, you can do yoavnir.tumblr.com and richsalz.tumblr.com and have a *.tumblr.com certificate.

Yes, I know.  It would mean that aaa.privacy.org and kkk.privacy.org would be under the same DNS name.  You could mitigate that by having a CNAME entry.

My question is about the security, not the discoverability (or vanity, if you will).

	/r$

---

From: Watson Ladd <[email-masked]>
Date: Tue, 15 Apr 2014 08:01:14 -0700

> My question is about the security, not the discoverability (or vanity, if you will).

Figure out how the browser knows to not send SNI (are we going to do
this for everything? probably not) and I think we've solved the
problem. DNS entries may or may not work: I need to think about it
more.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Apr 2014 11:04:22 -0400

> Figure out how the browser knows to not send SNI (are we going to do this for everything? probably not) and I think we've solved the problem.

A switch on the browser, just like cookie-control, that says "establish the private connection before identifying the host" or some such.  Change four pieces of software and you've probably got 90% of the browser market handled.

	/r$

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Apr 2014 09:06:25 -0700

On Tue, Apr 15, 2014 at 6:56 AM, Salz, Rich <[email-masked]> wrote:

> > So if you're hosting like tumblr, you can do yoavnir.tumblr.com and
> richsalz.tumblr.com and have a *.tumblr.com certificate.
>
> Yes, I know.  It would mean that aaa.privacy.org and kkk.privacy.orgwould be under the same DNS name.  You could mitigate that by having a
> CNAME entry.
>

Rich,

I'm not sure I completely understand your proposal, so let me try to
restate it:

1. Privacy.org would host aaa.privacy.org, bbb.privacy.org, ...
zzz.privacy.org
and have a cert for *.privacy.org

2. This allows the user to avoid revealing his target server as long as it
is
matches *.privacy.org *and* he has some mechanism for suppressing SNI.

3. If the user wants to have www.zzz.org virtually hosted, he needs a CNAME
that points from www.zzz.org -> zzz.privacy.org.

Do I have this right?

-Ekr

         /r$

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 15 Apr 2014 17:22:10 +0100

>that points from www.zzz.org -> zzz.privacy.org.

Not wishing to state the obvious about this idea, if that is indeed what the idea is and we've not misunderstood, but that CNAME had better be DNSSEC-signed: otherwise Mallory of the not-exactly-hypothetical Nation State Adversary just uses QUANTUM<some-cute-codename> to inject a fake CNAME DNS response to redirect https://bob.example/ to https://bob.evil.nsa/ when Alice looks it up, and Mallory's CA-signed certificate for *.evil.nsa becomes worth its weight in gold as Alice's browser accepts the redirect.

- --
/akr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Apr 2014 12:36:57 -0400

Yes, you have it right.  Alyssa's concerns about DNS are valid, but I do wonder if the CNAME security requirements are any different than the A/AAAA security requirements; I need to think about it.

                /r$

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Apr 2014 18:54:45 +0200 (CEST)

Salz, Rich wrote:
>
> Yes, you have it right.  Alyssa's concerns about DNS are valid,
> but I do wonder if the CNAME security requirements are any different
> than the A/AAAA security requirements; I need to think about it.

Both have no security requirements for HTTP-over-TLS.

The way that HTTP-over-TLS was originally designed, it was without
trust into DNS, i.e. *NONE* of the transformations that happen
during DNS lookup (CNAME, A/AAAA) affect the processing of the
server endpoint identification.  (SMTP got it wrong)

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Apr 2014 10:01:02 -0700

On Tue, Apr 15, 2014 at 9:36 AM, Salz, Rich <[email-masked]> wrote:

> Yes, you have it right.  Alyssa's concerns about DNS are valid, but I do
> wonder if the CNAME security requirements are any different than the A/AAAA
> security requirements; I need to think about it.
>

My claim is that they are. Here's why I say that:

The basic TLS model (and in fact the 3552 model) is that the attacker
controls
the network. This means that the attacker can detour the packets anywhere
he wants, regardless of what IP addresses are in them. Thus, forging
A/AAAA resolution just makes this easier. In order to defend against this,
TLS verifies that the name in the certificate matches the name it is
trying to connect to. In the current environment, that means that if
the client tries to connect to https://aaa.example.org/ and this is CNAMEd
to https://example.cdn.org/, the client checks for aaa.example.org,
so it doesn't need to trust the DNS. If we want to have him instead check
for example.cdn.org, then the CNAME needs to be verifiable (e.g., via
DNSSEC).

With that said, I don't think this is necessarily a dealbreaker: as has been
discussed a number of times, encrypted SNI doesn't provide much in the
way of concealing the target domain without encrypted DNS, which would
presumably also be authenticated, at which point this attack wouldn't work.

With that in mind, consider the following handwavy design:

We have a secure delegation record with the following semantics:
    - It indicates that domain www.example.org is delegated to
example.cdn.org
    - It indicates that .cdn.org does not require SNI.

example.cdn.org would have two certificates:

#1: A certificate for  (*.cdn.org)
#2: A certificate for www.example.org

So, a legacy client would:
1. Get the CNAME but not know it could trust it, so it sends SNI for
aaa.example.org
2. Because SNI is provided, the server provides certificate #2.
3. The client expects certificate for www.example.org, checks that name,
and we are
good to go (though without concealing SNI).

[This is the way things are now.

A new client would:
1. Get the CNAME and see that it's a secure delegation with a no SNI.
2. Because no SNI is provided, the server provides the default certificate
(#1)
3. Because the client knows about secure delegation it checks for
example.cdn.org
    instead of aaa.example.org and because the server has a wildcard cert
for
    *.cdn.org, it all works.

Obviously this requires messing with DNS to provide confidentiality and
secure
delegation, but we would need confidentiality in any case, and secure
delegation
is mostly a matter of working out the record semantics once you've solved
the
big problem of securing the DNS. [0]

I only just wrote this down, so maybe it's totally messed up, but it seems
like a
natural extension of Rich's idea. What do people think?

-Ekr

[0] Note: I'm not saying this is solved since DNSSEC deployment isn't good
right now, but if it's not solved then SNI encryption doesn't buy us much.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Apr 2014 11:27:11 -0700

> big problem of securing the DNS. [0]

Martin Thomson pointed out to me offline that this sort of conflates two
forms of DNS security:

1. End-to-end resolution security (e.g., DNSSEC or something like DNSCurve
    where there is a chain of delegations all the way down to the leaf
node).
2. Client-to resolver security (e.g., DNScrypt or where the attacker is
     not on-path to your resolver but is on-path to the server) where you
hope
     that your activities are hidden by DNS caching.

Clearly, this proposal will only work when integrity is provided down the
entire
chain, although it might work if there was DNSSEC + client-to-resolver
confidentiality. However, note that:

(a) IETF is just starting to look at standardizing DNS encryption
(b) the existing DNS encryption systems have seen limited deployment
(c) most of the problems with DNSSEC deployment have to do with
intermediate elements which would either block DNS encryption
or (alternately) could use DNS encryption to bypass the intermediary
messing with the DNSSEC records

Given these issues, it still seems like it's at least plausible to consider
DNS
integrity a prerequisite here.

-Ekr

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 15 Apr 2014 15:24:10 -0700

> and have that cert sign the handled DH, then go back and do a TLS

What if it were an opt-in thing?  A hypothetical DANE extension could
associate with each domain a tuple (ClientHello-protection public key,
TLS version guaranteed to be supported).  Clients could resolve that
essentially for free as long as they're already querying DNS, and this
could prevent downgrade attacks and give an efficient way to encrypt the
entire ClientHello.

Note that there's no reason that the public key in here should have
anything to do with the eventual TLS handshake.  In fact, I would argue
that it should be completely independent, so that large-scale load
balancers could strip the encryption off the ClientHello and hand the
connection off to something else that knows the real key.

As a concrete algorithm, the extra DNS information could be 36 bytes: 34
for ("Curve25519/ElGamal + AES-128-GCM" || "B = b*G") and 2 for "TLS
1.3" in some suitable format.  If such a record exists, then the client
starts the connection with something like "Encrypted Hello" || a*G || IV
|| AES-128-GCM(a*B, IV, ClientHello).

Arguably, the rest of the handshake should be encrypted with the same
key.  The only reason I suggested this particular public-key
cryptosystem is because it makes it easy to encrypt the reply.

There's a weak argument to be made for arranging for the actual
encrypted ClientHello to be indistinguishable from random by anyone who
doesn't know the private key.  This ought to be straightforward using
Elligator.  Off the top of my head, it sounds cute, but I don't really
see a benefit.

The TLS version is to prevent this thing from being downgraded away: if
the server tries to claim that it only speaks TLS 1.2, but the DNS
record said that the server supports TLS 1.3, then the client aborts.

This isn't directly per-IP, but a sensible server deployment should use
the same exact data in DNS for everything it hosts on the same IP.

This adds no round-trips.  It costs a few random bytes, two
multiplications, and an AEAD invocation on the client, and it costs one
multiplication and an AEAD invocation on the server.

It adds very little protocol complexity: the encrypted ClientHello is
exactly the same thing as a regular ClientHello but with an extra layer
of encryption on top.

--Andy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Apr 2014 20:50:26 -0700

Andy,

This is an interesting idea and as you say, it has the virtue that it
doesn't require messing with the state machine at all. I have a few
comments:

1. You probably have to frame this as a ClientHello with some
opaque extensions which happen to be encrypted. The reason for
this is that there are stateful inspection devices which examine
data on port 443 and enforce that it looks like TLS. As these
 devices are associated with the client not the server, the server's
TLS 1.3 compatibility does not guarantee that the client will
in fact be able to send a non-TLS framed ClientHello.

2. It might (or might not) be easier to frame the advertised information
as a TLS cipher suite.

3. This only prevents downgrade attacks if the information
is secured via DNSSEC. There are intermediate elements which
damage enough of the DNS resolution process that they will
cause DNS signature failures even when the client knows that
the records are supposed to be signed. Hard-failing in these
cases will likely result in unacceptably high failure rates, but
if you don't hard fail, then a network-based downgrade to
unencrypted SNI is possible.

More generally, I note that a number of the suggestions that people
have provided here (yours, Watson's Rich's, my modification of Rich's)
have the common factor that they require the server to opt-in in some
way. This has the major advantage that it allows us to design a
mechanism which might be inconvenient for some network environments
because they can just not opt-in, as well as allowing out-of-band
delivery of some data in the DNS.

The disadvantage seems to be that a smaller fraction of sites will offer
encrypted SNI, which slightly paints
a target on them. I think that's probably OK, since no matter what mechanism
we use for encrypted SNI, it seems likely that an attacker will be able to
get a good handle on the virtual hosts served by a given site, and so
can use that to identify which sites he is interested in tracking even if
everyone were to use encrypted SNI. However, it's worth considering
and I'd love to hear from people who want encrypted SNI what they
think of this tradeoff.

-Ekr

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 Apr 2014 09:53:51 -0400

On 15 April 2014 23:50, Eric Rescorla <[email-masked]> wrote:
> However, it's worth considering

I don't much like opt-in security or privacy mechanisms. I feel that
over time, people's opinion of their usefulness dwindles, they're
removed in favour of simplicity or performance, and then later on we
realise we wished we had them and wind up having to work around
things.  But the status quo has become to do without, and thus
re-proposing it is a non-starter.  (An example could be OCSP-nonce
requests.)

Furthermore, no offence to Rich, but I suspect if you told him "We'll
build the DNS subdomain forwarding, and you can use that or just not
encrypted SNI", he will choose not to use it. Maybe I'm wrong, but
since he argued against it initially, I'll make the leap.  So making
it opt-in seems to be as equivalent to building an optional feature
that almost no one will use from the beginning.

No matter what we do, we will be defining a new protocol that requires
network operators do a test deployment, change configurations, and
move some inter-operating pieces into play. While I'm sympathetic to
keeping that effort as low as possible, I feel optimising for that
goal is the incorrect optimisation.  Rather, optimising for the best
protocol on the wire, with 0-RTT and 1-RTT, a protected handshake, and
the like is more important.

There are a couple options that can try to address the technical
problems Rich has raised.

The wildcard approach is one way to solve this, and I don't have any
immediate concerns about beyond it's heavy requirement on DNS
integrity. While it's my sincere hope we will have it at least
deployed, I suspect not all clients will have validating resolvers
such that we're willing to bank what will be significant amounts of
dependence on it.

....But... There once was a thing called DNSSEC Stapled Certs
(https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a
SSL certificate had a chain of DNSSEC signatures in it, validating it
via DANE (or at that time, a DANE-like mechanism.)  It violates a
layering principal that people hold dearly, shoving DNS information in
other corners it shouldn't be.  But I think it would be necessary for
the wildcard approach to be reliable for clients like browsers.

This DNSSEC chain (from root, to TLD, to the record that
xxx.privacy.org TLSNAMEs to privacy.cdn.com) could be provided by
privacy.org in an HTTP Header, HTML META tag, or other mechanism. The
browser sees this, and then doesn't even need to perform a DNS lookup
for the subdomain when it encounters it.  The application server for
privacy.org only needs a DNSSEC-capable client to retrieve these
records periodically.

Another approach I think can be made to work is the idea of per-IP
shared parameters. A static key, valid for a week, for an IP that
servers 10,000 domains does not seem less secure to me than 10,000 RSA
keys on a server serving 10,000 domains. If you can steal one RSA key,
I don't understand why you could not so target the other 9,999.

CDNs are probably in the _best_ position to rotate these keys quickly,
as a client who is on the internet is more likely to talk to a CDN
every day than any individual domain name.

The idea of the handshake being indistinguishable from random using
Elligator is very very attractive.  Several people in internet
censorship research have lamented that if you build a protocol that is
indistinguishable from random bytes on the wire - you are the _only_
protocol to do so, and thus are distinguishable.  I would love for TLS
1.3/1.4/2.0/whatever to lay out that goal, as I feel we would be
giving the notion of Net Neutrality a powerful gift: Outside
intranets, on the internet itself, all traffic is equal, and you
cannot distinguish between the most popular protocol or
MyFirstRandomProtocol.

-tom

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 16 Apr 2014 09:32:29 -0500

> that almost no one will use from the beginning.

Yes: we will not use encrypted SNI.  We can't.  We need to put thousands
of HTTP hosts with incompatible crypto requirements on each IP address.
Per-IP keys don't help us very much.

> I don't understand why you could not so target the other 9,999.

Those 10k domains can't agree on basic cryptographic primitives, never
mind parameters of those primitives.

Moreover, we don't have a single machine or a single location behind
each of those IP addresses---so the key distribution problem there gets
a little complicated.  That part is not insurmountable---but I think
continuing to make TLS push us to use a number of IP addresses
proportional to the number of web sites misses the prime benefit of SNI.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 07:39:59 -0700

> Per-IP keys don't help us very much.

Would a protocol along the lines of my strawman work for you?  I
explicitly did not require that the eventual cipher suite match for
different SNI values.  I even made it possible to for whatever
receives the initial SSL connection to strip the SNI encryption and
hand the connection of to something else, without sharing any
long-term secrets between the machines in question.

--Andy

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 07:52:44 -0700

> in fact be able to send a non-TLS framed ClientHello.

This is annoying but shouldn't be a real problem.

If large numbers of sites end up deploying it, and everyone involved
agrees to send the exact same sequence of "TLS" header bytes in front,
then there's an added benefit: middle boxes won't be able to tamper
with the actual encrypted part, so it should be extensible in the
future with impunity.

Of course, MITM boxes will hate it, because a client configured in a
hard fail mode won't be able to complete a handshake through a MITM
box with a CA key, since the MITM box won't be able to understand the
handshake.  I think this isn't so terrible.

> 2. It might (or might not) be easier to frame the advertised information

Hmm.  This could work if TLS cipher suites get split into separate
cipher, signature, and key exchange parts.  In the mean time, there
are no signatures involved at all, so most of the cipher suites don't
make much sense here.  And I don't think anyone wants to add
TLS_CURVE25519ELGAMAL_AES_128_GCM_SHA256 as a high-performance non-PFS
option.

> unencrypted SNI is possible.

Fedora is currently mulling over making everyone's laptop use DNSSEC
by default.  This may be a mess, but it looks like it'll actually
work, albeit with a bit of DNSSEC-over-TCP hackery.  In any event,
there will eventually be clients who will refuse to connect to HTTPS
sites without either a valid TLSA entry or a proof that there isn't
one, and these clients will be fully protected by this kind of hello
encryption.

> and I'd love to hear from people who want encrypted SNI what they

True.

I bet that Google, at least, would enable this thing, and there may be
enough pressure on the big CDNs to do it that one or two of them will
as well.  At that point, there's already a lot of benefit.

If a proposal like this were adopted, someone should try to prove that
a server that does not know the private key associated with the
ClientHello protection cannot tamper with any legitimate connections
to that domain.  If true, this would be a nice bonus.  It might pay to
adjust the protocol, if needed, to make such a proof simpler.  For
example, the ServerHello could include an extension that proves
knowledge of the ClientHello temporary key.  To make that work well,
there would have to be some extra trickery to make sure that big
virtual hosts can strip the ClientHello encryption and still
successfully connect.  The existing client random field may already be
enough, though.

--Andy

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Apr 2014 11:02:02 -0400

> Yes: we will not use encrypted SNI.  We can't.  We need to put thousands of HTTP hosts with incompatible crypto requirements on each IP address.

Brian makes a simple declarative statement. I started this thread by trying to list why the tradeoffs are such that a consensus could reasonably come to the conclusion that encrypted SNI should not be a part of TLS 1.3

	/r$

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Apr 2014 08:03:17 -0700

> This is annoying but shouldn't be a real problem.

I agree. I wasn't trying to suggest that it was. To be clear, I think this
is a clever idea definitely worth exploring. Thanks for suggesting it.

> handshake.  I think this isn't so terrible.

I'm not sure how deployable that is going to turn out to be. As you know,
current browsers don't allow CA pinning to override MITM boxes for
deployment reasons, so this seems like it might be a disincentive for
people to adopt this. I'd love to hear from large client implementors
how they would feel about this. (I'll ask around Mozilla...)

> TLS_CURVE25519ELGAMAL_AES_128_GCM_SHA256 as a high-performance non-PFS

Yeah, I'm not sure about this one either. Will have to think about
it more.

> one, and these clients will be fully protected by this kind of hello

I suspect that the problem here is the browsers, which generally
don't want to accept even marginal increase in failure rates
(and DNS over TCP is associated with that...)

> successfully connect.  The existing client random field may already be

This does seem like a worthwhile goal.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Apr 2014 09:00:47 -0700

Pardon my confusion, but it sounds like we imagine the overlay that
hides SNI as not adding a round trip, and thus being intermingled with
TLS in negotation. Or is this a matter of encrypting the entire Client
Hello packet, then the rest of the connection with the same key, and
completing the handshake over this channel, then running the record
layer outside? I think that's what Andy's getting at with ECIES (El
Gammal only encrypts group elements!) and using the encrypted key in
the negotiation.

I do worry about DNSSEC deployment+usage here. The local resolver is
actively hostile in many censorship regimes as ISPs are part of the
system. DNSSEC needs to get to the browser for any information in it
to be trusted if you do a lookup in places like Ethiopia, China, or
the US on Verizon.

Sincerely,
Watson Ladd

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 16 Apr 2014 11:15:15 -0500

> could prevent downgrade attacks and give an efficient way to encrypt the

Then the censor looks to see which key is used, yes?

> Elligator.  Off the top of my head, it sounds cute, but I don't really

Or does this protect against it?

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 09:39:07 -0700

> Then the censor looks to see which key is used, yes?

The idea is that the same key would be used for hello encryption for
all domains served by the same IP addresses.

Even if different keys were used, I'm not sure the censor can tell
which.  I think that the particular public-key protocol I suggested
doesn't leak any information about the public key used to a censor
that doesn't know the private key, but I could be wrong.

> Or does this protect against it?

This shouldn't make a difference, since Elligator just makes curve
points indistinguishable from any other string of bits, more or less.
In this case, the censor already knows that a particular part of the
message is a curve point, so Elligator just masks that fact.

--Andy

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 09:53:22 -0700

On Wed, Apr 16, 2014 at 9:00 AM, Watson Ladd <[email-masked]> wrote:
> layer outside?

Neither.  I'm actually suggesting encrypting just the ClientHello to
simplify allowing very large virtual hosts to receive an encrypted
hello, decrypt it, and hand the entire connection off to something
else that doesn't need to know about encrypted hellos.

A more complicated approach would be to encrypt the whole handshake
and then run the record layer outside.  This would have the added
benefit of protecting the server's choice of cipher suite, which may
be important.  To make this work, the client would have two choices:

Header indicating encrypted ClientHello || encrypted handshake session
key || encrypted ClientHello

or

Plaintext ClientHello, with extension giving a plaintext session key
to use to encrypt the rest of the handshake

The latter adds no security whatsoever, but it does allow a virtual
server to decrypt the encrypted client hello, add the extension, and
then hand off the connection.

Other variants are possible, of course.

My goal here is to keep this as painless as possible for large CDNs,
to minimize the degree to which the state machine gets more
complicated, to add no roundtrips, and to still protect the
ClientHello in cases where the client has access to valid DNSSEC data.

> I think that's what Andy's getting at with ECIES (El

Yes, you're right.  This is ECIES, not ElGamal.  I'm not a real
(classical) cryptographer, so my terminology may be wrong, and any
security claims I make should be taken with a giant grain of salt.

> to be trusted if you do a lookup in places like Ethiopia, China, or

Paul Wouters is working on having hosts run their own
DNSSEC-validating resolvers.  I have the prototype he suggests
installed on my laptop, and it works so far.  Then again, I'm on one
of the friendliest ISPs around.  We'll see how it goes.

I do expect that, some day, a large fraction of browsers will either
validate DNSSEC themselves or will be able to talk to something else
on the same machine that validates DNSSEC.

I should mention that there's an ugly corner case with my suggestion.
If a given domain is served by multiple virtual hosts, load balanced
by multiple AA/AAAA records, either they need to share the same
ClientHello key, or the data in DNS needs to indicate which IP goes
with which ClientHello key.  In practice this may not be very common.

--Andy

---

From: "Sniffen, Brian" <[email-masked]>
Date: Wed, 16 Apr 2014 12:54:06 -0400

> all domains served by the same IP addresses.

Oh, I see.  But the US government customers want a key to a NIST scheme generated with Dual_EC, and the notional non-government entities want anything but that.

> that doesn't know the private key, but I could be wrong.

But they want different protocols.  So we drift to having the censor-approved data on one IP, and the censor-opposed data on another IP.

I see the benefit of the wildcard proposal—it seems to help small users who don’t really get a say in their crypto, and just use example.tumblr.com and similar, where there’s a bunch of innocent social data mixed in with the politically interesting parts.  I don’t see how encrypted SNI helps preserve the privacy of the clients of a big web site against the adversaries I understand to oppose such.

-Brian

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 10:22:08 -0700

> But they want different protocols.  So we drift to having the censor-approved data on one IP, and the censor-opposed data on another IP.

OK, I see the problem here.

Three possible solutions:

1. US government customers can just skip setting the DNSSEC option.
The same IP can host encrypted and unencrypted ClientHello users.

2. See if Curve25519 can be used in an encrypted ClientHello even with
FIPS certification.  The argument would be that this isn't really
cryptography, since it's just an additional layer on top of something
that's already certified.  I don't know whether this would fly.

3. Use something like Elligator.  This slows down the server a little
bit, since it will have to attempt to decrypt the ClientHello once for
each possible key, but there only really need to be two keys here.
This needs some padding trickery -- see below.

I don't think that Elligator works for NIST curves, but Elligator
Squared seems to.

I actually like #3, despite its complexity, because it allows the
entire encrypted ClientHello payload to be indistinguishable from
random.  This is a further argument for adding a little bit more
complexity to allow the rest of the handshake and the record layer to
be indistinguishable from random as well.  If nothing else, this will
make it much easier to extend things in the future, since middle boxes
that support TLS 1.3 won't be able to peek inside and screw up future
extensions.  IIUC the TLS 1.2 record layer is easily distinguishable
from random.

To keep everything on one page, here's the updated strawman:

DNS indicates, for each domain: (cryptosystem, public key,  guaranteed
TLS version)

Cryptosystems include:

Non-US-government-preferred choice: ECIES/Elligator on Curve25519,
with ChaCha20+Poly1305 AEAD.

US-governement-preferred choice: ECIES/Elligator Squared on P-256,
with AES-128-GCM.

If the client sees one of these DNS records, it sends:

ClientHello wrapper || f(a*G) || IV || AEAD(real ClientHello)

The function f is either Elligator 2 or Elligator Squared, as
appropriate.  If Elligator is being used, the client needs to try an
average of two times to get a value of a that works.  The client is
expected to include a padding extension in the real ClientHello with a
length calculated to hide the length of the SNI and the length of the
ECIES header.

The real ClientHello will contain a further extension that contains a
session key that will be used to encrypt the rest of the handshake and
indicates the cipher suite.  This cipher suite MUST be exactly the
same as the one used for the ClientHello (ChaCha20+Poly1305 or
AES-128-GCM, respectively).

The server tries to decrypt the ECIES payload with each of its keys.
This is quite fast, unless P-256 is supported, in which case it's
still not that bad.  It then proceeds exactly as it would if the real
ClientHello were sent in the clear.  In particular, it does not need
to remember the ECIES session key.

If the encrypted ServerHello extension is in use, then the ServerHello
and all remaining handshake messages are encrypted as specified.  This
happens regardless of whether the ClientHello is encrypted.

If TLS 1.3 plans on encrypting the ServerHello anyway in a manner that
is indistinguishable from random, then the extension part of this
strawman can be dropped.

I don't see why FIPS certifiers would object to the use of Elligator
Squared.  It's just a transformatoin of the bytes before they are sent
on the wire.

--Andy

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 16 Apr 2014 18:31:52 +0100

On 16/04/2014 17:54, Sniffen, Brian wrote:

>> The idea is that the same key would be used for hello encryption
>> for all domains served by the same IP addresses.
> Oh, I see.  But the US government customers want a key to a NIST
> scheme generated with Dual_EC, and the notional non-government
> entities want anything but that.

Let them have a parallel cryptosystem, then? We can put a cryptosystem
ID in the DNS record (as I just see, while replying, that Andy has
suggested). That also provides scope for agility.

I'm not sure approval (or otherwise) from any government in particular
should stifle developments in this WG, especially in today's climate.

Perhaps NIST would consider adopting our work, when it is finished.
After everything that's happened, even being mindful of the general
effect they have on the market, I think you can understand that the
other way around is far less palatable.

- -- 
/akr

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 16 Apr 2014 11:09:13 -0700

> [several suggestions to use DNS for this or that elided]

Currently TLS clients only need to use DNS to determine the IP
address of the server.  Do we really want to start leaning
heavily on DNS for anything else?  I'm skeptical....

Mike

---

From: James Cloos <[email-masked]>
Date: Wed, 16 Apr 2014 14:32:13 -0400

>>>>> "AL" == Andy Lutomirski <[email-masked]> writes:

AL> US-governement-preferred choice: ECIES/Elligator Squared on P-256,
AL> with AES-128-GCM.

DJB's parallel paper (http://cr.yp.to/snuffle/bruteforce-20050425.pdf)
implies all should s/AES-128/AES-256/g.  Especialy when there is a
significant quantity of traffic available for probabilistic attacks.

(I presume those who like NIST crypto will be happy with AES256-GCM-SHA384.)

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 16 Apr 2014 18:47:08 +0000

> Then the censor looks to see which key is used, yes?

Keys are free - names and signatures are not. The good news is that
signatures may be regenerated at a low cost depending on the systems;
the bad news is that names generally can't change without a lot of
effort on both the client and the server side.

> Or does this protect against it?

I have previously hoped for a TLS (handshake, protocol,
implementation, etc) that actually considers that an attacker will try
to distinguish users and then treat them differently, eg: attacking
them, even with a simple DoS.

We see this often with the Tor network. We once were blocked in Iran
because we used a specified prime from the relevant RFC - it turns out
nearly no one else was impacted because they used another prime. We
changed the primes on the server to be dynamically generated and the
network was unblocked without a client side update. Fixed identifiers
or patterns in protocols are how censors target specific users and
protocols for censorship. The SNI in TLS is the most obvious and easy
distinguisher and it also suggests that privacy isn't actually a
cohesive security property of Transport Layer Security.

Not every TLS service uses DNS simply because it may also use names.
Names aren't only used in DNS. Just as there is more to the internet
than the world wide web, there is more to naming than the DNS.

Also, while I sympathize to the Akamai use case, I think that the
problems created with some kinds of centralization here should not be
over looked. That there are thousands of hosted sites/services on a
single IP is clearly something that needs to be supported. Is it
really only by ensuring that *everyone* that uses TLS is leaking
information to the network? I think there are probably other
options...

All the best,
Jacob

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 11:55:25 -0700

> effort on both the client and the server side.

I'm not sure I understand what you mean.

> than the world wide web, there is more to naming than the DNS.

I think that my updated proposal should work for you, as long as Tor
has some other way to distribute the same data that's normally in the
DNS record.  I imagine that it could be distributed along with the IP
addresses of entry nodes.  Am I missing something here?

My proposal, as currently written, results in the encrypted form the
the TLS handshake looking like a fixed header (ClientHello TLS version
whatever, throw-away values in fixed fields, extension prefix for the
actual encrypted Clienthello) followed by data that is
indistinguishable from random due to the use of Elligator 2 /
Elligator Squared.

If non-Tor sites adopt this, then Tor traffic will look just like
everything else.

--Andy

---

From: Erik Nygren <[email-masked]>
Date: Wed, 16 Apr 2014 14:56:27 -0400

If we do anything with DNS, we need to be very conscious that individual
records change asynchronously from other records.  For example, we can't
assume that an A/AAAA record and a DANE record refer to the same operator
(webserver, hosting provider, CDN, etc).   In order for anything along
these lines to be deployable, it must be possible for everything associated
with a particular name->service binding to change together.  In addition,
browser vendors are extremely wary of doing extra DNS lookups synchronous
to a request which is one reason that SRV records aren't in-use today for
HTTP(S).

After thinking about this some, if we are looking towards a future world
where additional DNS security and privacy has been added, a new "service
binding" record type (I'll call it a "B-record") might help partially
address a number of these issues and raise the bar a little about SNI
privacy.  The B-record would glue together information needed for
establishing a connection (and provide a client with a number of options to
choose from).  For example:

     _https._b.www.example.com B  "AAAA=2001::abcd, port=443, alpn=h2s,
handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335,
pri=5, dane_cert_name=version83.ca.example.com"
     _https._b.www.example.com B  "A=1.2.3.4, port=443, alpn=h2s,
handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335,
pri=5,  dane_cert_name=version83.ca.example.com"
     _https._b.www.example.com B  "A=1.2.3.5, port=443, alpn=h1s,
handshake_ecdhe_key=438nkgj8utjs89we0t8tjer, handshake_token=asdjhk887,
pri=3,  dane_cert_name=version82.ca.example.com"

Defines a set of HTTPS service bindings for a few sets of IP addresses with
different ALPN settings.

In the above, the handshake_ecdhe_key is the public part of the server key
to encrypt the handshake (including SNI to and the handshake_token is the
"opaque" value from ekr's flows proposal.  Clients could select between
which of them they'd use based on their ALPN support.

At least for HTTP(S), something like this might be more deployable than
current options.

Note that the handshake_token (sent in the clear in the TLS handshake like
the "opaque" value) will leak information to passive attackers who are
building up correlation tables.

Also if the key is used *only* for the handshake, it's not clear that this
is any worse against active attackers even if DNSSEC is not used than the
"new flows" proposal.  (In both cases a MitM can provide an alternate
handshake key or build up a table of ids to SNIs.)  Clearly DNSSEC would
need to be used for *every* step before DANE could be used, however.

I think the question from above arises of whether it is worth doing all of
the engineering work here if there's still no fundamental way to guard
against active attackers or resourceful passive attackers.  Some of this
will come down to trade-offs.

        Erik

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 12:09:24 -0700

On Wed, Apr 16, 2014 at 11:56 AM, Erik Nygren <[email-masked]> wrote:
> (webserver, hosting provider, CDN, etc).   In order for anything along these
> lines to be deployable, it must be possible for everything associated with a
> particular name->service binding to change together.  In addition, browser
> vendors are extremely wary of doing extra DNS lookups synchronous to a
> request which is one reason that SRV records aren't in-use today for
> HTTP(S).

You can hack around this by temporarily turning off hello encryption
when switching providers.  This is unfortunate, though.

> building up correlation tables.

I'm not sure exactly what you mean by handshake_token.  Do you mean
the anti-replay token?

The handshake token as a way of identifying the service binding in use
seems problematic to me.  Wouldn't it be better to just leave it out
entirely?  As long as each IP only accepts one or two handshake keys,
then figuring out which one is in use by trial decryption should be
fine.  I think that something is wrong if you have an IP with lots of
handshake keys.

Realistically, you may need up to four handshake keys: old FIPS, new
FIPS, old non-FIPS, new non-FIPS.

> will come down to trade-offs.

I think my approach is actually secure against active attack, so long
as the client is willing to fail if DNSSEC validation fails.  Your
idea of B records could be as the DNS component.

--Andy

P.S. As a side note, here's a tweak to mine: the DNS-encoded key
should include the length of the maximum overhead that any handshake
cipher suite imposes to make the padding calculation easier.  That
adds one byte or so.

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 16 Apr 2014 20:34:29 +0000

> I'm not sure I understand what you mean.

I mean - if you have a name that is blocked and the name is exposed in
the protocol - you can't change the name easily. One can rotate a
certificate when it is blocked. One may support a different protocol
that isn't blocked. A name is a fixed string ripe for feature
extraction and that often results in say, a forged TCP RST packet.

> addresses of entry nodes.  Am I missing something here?

I am not really interested in the Tor case here but rather the large
picture TLS usage which will later impact Tor. Though I do care that
an evil Exit node might specifically block stuff based on SNI, I think
that is a pretty unimportant corner case in the Big Picture. The Tor
community already has stuff like ScrambleSuit and other Pluggable
Transports to obfuscate traffic.

What we're lacking is a transport layer security protocol that other
people use without all of these distinguishers. Widespread use of
easily censored protocols full of information leaks makes it harder
for us to blend in with regular user traffic on the wire.

That is a slight digression but I think it is probably useful context
for what I'm thinking about and why I care about TLS in say, a web
browser that doesn't use Tor at all.

> indistinguishable from random due to the use of Elligator 2 /

I'm not clear that fixed sizes are what we'd want but I think the use
of Elligator like systems is a good general idea.

I tend to think that it would be useful to have a TLS mode where there
is an outer layer of TLS that is unauthenticated and then a second
layer with normal TLS on the inside that verifies the outer layer.
This isn't unlike the way that OTR handles key exchange data to
prevent the exposure of long term (public) keying material to a
potentially hostile chat network.

> If non-Tor sites adopt this, then Tor traffic will look just like

Maybe. This is much much harder to accomplish than it first appears!

All the best,
Jacob

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 16 Apr 2014 23:54:43 +0100

On 16/04/2014 21:34, Jacob Appelbaum wrote:

> […] and that often results in say, a forged TCP RST packet.

Which, incidentally, we should consider something to address,
especially if we do indeed have a bakeoff of some form for a fancier
TLSv2.0.

NSA calls this technique QUANTUMSKY (one of their less catchy cover
names) but it's been around for aeons (most famously in the Chinese
'Golden Shield'): any man-on-the-side can simply RST your TCP
connections if they don't like the way they smell, and this is (by
far) the cheapest and easiest way for a nation state adversary (or
malicious coffee shop WiFi) to selectively disrupt, or censor,
communications.

Could we plug that hole in a future version of TLS?

The obvious way involves UDP, and baking transport control (and
multiplexing?) inside that layer, within the encryption. In fact it's
so obvious, everyone likes to cook up their own recipe: lots of people
have done something in that general area already in different ways,
and discovered interesting things about it (Google's QUIC being one
notable recent foray into the field). UDP is also notably better for
connections through NAT and suchlike. (I've even done my own
experiments in that general direction, although delicious and moist as
they seem to be, they're simply experiments and I'm not yet ready to
serve them to guests, let alone strangers!)

It also results in something that probably looks more like DTLS than
anything we have now, or something even stranger, or like nothing
anyone can recognise.

It may, or very well may not, be a good idea (gleefully gratuitously
rampant layering violation/wheel reinvention vs. avoiding unnecessary
insecure layers vulnerable to a real, deployed attack/square wheel),
but I'd be interested (with no particular hurry) if anyone had had any
thoughts in that direction.

- -- 
/akr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Apr 2014 16:00:52 -0700

On Wed, Apr 16, 2014 at 3:54 PM, Alyssa Rowan <[email-masked]> wrote:

> > [...] and that often results in say, a forged TCP RST packet.
>

My sense is that this is out of scope for TLS proper, though (D)TLS could
certainly be part of the solution, as in:

http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03

Which is used in WebRTC data channels.

(Which reminds me, I promised to review this too so I need to get on it...)

Best,
-Ekr

---

From: Paul Lambert <[email-masked]>
Date: Wed, 16 Apr 2014 19:29:09 -0700

>significant quantity of traffic available for probabilistic attacks.
These type of parallel HW attacks are facilitated by CCM/GCM modes.
AES-SIV would not be easily mapped into such a attack.

Paul

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 19:38:14 -0700

> AES-SIV would not be easily mapped into such a attack.

Let's focus on the handshake encryption part, as opposed to the actual
selection of cipher suite.  After all, I think it's pretty clear that
acceptable cipher suites exist, and selecting them won't be terribly
hard.

FWIW, the chosen AEAD construction needs to be indistinguishable from
random, too.  GCM should be okay: the tag is the encryption of a
plaintext block that should only occur once for the lifetime of a key.
 Poly1305, at least as it's likely to be instantiated, should be okay
for the same reason: the tag is the sum of two effectively independent
terms mod 2^128, and one of those terms is indistinguishable from
random.

--Andy

---

From: Erik Nygren <[email-masked]>
Date: Wed, 16 Apr 2014 22:46:45 -0400

On Wed, Apr 16, 2014 at 3:09 PM, Andy Lutomirski <[email-masked]>wrote:

> these

In my experience, anything of this form not designed to be easy to operate,
reliably support rotation, and robustly move between providers is likely to
fail to be deployable.  Errors in this world seems to be a top cause of
outages and this sort of thing can be very hard to reason about.  Sadly,
anything that requires "hack around" as part of its normal operating regime
just isn't going to work.

> FIPS, old non-FIPS, new non-FIPS.

Perhaps handshake_key_label would have been a better term.
I was referring to what is in PredictedParameters.server_key_label in ekr's
tls13-new-flows
(which has the same problem if not handled properly, and even if used
properly still
has risks here which may not have good answers).

There are plenty of valid scenarios where you may need considerably more
than four.
An example given earlier on the list is for VM/cloud hosting providers who
need to demultiplex
from a small number of IPv4 addresses to different backend servers being
run by different
entities without mutual trust, each of which having independent different
sets of keys.

      Erik

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 16 Apr 2014 20:08:24 -0700

> just isn't going to work.

I agree.  Using "bindings" as you suggested is better.  It also adds
no extra round trips.

> from a small number of IPv4 addresses to different backend servers being run
> by different

You still only need four.  Remember that my ClientHello key is
completely independent of the key associated with the server
certificate, and that it can be stripped.

Suppose that there are a thousand domains, all sharing a few IPv4
addresses, but actually served by 100 mutually distrustful backend
servers.  You would configure all thousand domains to share the same
ClientHello key.  The devices that own the IPv4 addresses would know
the private key.  Whenever a connection comes in, they decrypt the
ClientHello, read the SNI, and forward the decrypted ClientHello to
the appropriate backend.  That backend server does not know the
ClientHello private key, but it doesn't need to.  Similarly, the thing
that owns the IPv4 address does not need to know the backend server's
private key.

So you still only need one or two keys under normal circumstances and
two or four while rotating ClientHello keys.

--Andy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Apr 2014 11:27:21 +0300

> Could we plug that hole in a future version of TLS?

We’re at the wrong layer to fix an attack against TCP.  The right place to protect TCP is either in TCP itself, or by using IPsec.

> notable recent foray into the field).

Those who won’t use TCP are doomed to re-create it. To get a UDP-based protocol to replace TCP for the web you’d need all of reliable delivery through (selective?) retransmissions, bandwidth detection, replay protection, a whole lot of things that took the transport community years to get right. Yes, there have been many attempts, but there’s a reason TCP is still the protocol everyone uses for pretty much any type of bulk transfer. And this is before we even begin to talk about middleboxes dropping unrecognized UDP services.

> UDP is also notably better for

UDP is connectionless. As such, NAT devices don’t know when it’s done. So NAT mappings need to linger a lot longer after the last packet. TCP works better with NAT.

> thoughts in that direction.

It would require an explanation about why this new wheel would be better than TCP in IPsec.

Yoav

---

From: "Sniffen, Brian" <[email-masked]>
Date: Thu, 17 Apr 2014 09:16:53 -0400

> certificate, and that it can be stripped.

Do I understand that you intend one for normal operation, one more during rotations---and then for my example that different people want different crypto, another operation/rotation pair?

I can imagine that working well in 2015.  I think in 2020 we'll surely find it too tight and chafing. Maybe that is enough.

-Brian

---

From: Erik Nygren <[email-masked]>
Date: Thu, 17 Apr 2014 08:58:49 -0400

Some of this ties directly into the tcpcrypt discussions.  It may be worth
having a discussion somewhere in the IETF on which protections belong in
which layers and how we make sure they can compose safely.  It may be that
protecting the handshake from passive attacks also belongs in the tcp
layer.  See my previous post on this topic:
           http://www.ietf.org/mail-archive/web/tls/current/msg11693.html

      Erik
On Apr 17, 2014 4:27 AM, "Yoav Nir" <[email-masked]> wrote:

> We’re at the wrong layer to fix an attack against TCP.  The right place to
> protect TCP is either in TCP itself, or by using IPsec.
>
> Those who won’t use TCP are doomed to re-create it. To get a UDP-based
> protocol to replace TCP for the web you’d need all of reliable delivery
> through (selective?) retransmissions, bandwidth detection, replay
> protection, a whole lot of things that took the transport community years
> to get right. Yes, there have been many attempts, but there’s a reason TCP
> is still the protocol everyone uses for pretty much any type of bulk
> transfer. And this is before we even begin to talk about middleboxes
> dropping unrecognized UDP services.
>
> UDP is connectionless. As such, NAT devices don’t know when it’s done. So
> NAT mappings need to linger a lot longer after the last packet. TCP works
> better with NAT.
>

---

From: James Cloos <[email-masked]>
Date: Thu, 17 Apr 2014 10:13:51 -0400

>>>>> "AL" == Andy Lutomirski <[email-masked]> writes:

AL> Let's focus on the handshake encryption part,

Good point.

Equal(-ish :) strength seems like a good plan, though.

-JimC

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Apr 2014 15:36:21 +0100

Hiya,

On 04/17/2014 01:58 PM, Erik Nygren wrote:
> Some of this ties directly into the tcpcrypt discussions.  

Yes, noting though that the TCP encryption/tcpcrypt work
is at a far earlier stage than TLS. (Its good stuff though,
or will be, I hope.)

> It may be worth

I'd quibble with "belong" there. I think to some extent our
(the IETF, not the TLS WG) job is to define protocols that get
implemented so that whoever is deploying can turn on the
security they want. Its a big old Internet out there after all,
and I'm not sure our best guess at which-layer-does-what-best
is likely to be right for all time for all places.

> which layers and how we make sure they can compose safely.  

That part I definitely do agree with. And with having a more
general discussion, which I'd hope will feed into our nascent
plans to add to BCP 72 in a while.

This is not the right list for that discussion of course, but
if you (or someone) wanted to write a draft and get a discussion
going on saag that would be good. (I suspect that might be
more useful when the TLS and tcpcrypt discussions are a little
further along though, maybe in/after the summer.)

Cheers,
S.

> It may be that

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 17 Apr 2014 07:52:16 -0700

> Do I understand that you intend one for normal operation, one more during rotations---and then for my example that different people want different crypto, another operation/rotation pair?

Yes.

> I can imagine that working well in 2015.  I think in 2020 we'll surely find it too tight and chafing. Maybe that is enough.

I'd much rather allow an unlimited number of keys, but it's not
obvious to me that it's possible to do that.

I think that we need a protocol in which Bob knows N private keys,
Alice knows one of those keys, Alice can encrypt a message to Bob
using that key, Bob can decrypt it in time t(N), and an eavesdropper
who does not know any of the private keys can't distinguish the
message from random?

My protocol has t(N) linear in N -- Bob does tries decrypting with
each key.  Does anyone know of a protocol that scales better?

If we're willing to lose a bunch of the nice properties, we could just
include a short has of the public key.  To me, that seems like a
tradeoff that we'd be better off without.

--Andy

---

From: Erik Nygren <[email-masked]>
Date: Thu, 17 Apr 2014 11:05:16 -0400

If Alice sends a plaintext key label along with the message, the options
seem to be:

1) Don't send any key label resulting in t(N)
2) Send a small key label (eg, a value from 1-M) allowing for t(N/M) but
providing a passive listener additional visibility based on the size of M
3) Send a medium-sized key label (same as above) which seems like the worst
of all worlds since while this might allow for t(1) it also means a large M
4) Send a long byte-string key label which allows the server to pack in
enough information to allow it to be time-variant (eg, a timestamp plus an
encrypted version of the timestamp and more detailed routing information)

It seems like 4 and 2 are the most desirable options here?

         Erik

On Thu, Apr 17, 2014 at 10:52 AM, Andy Lutomirski <[email-masked]>wrote:

> > Do I understand that you intend one for normal operation, one more
> during rotations---and then for my example that different people want
> different crypto, another operation/rotation pair?
>
> Yes.
>
> >
> > I can imagine that working well in 2015.  I think in 2020 we'll surely
> find it too tight and chafing. Maybe that is enough.
> >
>

---

From: "Sniffen, Brian" <[email-masked]>
Date: Thu, 17 Apr 2014 12:35:59 -0400

On Apr 17, 2014, at 9:52 AM, "Andy Lutomirski" <[email-masked]> wrote:
> 
> , Bob can decrypt it in time t(N), and an eavesdropper

Surely the eavesdropper can measure the decryption delay, probe himself, and discover which key it was---unless every implementation carefully shuffles keys?

And now an adversary can cause N decryptions per initiated connection. Ouch.

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Apr 2014 11:51:53 -0500

> We’re at the wrong layer to fix an attack against TCP.  The right place to protect TCP is either in TCP itself, or by using IPsec.

Well, yes, but we're well past having clean layers now.  I wouldn't
_terribly_ mind an option where TLS keying can be used to key a TCP
encryption option.  That is, I'd not like it very much, but I'd accept
it.

> Those who won’t use TCP are doomed to re-create it. To get a UDP-based protocol to replace TCP for the web you’d need all of reliable delivery through (selective?) retransmissions, bandwidth detect…

Yes, but TCP has issues.  See mosh for an example of why one might
abandon TCP for UDP.  (Briefly: with UDP one gets mobility for free;
with TCP one can only get mobility via IP mobility protocols,
therefore one doesn't.)

> UDP is connectionless. As such, NAT devices don’t know when it’s done. So NAT mappings need to linger a lot longer after the last packet. TCP works better with NAT.

Yes, but for some application protocols (e.g., mosh) this is not a big deal.

> It would require an explanation about why this new wheel would be better than TCP in IPsec.

Because no one has cared to implement RFC5660 or anything like it.
IPsec as it is implemented and deployed does not provide TLS-like
guarantees that the peer at the other end remains the same for the
life of the connection (assuming local security).  This is a major
failure of IPsec, and a barely acknowledge failure at that.

If you want to use IPsec for end-to-end security then a) some parts of
the authentication process must move to higher layers, b) peer
continuity MUST be provided.  Any discussion of use of IPsec for
end-to-end security [outside small networks] without such an
acknowledgment of this just isn't credible.

Nico
--

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 17 Apr 2014 09:53:12 -0700

> And now an adversary can cause N decryptions per initiated connection. Ouch.

If N == 4 and the decryption operations are fast, this isn't so bad.

I wonder if there's a way to test a large number of private keys at
once.  If so, then the cost drops to O(log N).  Off the top of my
head, I can't think of a cryptosystem with that property.  For
example, there's a way to check a large number of Schnorr signatures
at the same time, but you're expecting all of them to be correct.
Here you want to check a large number of private keys at once and find
out whether any of them can decrypt a given message.

I know there are some serious cryptographers on the list.  Anyone?

--Andy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 10:00:15 -0700

> encrypted version of the timestamp and more detailed routing information)

Isn't that what draft-ekr-tls-new-flows effectively proposes?

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 17 Apr 2014 14:59:46 -0500

> If N == 4 and the decryption operations are fast, this isn't so bad.

Cryptographic negotiation attacks are already one of the most powerful
DDoS techniques available.  Making them 4x more effective is lethal.
Unless we want to say they're so dangerous as to be no *more* lethal
from quadrupling, this isn't okay.

I hesitate to ask, but: is it plausible to re-open the proof-of-work
conversation, so a server under load can, in the initial opportunistic
encryption phase, push back to a client and ask for a puzzle to be
solved?

> head, I can't think of a cryptosystem with that property.

I certainly don't expect to find any *pair* of cryptosystems with that
property, and continue to maintain that in 3 years we won't find two big
organizations willing to use exactly the same crypto.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Apr 2014 13:19:36 -0700

> encryption phase, push back to a client and ask for a puzzle to be

I don't think it's implausible (though I'm not completely sold yet).

One concern I would have is whether we understand the problem well
enough to actually specify this. I'm not an expert in this area, but weren't
there a bunch of concerns about designing puzzles that were effective
without being prohibitively expensive for mobile devices? How would
we design a new kind of puzzle (As opposed to messing with the puzzle
work factor) and then roll it out?

-Ekr

---

From: "Sniffen, Brian" <[email-masked]>
Date: Thu, 17 Apr 2014 16:26:35 -0400

On Apr 17, 2014, at 3:20 PM, "Eric Rescorla" <[email-masked]> wrote:
> without being prohibitively expensive for mobile devices?

Oh, I expect to deny service to users whose computational power is swamped by an adversary node's. I don't have a way to fix that. But conventional puzzles are enough to convert an adversary who could deny service to everybody---by overloading the server---to one who can only deny service to computationally weak clients, or when they overwhelmingly outnumber normal clients. 

And if we ever do come to terms on session resumption, that can help mobile clients a good bit. I understand most mobile clients keep sessions in persistent storage to keep them alive as long as possible for this reason.

---

From: Erik Nygren <[email-masked]>
Date: Thu, 17 Apr 2014 19:05:34 -0400

> Isn't that what draft-ekr-tls-new-flows effectively proposes?

Exactly, hence my proposal to include that in a DNS Service Binding
record.
The concern raised was that this could be used by a passive attacker
to further identify the hostname the client was connecting to.
By preference would be to take this approach but provide some guidance
on a way to help raise the bar.  For example, constructing this label with
something like:

    { timestamp, label_key_vers , AES(label_key, timestamp ||
SNI_routing_identifier || handshake_keyversion ) }

would reduce some of these attacks over just having a static value in the
label (which might
degenerate down to something with a static 1:1 identifier with the SNI
which would some of the
point of encrypting the SNI in the first place).

          Erik

---

From: Bill Frantz <[email-masked]>
Date: Sat, 19 Apr 2014 08:55:22 -0700

On 4/17/14 at 1:27 AM, [email-masked] (Yoav Nir) wrote:

> Those who won’t use TCP are doomed to re-create it. To get a UDP-based protocol to replace TCP for 
> the web you’d need all of reliable delivery through (selective?) retransmissions, bandwidth 
> detection, replay protection, a whole lot of things that took the transport community years to get 
> right. Yes, there have been many attempts, but there’s a reason TCP is still the protocol everyone 
> uses for pretty much any type of bulk transfer. And this is before we even begin to talk about 
> middleboxes dropping unrecognized UDP services.

Absolutely correct.

However, one could set up a DTLS session and then initialize the TCP protocol within that session.

I don't think anyone has considered this inversion before. It may not be useful, but...

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, CA 95032

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Apr 2014 19:33:57 +0300

> However, one could set up a DTLS session and then initialize the TCP protocol within that session.

You mean a security layer between the IP layer and the transport layer? 

> I don't think anyone has considered this inversion before. It may not be useful, but…

Except people who have implemented IPsec in transport mode. For compatibility with NAT, it can use UDP with port 4500.

Really, the only advantage of DTLS over IPsec is that the TLS handshake is easier to deploy than IPsec’s key exchange (IKE), because IKE demands mutual authentication, and deploying client credentials is so hard, some people would like us to remove it entirely from TLS 1.3.

What would work nicely (and some vendors have products that do this already) is initiating IPsec in a client/server model, where the client receives the details of the IPsec SA from the server. That transaction could run over UDP or even over HTTPS.  Of course, I think this is the wrong mailing list to discuss a suggestion like this.

Yoav

---

From: Bill Frantz <[email-masked]>
Date: Sat, 19 Apr 2014 10:13:58 -0700

On 4/19/14 at 9:33 AM, [email-masked] (Yoav Nir) wrote:

>Except people who have implemented IPsec in transport mode. For 
>compatibility with NAT, it can use UDP with port 4500.

Indeed IPsec is proof that it can work.

>Really, the only advantage of DTLS over IPsec is that the TLS 
>handshake is easier to deploy than IPsec’s key exchange 
>(IKE), because IKE demands mutual authentication, and deploying 
>client credentials is so hard, some people would like us to 
>remove it entirely from TLS 1.3.
>
>What would work nicely (and some vendors have products that do 
>this already) is initiating IPsec in a client/server model, 
>where the client receives the details of the IPsec SA from the 
>server. That transaction could run over UDP or even over 
>HTTPS.  Of course, I think this is the wrong mailing list to 
>discuss a suggestion like this.

If we can get IPsec to be practical for the TLS use cases, we 
can all go home. :-)

One of the disadvantages of putting TCP on top of the encrypted 
layer is that when a packet is resent it is re-encrypted. My 
crypto-plumber reflexes say that re-encryption can be dangerous 
with certain systems, but I can't remember the details. 
Apparently IPsec has avoided this problem.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Apr 2014 12:20:48 -0700

On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <[email-masked]> wrote:

> > Those who won't use TCP are doomed to re-create it. To get a UDP-based
> protocol to replace TCP for
> > the web you'd need all of reliable delivery through (selective?)
> retransmissions, bandwidth
> > right. Yes, there have been many attempts, but there's a reason TCP is
> still the protocol everyone
> I don't think anyone has considered this inversion before. It may not be
> useful, but..
>

This is how WebRTC DataChannels work, except that it's SCTP rather than TCP.

The WG did consider TCP but selected SCTP for a variety of reasons that
probably
don't bear going into here. You certainly could build the same thing with
TCP.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sat, 19 Apr 2014 12:40:48 -0700

> don't bear going into here. You certainly could build the same thing with

This is also how MinimaLT, CurveCP, and indeed TCP over IPSec
(assuming we fix the issues that stop IPSec at the application layer
from working) work. The flow control issues are easy: copy the
algorithm from TCP. The firewall issues are not.

There is also an issue with the size of Server Hellos: they cannot be
larger than the Client Hello in the first round to avoid
amplification. So you won't get a full X509 chain in in one round.
However, you can spend 2RTT and still beat the 1RTT over TCP solution.
If you want to change things up even more, send the certs after the
channel is established.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Apr 2014 12:50:17 -0700

> algorithm from TCP. The firewall issues are not.

Yes, the firewall issues are fairly complicated. The good news is that
they're quite a bit easier in client-server type applications because
servers generally have public IP addresses (otherwise you pretty
much cannot connect to them via TCP). Basically, either the client
is behind a network element (firewall/NAT) which lets UDP in and
out or it's not. If it is (estimates for this vary, but rumors are ~95%),
then client-server TCP over UDP variants should work.

The situation is of course much more complicated for P2P
applications, and in such applications you need ICE and generally
a media relay server.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Tue, 22 Apr 2014 22:08:45 +0000

On Apr 17, 2014, at 3:20 PM, "Eric Rescorla" <[email-masked]> wrote:
> enough to actually specify this. I'm not an expert in this area, but 
> weren't there a bunch of concerns about designing puzzles that were 
> effective without being prohibitively expensive for mobile devices?

We think about this problem a lot in the Password Hashing Competition (PHC)
See https://password-hashing.net/

The primary driver of the decision to add work factor is the entropy present in the secret, in this case the server name. Too much entropy and the work factor is wasteful, too little entropy and the work factor is hopeless.

If the defenders tune the work factor to allow them to process 10000 items a day with tolerable CPU consumption, then an attacker with similar resources can apply 10000 guesses brute force a single secret.
 
How often is any amount of work factor that's suitable for the defender going to present a significant obstacle to a real attacker attempting to guess the contents of SNI?

My first impression is to think SNI is unlikely to represent enough entropy to attackers in practice to make an additional work factor useful.

- Marsh
--------------------
Boilerplate disclaimers apply.

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 03:32:39 +0200 (CEST)

> conclusion.  If you need to protect SNI, then TOR or to a lesser extent

I agree.  If you need TOR, you should use TOR.

Encrypted SNI comes at a huge cost, and could at best provide
a benefit somewhere between completely negligible and absolutely none.

Whether the service provider uses multiple services on a host at
all, is up to the service provider.

What name the service provider chooses is up to the service provider.

Whether the content of the individual hosts is (close to) 100%
distinguishable by its traffic patterns is up to the hosting provider,
the service providers, the nature of their contents and the amount
of (or lack of) cooperation/synchronization among the service providers.

It would be crazy if any of the secret three agencies would spent
a huge amount of protective efforts so that they could refer to
their "secret hideout at 17, umpteen street" under the term
"secret hideout at 17, umpteen street", instead of simply
calling it an office or a laundry, or whatever.

The server name is simply routing information.  And it is not just
load-balancers that may want to be able to use that information
without having to open/terminate/participate the TLS communication,
it's also easier and cleaner for implementations at the endpoint
to do the server-side of TLS extension SNI "outside" of the TLS stack.

-Martin