Re: [TLS] DNS-based Encrypted SNI

[Brian Sniffen]

Eric Rescorla  writes:

> On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian  wrote:
>
>> Looks neat.
>>
>> 1) TFO DOS vector: is the idea servers will disable TFO under strain but
>> not be able to disable ESNI?
>>
>
> I hadn't thought about it, but that seems right. I'm not really seeing why
> this is a DOS vector? At present, if you're able to pass a routability
> test, you can force a server to do a DH exchange and a signature, so
> forcing them to do ESNI decryption doesn't seem like it's that much of an
> amplification.

This is the same worry I had talking about ESNI the first time: if
experiencing a lot of load, a server operator might like to route the
load-generating customers / apps / users to a different set of servers.
To do that, he needs to know which customers / apps / users are inviting
the load.  Is this a flash crowd to exampleA.com or exampleB.com?
Having to do crypto to determine that makes it *much* more expensive.
It rules out a bunch of ways of doing it on a separate device that
doesn't have the decryption key.

I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?  That takes away the
routability test---they just test a sample of what's on the wire, but
that's probably okay.

>> 2) “clients might opt to attempt captive portal detection to see if they
>> are in the presence of a MITM proxy, and if so disable ESNI.”
>>
>> If I’m operating a great firewall, I can use this to discover dissidents,
>> right?  Either they send me dangerous SNI values or they are configured to
>> not disable ESNI, and taking the fifth is fatal. To protect them, I think
>> nobody can have this mode.
>>
>
> This doesn't sound right to me. The idea here is that you only disable ESNI
> if the attacker is able to generate a valid TLS connection to a
> *non-default* root, which means that they are MITM-capable, which nation
> state firewall operators typically are not. And of course if they are, then
> you have real problems. Can you walk me through the flow you have in mind.

My nation-state operator adversaries typically are MITM-capable.  Hunh.
And yes, I have real problems!  Lucky me.

But to generalize: even if it can't be done at the GFWoC, it's still
dangerous if done a cafe at a time.

>> 3) How many bits does this offer? Hiding in a set of a million uniform
>> hosts is 20 bits,
>
>
> Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits
> strong in the sense that the attacker can do a computation of cost 2^{20}.n
>
>
> and the nonuniformity will accrue to the adversary’s benefit. Active
>> probing will unmask visitors to dissident sites.
>>
>
> I don't really follow this. Can you explain?

I think it's at most 20 bits strong: the attacker can do a computation
of cost 2^{20}, and crack the anonymity.  It involves 2^{20}
cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

But I think it's a *lot* weaker than 2^{20}: the needles of the
adversary's search are not uniformly distributed.  So he can block the
most popular site for a day.  That doesn't take off 1 bit; that takes
off the vast majority of the clients.  If sites are on a power-law
distribution, it gets down to where the remaining 2^5 are rubber-hosable
in just a few experiments.

-Brian

> -Ekr
>
>
>
> I worry that this tool is so weak against a GFW-style adversary for the
>> purpose of allowing dissident access to restricted web sites that it will
>> be dangerous if released. But maybe I misunderstand the purpose. If this is
>> just to keep Western ISPs from monkeying with traffic, sure, ship it.
>> Labelling the encryption with its strength as applied, or showing CDNs and
>> ISPs how to work out some bounds, seems one way to help users understand
>> whether this can help them or put them more at risk.
>>
>> --
>> Brian Sniffen
>>
>>

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Brian Sniffen]

Having promised a review before August 18, I have three issues I'd like
to talk about.  But first, thanks for keeping pushing on this.  I am not
sure it will ever see wide adoption, but we'll surely never find out if
we don't try.


## Don't stand out

I think the requirement that the browser check the CT log and perform
DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I
don't expect most browsers to do that most times.  Am I missing
something?


## CDN integration

> If N multiple domains on a CDN are acceptable fronts, then we may
> want some way to indicate this without publishing and maintaining N
> separate tokens.

Those multiple domains will not share TLS keys (or will be under a TLS
wildcard), so delegation to a certificate is enough to cover this.  I
think you can just cut this paragraph, but maybe I don't know something
about some sort of CDN?


## Security considerations: DDoS

In section 6, I'm glad to see analysis vs the ddos requirements in 2.3.
I'm not sure I agree with the quick result:

1) The forwarding server can be used as a reflector.  Under some
   circumstances it should back off.

2) Under CPU load, the forwarding server will presumably start refusing
   early data (especially early data with TCP Fast Open!).  Is it
   necessary to say anything more here?  Or is the ordinary behavior of
   flaky early data sufficient?

   Particularly: what should clients do when early data is refused?  Try
   again with this in the main data section?  Give up?

-Brian

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Brian Sniffen]

Sean Turner <s...@sn3rd.com> writes:

> At our IETF 99 session, there was support in the room to adopt 
> draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the 
> list so please let the list know whether you support adoption of the draft 
> and are willing to review/comment on the draft before 20170818.  If you 
> object to its adoption, please let us know why.

I support wg adoption of this draft and am willing to review before
20170818.

-Brian

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Brian Sniffen]

Kyle Rose <kr...@krose.org> writes:

> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen <bsnif...@akamai.com> wrote:
>
>> I could imagine making the server ECDH share dependent on the
>> client ECDH share, plus a local random value.  At the end of the
>> session, the server discloses that random value, showing that it
>> properly constructed a fresh ECDH share.
>>
>> Then the client has an opportunity to notice---this session didn't have
>> a (retrospective) proof of proper generation of the server ECDH share,
>> and so may involve key reuse in a dangerous way.
>>
>> This doesn't stop the server from logging the session key, of course.
>>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.

Yes, but it adds a storage requirement in proportion to the number of
evil acts taken.  For the same reason we find large-key cryptography
interesting---now the adversary has to smuggle out megabytes---we might
like this.

> (Your proposal is
> interesting, but because it neatly solves the problem of DH share reuse
> without requiring some kind of CT-like infrastructure, not because it
> somehow addresses the evil endpoint problem. On the downside, it also may
> have implications for amplification DoS.)

Yes: I'd expect a large operator to drop support for this extension
under load, exactly when they switch to pre-generated ECDH keys.  When
they must further switch to re-used keys, that will be silent.

Conversation elsewhere raises a practical point: browsers don't want to
alert the user on every aborted connection.  But a bad server can
accept this extension, reuse a ECDH share, and then RST the
connection rather than properly terminate it.  All I can offer there is
the idea that the client *should* alert when *it* closes the connection
and doesn't get back a proof of proper key generation.

-Brian

-- 
Brian Sniffen <bsnif...@akamai.com>
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Brian Sniffen]

Ted Lemon <mel...@fugue.com> writes:

> On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 
> wrote:
>> What I am trying to avoid is the ability to *surreptitiously* subvert a 
>> protocol that’s assumed to be secure.
>
> You don't seem to be hearing what I'm trying to say.   What you are
> proposing is physically impossible.

Is it?  I could imagine making the server ECDH share dependent on the
client ECDH share, plus a local random value.  At the end of the
session, the server discloses that random value, showing that it
properly constructed a fresh ECDH share.

Then the client has an opportunity to notice---this session didn't have
a (retrospective) proof of proper generation of the server ECDH share,
and so may involve key reuse in a dangerous way.

This doesn't stop the server from logging the session key, of course.

I *think* the shape I describe above fits into an extension, so (a) it
doesn't have to be done to ship TLS 1.3, and (b) it can be available for
use in general purpose browsers, and then disabled for the "enterprise"
case, and (c) I don't have to worry through the performance implications
of not being able to pre-generate a stack of ECDH shares.

-Brian

-- 
Brian Sniffen <bsnif...@akamai.com>
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Separate APIs for 0-RTT

[Brian Sniffen]

Steven Valdez <sval...@google.com> writes:

> Confirming that BoringSSL is using a single API for early/regular data,
> since we ran into issues/complications with our implementation of dual APIs
> with our use cases.

I predict that those are exactly the places you're going to have later
security incidents.  In particular, the use case of fusing the early and
regular data into a single stream is going to lead to problems like
Triple Handshake.

The history of APIs where some bits have different secrecy, freshness,
or authentication than the rest says they all end up with bugs related
to user assumptions that blur away the difference.

-Brian

-- 
Brian Sniffen <bsnif...@akamai.com>
/(* Akamai - Faster Forward

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Brian Sniffen]

Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:

> On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
>> It certainly was. But then the clear text SNI is a gaping privacy hole
>> in TLS, the kind of issue that should keep us awake at night until it is
>> resolved. We need to make sure that we make progress, rather than rehash
>> the old arguments. Maybe we should invest some time and document the
>> various proposals in a draft. I am willing to work on that. Any other
>> volunteers?
>
> I agree with Christian's assessment of the problem, and i'd be
> interested in collaborating on such a draft.

Who's the audience for that draft?  If it's meant to document the blind
alleys we've found, perhaps we could list both alleys, and the walls at
the end:

  - hash the name [adversaries can hash too]
  - hash the name with a salt [adversaries can check the salted hash
too, as if operating all the banned sites]
  - encrypt the SNI under the pre-shared key

But beware of:

  - the adversary can replay this SNI and see what site he gets
  - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
no operations that scale linearly with number of sites hosted)
  - not everybody's going to do this, not even every TLS 1.3 instance
  - if networks can't track activity, some will push users to stay on
TLS 1.2.

-Brian

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] security considerations for draft-rescorla-tls-subcerts

[Brian Sniffen]

I'm trying to understand the adversary model in which Delegated
Credentials are helpful.  It seems like if you weren't going to sign off
on a cloud service provider getting a certificate before, you *probably*
shouldn't let them have a delegated credential now---but if you were
going to do so, *and* you don't believe revocation works (wise!), now
you can offer a delegated credential and be safer?

That corresponds to an adversary who can compromise a cloud service and
learn the customers' private keys---but can only do so rarely.  Now
instead of having ~ 1 year of use of your certificate, that adversary
has a few days of use of your credential.  But if the cloud service
is regularly breached, you're as bad off as before (but no worse?)

It sounds like the first years of delegated credentials will see them
used in tandem with split systems (Lurk, Akamai and Cloudflare's various 
patented
approaches)---then the primary benefit of delegated credentials is lower
latency for session establishment.

But maybe the idea is to avoid the first circumstance and emphasize that
these are for the second case.  Authors, can you describe what you have
in mind?

Thanks,
Brian

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Interest in draft-sullivan-tls-exported-authentication

[Brian Sniffen]

Can you help me understand what this means?

  servers that are authoritative for multiple domains the same
  connection but do not have a certificate that is simultaneously
  authoritative for all of them

I'm sure there's a word or two missing between "domains" and "the" in
the first line, but I'm not sure what they are.


More generally, it's great to see a replacement for renegotiation.  Can
you expand (maybe just here?) on the last paragraph of the security
considerations?  I think you mean that the sender of an authenticator
can't tell when it was received & understood.  But I'm not sure the
receiver can tell when it was sent---say, in the case of a smartcard
insertion, or access to a key from satisfying some local attestation
scheme, whether that key access precedes or follows the sending of a
request.

-Brian

Nick Sullivan <nicholas.sulli...@gmail.com> writes:

> All,
>
> I have updated the draft in preparation for the IETF 98:
> https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01
>
> The details of the protocol haven't changed, but I've included some
> security considerations after speaking with Karthikeyan Bhargavan and
> others about the cryptographic soundness of the construction.
>
> Nick
>
> On Tue, Jan 3, 2017 at 8:59 PM Joseph Salowey <j...@salowey.net> wrote:
>
>> There seemed to be support for draft-sullivan-tls-exported-authentication
>> (https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)
>> in Seoul.   Since there has not been much discussion of this draft on the
>> list we are giving the working group a chance to review the draft before
>> calling for adoption later this month.
>>
>> Cheers,
>>
>> J
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Brian Sniffen]

__
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  
>>> comment is that over time various industries have learned what it takes to 
>>> "Deliver a stable product".    We did not >>want to invest millions in 
>>> these debugging networks.  But  we learned the hard way,  that it was 
>>> necessary.
>>> I am not a member of the banking coalition that started this subject,  nor 
>>> of the banking industry at all,  but I certainly understand their 
>>> perspective and am concerned about  the same >>unmanageable future they 
>>> described.
>
>>Do  Akami, Cloudlflare and Google magically not have these problems?
> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.
> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we 
> might do them the courtesy of not thinking that they are foolish to do so.   
> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <mackerm...@bcbsm.com>
>> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
>> wrote:
>>> From the perspective an Enterprise that runs these applications and has 
>>> invested HEAVILY in the debugging networks.
>>>
>>> The reason we are debugging these networks is so that "The 5-6 order of 
>>> magnitude of folks using them"  will have good service.  If they do not,  
>>> they will consider competitors and/or generate a litany service calls or 
>>> complaints.        I.E.    When these "Folks"  are slow or not working they 
>>> are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable 
>> product at a competitive price are rewarded, while those who fail to deliver 
>> or deliver at an unreasonable cost are not? (Some hand waiving).
>>
>> If all providers failed to deliver or delivered an inferior product, then it 
>> might indicate a major course correction is needed. But I don't think that's 
>> the case here.
>>
>> Jeff
>>
>>
>> The information contained in this communication is highly confidential and 
>> is intended solely for the use of the individual(s) to whom this 
>> communication is directed. If you are not the intended recipient, you are 
>> hereby notified that any viewing, copying, disclosure or distribution of 
>> this information is prohibited. Please notify the sender, by electronic mail 
>> or telephone, of any unintended receipt and delete the original message 
>> without making any copies.
>>
>>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
>>nonprofit corporations and independent licensees of the Blue Cross and Blue 
>>Shield Association.
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Brian Sniffen]

Erik Nygren  writes:

> I'm also very supportive for the reasons you outline.
>
> However, I think we should consider calling it TLS 4 or TLS 4.0 or TLS 5.
>
> In particular, much of the non-technical audience still calls it "SSL" (pet
> peeve of many of us, I suspect) and having a version number clearly greater
> than SSLv3 and not confusing with SSLv2 would be quite valuable.  "TLS 2"
> may have risk for unfortunate confusions with SSLv2 and SSLv3.

That is wise.

What discussions were deferred as "this is just 1.3, wait for 2.0" that
will legitimately come back out of the woodwork if this is renamed to
TLS X, X > 1.9?

-Brian

> Another reason to avoid 1.3 is Western culture negative connotations around
> "tls13" which TLS 1.3 will get abbreviated as.
>
> - Erik
>
>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>
> On Aug 30, 2016 3:35 PM, "Dave Garrett"  wrote:
>
>> On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote:
>> > I support this change as long as there is no technical change (version
>> ID remains 0x0304).
>>
>> To reiterate, I am also against changing the version ID. However, I do
>> think it's worth updating the context string version number, otherwise it'd
>> be a little unnecessarily confusing there. (trivial change to key
>> derivation, but not wire format) I've also made a point to tweak references
>> to the on-the-wire version value to refer to it as a "version ID" rather
>> than just version, to make it very clear that this is really just an
>> arbitrary codepoint and shouldn't be read as 3.4.
>>
>> I've made the changes for a WIP branch, here (not a PR, as of yet):
>> https://github.com/tlswg/tls13-spec/compare/master...
>> davegarrett:tls2rebranding
>>
>> Going through the motions of doing the renaming now is useful to see if
>> there's anything that is more affected than initially expected, such as the
>> context strings having the version in there directly as a string (they're
>> designed to be updated as-needed, so this shouldn't be a problem).
>>
>>
>> Dave
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Brian Sniffen]

Hilarie Orman  writes:

>>  From: Derek Atkins 
>>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>
>>  "Steven M. Bellovin"  writes:
>
>>  > Yes.  To a large extent, the "IoT devices are too puny for real
>>  > crypto" is a hangover from several years ago. It was once true; for
>>  > the most part, it isn't today, but people haven't flushed their cache
>>  > from the old received wisdom.
>
>>  This is certainly true for AES, mostly because many small chips are
>>  including AES accelerators in hardware.  It's not quite true for public
>>  key solutions; there are still very small devices where even ECC takes
>>  too long (and yes, there are cases where 200-400ms is still too long).
>
>>  > It pays to look again at David Wagner's slides from 2005, on sensor
>>  > nets and crypto:
>>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>>  >
>
> Unattended sensors with wifi present an unsolved crypto problem.  They
> can last 10 years on an AA battery without crypto, probably well less
> than a year if they have to do any kind of encryption.  These things
> will be everywhere, providing the data that will underly all kinds of
> decision-making.

Assuming there are *some* integrity requirements for the data, and that
they are deploying 32-bit ARM with AES support (stipulating that ~every
CPU will have AES support in a few years, as ~every CPU sold does
today), we're talking about *either* an ECDHE negotiation every few
months or a pre-shared key, good for ten years.

AES-GCM with hardware support compares favorably to SHA-2 without
hardware support, so if they've been able to last 10 years before, they
should do just fine in the future.  The old devices won't last forever,
and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
for ten years after 1.3 is out.

-Brian

> Although much of the solution may lie in hardware innovation, the
> world really does need minimal crypto algorithms.
>
> Hilarie
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls