Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Jerry Leichter]

On Sep 30, 2013, at 9:01 PM, "d.nix"  wrote:
> It's also worth pointing out that common browser ad blocking / script
> blocking / and site redirection add-on's and plugins (NoScript,
> AdBlockPlus, Ghostery, etc...) can interfere with the identification
> image display. My bank uses this sort of technology and it took me a
> while to identify exactly which plug-in was blocking the security
> image and then time to sort out an exception rule to not block it.
> 
> The point being - end users *will* install plug-ins and extensions
> that may interfere with your verification tools.
It goes beyond that.  A company named Iovation sells a service that's supposed 
to check a fingerprint of your machine against a database so that someone like 
a bank can determine if your login is supposed to come from this machine.  (It 
also leaves behind a cookie, and may blacklist some addresses).  Anyway, the 
result is a connection to "iesnare.something" when you go to your bank.  I run 
a Little Snitch on my Mac's; it reports and ask for approval for unknown 
connections.  So I see alerts pop up when I go to my bank and similar sites.  
Sometimes I block the connection, sometimes I let it through.  (Actually, it 
doesn't seem to affect the site's behavior either way.)

-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[d.nix]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> Found at: 
> 
>
> 
> 
> To quote from the above:
> 
> The idea is that if customers do not see their [preselected] image,
> they could be at a fraudulent Web site, dummied up to look like
> their bank’s, and should not enter their passwords.
> 
> The Harvard and M.I.T. researchers tested that hypothesis. In 
> October, they brought 67 Bank of America customers in the Boston
> area into a controlled environment and asked them to conduct
> routine online banking activities, like looking up account
> balances. But the researchers had secretly withdrawn the images.
> 
> Of 60 participants who got that far into the study and whose 
> results could be verified, 58 entered passwords anyway. Only two
> chose not to log on, citing security concerns.
> 
> This approach requires the customer to verify the image every log
> on. Conning them by replacing the image with, "Site undergoing 
> maintenance"[1] is fairly easy. With my approach, I would
> authenticate the bank's key once, when I establish an account or
> sign up for online banking. My software would check that
> authentication every time I log on after that. (If the bank decides
> to change it's key every year, I might need a new piece of paper
> every year -- which might get old after a few years.)
> 
> 
>> and http://en.wikipedia.org/wiki/Phishing#cite_note-88 which say 
>> simple things like "show the right image" don't work.
> 
> Found at: 
> 
>
> 
It's also worth pointing out that common browser ad blocking / script
blocking / and site redirection add-on's and plugins (NoScript,
AdBlockPlus, Ghostery, etc...) can interfere with the identification
image display. My bank uses this sort of technology and it took me a
while to identify exactly which plug-in was blocking the security
image and then time to sort out an exception rule to not block it.

The point being - end users *will* install plug-ins and extensions
that may interfere with your verification tools.

Dave
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJSSh7jAAoJEDMbeBxcUNAel+AIAIx5Y1M0zlQtPU14aKaIE0Eo
jpQRCRgY4X/g30EnNt5wh+umKPS7ZSwPg62GfLpmntijPsGCThXVxY62OfJpnZU9
uWh+AwNG3RkMn90w2at1YaCbOyXiPEwN/2PuRsJ+RRQRKu4hbJmF1/1X36ykoIAc
s6LZ44a1FpIX8uGg5D6yo/emse3ZaKB6XlhoYZfbNlEnUc63/Sj8mC8K7ErhQbRu
qM8/LayQHLNDy+xHFfHLS2v8EJUz8DOVXKWBxxNY6Ig2Z4g4oUbbrhP1pAo2S9J9
YIR/DO4I+epiAy6WvLl/H31EHqnne5qN7B+nOz8mXxH/yg3zMliVmNKI6UCypyM=
=PXyH
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Bill Frantz]

Rich - Thanks for chasing this study down. There is a lot of 
food for thought for all of us in it.


On 9/30/13 at 11:29 AM, rs...@akamai.com (Salz, Rich) wrote:

Bill said he wanted a piece of paper that could help verify his 
bank's certificate.  I claimed he's in the extreme minority who 
would do that and he asked for proof.


I can only, vaguely, recall that one of the East Coast big 
banks (or perhaps the only one that is left) at one point had a 
third-party cert for their online banking and that it 
"encouraged" phishing of their customers.  See also http://en.wikipedia.org/wiki/Phishing#cite_note-87


Found at: 


To quote from the above:

The idea is that if customers do not see their [preselected]
image, they could be at a fraudulent Web site, dummied up to
look like their bank’s, and should not enter their passwords.

The Harvard and M.I.T. researchers tested that hypothesis. In
October, they brought 67 Bank of America customers in the
Boston area into a controlled environment and asked them to
conduct routine online banking activities, like looking up
account balances. But the researchers had secretly withdrawn
the images.

Of 60 participants who got that far into the study and whose
results could be verified, 58 entered passwords anyway. Only
two chose not to log on, citing security concerns.

This approach requires the customer to verify the image every 
log on. Conning them by replacing the image with, "Site 
undergoing maintenance"[1] is fairly easy. With my approach, I 
would authenticate the bank's key once, when I establish an 
account or sign up for online banking. My software would check 
that authentication every time I log on after that. (If the bank 
decides to change it's key every year, I might need a new piece 
of paper every year -- which might get old after a few years.)



and http://en.wikipedia.org/wiki/Phishing#cite_note-88 which 
say simple things like "show the right image" don't work.


Found at: 


I believe this study is the one referred to in the NYT article 
above. This study started with 67 people, the same number 
mentioned above and the authors are also affiliated with Harvard 
and MIT. The steps they took to ethically use real accounts are 
worth reading.


The last test involved presenting a IE warning page, "There is a 
problem with this website's security certificate. The result was:


Of the 60 participants whose responses to prior tasks had
been verified, we were able to corroborate 57 participants’
responses to the warning page. Despite the overtness of the
warning page and its strong wording, 30 of 57 participants
(53%) entered their passwords. 27 participants (47%) did
not login.

Leaving me to say you shouldn't give the user an option to 
ignore security. I don't think I get a choice if an Apple or 
Microsoft software update fails signature verification.


Their conclusions:

Users will enter their passwords even when HTTPS
indicators are absent.

Users will enter their passwords even if their site-
authentication images are absent.

Site-authentication images may cause users to disre-
gard other important security indicators.

The last conclusion is interesting for evaluating other studies. 
They divided their subjects into three groups. Two used dummy 
accounts and one used their own accounts.


Role playing has a significant negative effect on the
security vigilance of study participants. Participants who
played roles disregarded more attack clues before withholding
their passwords than participants whose own passwords were at
risk.

Cheers - Bill

[1] The text used in the second reference's study is very enticing:

SAI Maintanance [sic] Notice:
[bank name] is currently upgrading our award
winning SAI feature. Please contact customer
service if your SAI does not reappear within the
next 24 hours.

---
Bill Frantz| I like the farmers' market   | Periwinkle
(408)356-8506  | because I can get fruits and | 16345 
Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los Gatos, 
CA 95032


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Salz, Rich]

Bill said he wanted a piece of paper that could help verify his bank's 
certificate.  I claimed he's in the extreme minority who would do that and he 
asked for proof.

I can only, vaguely, recall that one of the East Coast big banks (or perhaps 
the only one that is left) at one point had a third-party cert for their online 
banking and that it "encouraged" phishing of their customers.  See also 
http://en.wikipedia.org/wiki/Phishing#cite_note-87 and 
http://en.wikipedia.org/wiki/Phishing#cite_note-88 which say simple things like 
"show the right image" don't work.

/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[ianG]

I think, if we are about redesigning and avoiding the failures of the 
past, we have to unravel the false assumptions of the past...



On 20/09/13 01:21 AM, Phillip Hallam-Baker wrote:
...

Bear in mind that securing financial transactions is exactly what we
designed the WebPKI to do and it works very well at that.



Reasonable people may disagree with that claim.

PKI for the web was designed to secure *one small part* of the financial 
process -- sending credit card numbers over the net.  To secure 
financial transactions without limit, we'd need an end-to-end solution. 
 E.g., online banking (which comes much later) requires an 
authentication solution, which offering by WebPKI (the client cert) is 
infamously not used;  and, as a counterpoint, the biggest hacks occur at 
the server, being that "large part" of financial transactions that 
WebPKI explicitly ignored.


Further, "very well" is a gross exaggeration of marketing proportions. 
In order to say it works "very well" at even its small part of 
protecting access to servers, we'd have to solve the browser 
authentication problem that is at the root cause of phishing.  I grant 
that the phishing bug was addressed at a level of PKI-me-harder, but we 
still lack a solution...




Criminals circumvent the WebPKI rather than trying to defeat it. If they
did start breaking the WebPKI then we can change it and do something
different.



Oh, they broke it.  Criminals send an unauthenticated URL and the user 
goes to that URL.  The browser doesn't notice, the user doesn't notice, 
and the implementors conspire not to notice.  WebPKI is totally broken. 
 The fact that the criminals didn't follow the cutesy rules laid out in 
the WebPKI security model is not a circumvention but a breach and an 
excuse -- the rules weren't applicable to the real world.


And, regardless of whether we decide that it is circumvention or breach, 
nothing positive was ever done about it.  So we're left arguing about 
the point of something that is too easy to circumvent and doesn't get 
fixed.  WebPKI is either an historical oddity or an economic drag on 
real security.


(Quite where reasonable people might have a reasonable disagreement is 
where the breach/circumvention is;  that's an argument that will (and 
did) roll on for a decade, which is perhaps why it never gets fixed... 
insert long thread.)




But financial transactions are easier than protecting the privacy of
political speech because it is only money that is at stake. The
criminals are not interested in spending $X to steal $0.5X. We can do
other stuff to raise the cost of attack if it turns out we need to do that.

So I think what we are going to want is more than one trust model
depending on the context and an email security scheme has to support
several.



Yes.  Challenge is to get that into the supply chain.



If we want this to be a global infrastructure we have 2.4 billion users
to support. If we spend $0.01 per user on support, that is $24 million.
It is likely to be a lot more than that per user.

Enabling commercial applications of the security infrastructure is
essential if we are to achieve deployment. If the commercial users of
email can make a profit from it then we have at least a chance to co-opt
them to encourage their customers to get securely connected.



It's either that, or bypass completely.  I agree email looks difficult, 
and the economics suggest bypass not rebuild.




One of the reasons the Web took off like it did in 1995 was that
Microsoft and AOL were both spending hundreds of millions of dollars
advertising the benefits to potential users. Bank America, PayPal etc
are potential allies here.



Curiously (digression), Paypal bought Skype for a secure end-to-end 
solution to many of these problems.  They never capitalised on it.  Did 
they ever say why?




iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[John Kelsey]

On Sep 19, 2013, at 5:21 PM, Phillip Hallam-Baker  wrote:

>  Criminals circumvent the WebPKI rather than trying to defeat it. If they did 
> start breaking the WebPKI then we can change it and do something different.

If criminals circumvent the PKI to steal credit card numbers, this shows up as 
fraud and is noticed without any need for a Snowden.  Eavesdropping doesn't 
show up in such an obvious way.  

> But financial transactions are easier than protecting the privacy of 
> political speech because it is only money that is at stake. The criminals are 
> not interested in spending $X to steal $0.5X. We can do other stuff to raise 
> the cost of attack if it turns out we need to do that.

Also, criminals find it harder to spend a few million up front before they get 
the first payoff.  Nor can they appeal to patriotism or compel compliance via 
the law.  

> If we want this to be a global infrastructure we have 2.4 billion users to 
> support. If we spend $0.01 per user on support, that is $24 million. It is 
> likely to be a lot more than that per user.

It has to pay for itself ultimately, at least as well as email does. 

--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Russell Nelson]

Salz, Rich writes:
 > I would say this puts you in the sub 1% of the populace.  Most
 > people want to do things online because it is much easier and "gets
 > rid of paper."  Those are the systems we need to secure.  Perhaps
 > another way to look at it: how can we make out-of-band verification
 > simpler?

There's probably a whole O'Reilly book waiting to be written on
identity verification, but let me say it in one phrase: "closing the
loop". That means giving information electronically, and expecting to
get it back via a different path. So, as an example, the institution
prints are magic number (also in barcode or QRcode form so you can
scan it) on a piece of paper, and mails it to your address of
record. Or they call your phone number of record and ask you to enter
a magic number.

Or they ask for a time-proof-of-work. Let's say that you've been
posting to an online forum for some time (e.g. this mailing
list). They ask you to post a magic number to the mailing list in your
signature block. Somebody like Lucky Green could use this. Or The Well
members, presuming that The Well still exists in some form.

Same idea for Facebook, Google+, a blog, your personal website
(e.g. russnelson.com), your corporate website
(e.g. http://crynwr.com/~nelson/), etc. Anything where only you can
enter information just as you have been doing for years.

-- 
--my blog is athttp://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  | Sheepdog   
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

On Thu, Sep 19, 2013 at 5:11 PM, Max Kington  wrote:

>
> On 19 Sep 2013 19:11, "Bill Frantz"  wrote:
> >
> > On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:
> >
> >>> I know I would be a lot more comfortable with a way to check the mail
> against a piece of paper I
> >>
> >> received directly from my bank.
> >>
> >> I would say this puts you in the sub 1% of the populace.  Most people
> want to do things online because it is much easier and "gets rid of paper."
>  Those are the systems we need to secure.  Perhaps another way to look at
> it:  how can we make out-of-band verification simpler?
> >
> >
> > Do you have any evidence to support this contention? Remember we're
> talking about money, not just social networks.
> >
> > I can support mine. ;-)
> >
> > If organizations like Consumers Union say that you should take that
> number from the bank paperwork you got when you signed up for an account,
> or signed up for online banking, or got with your monthly statement, or got
> as a special security mailing and enter it into your email client, I
> suspect a reasonable percentage of people would do it. It is, after all a
> one time operation.
>
> As with other themes though, one size does not fit all. The funny thing
> being that banks are actually extremely adept at doing out of band paper
> verification. Secure printing is born out of financial transactions,
> everything from cheques to cash to PIN notification.
>
> I think it was Phillip who said that other trust models need to be
> developed. I'm not as down on the Web of trust as others are but I strongly
> believe that there has to be an ordered set of priorities. Usability has to
> be right up there as a near-peer with overall system security. Otherwise as
> we've seen a real attack in this context is simply to dissuade people to
> use it and developers, especially of security oriented systems can do that
> of their own accord.
>
> If you want to get your systems users to help with out of band
> verification get them 'talking' to each other. Perry said that our social
> networks are great for keeping spam out of our mailboxes yet were busy
> trying to cut out the technology that's driven all of this.
>
> Out of band for your banking might mean security printing techniques and
> securing your email, phoning your friends.
>

Bear in mind that securing financial transactions is exactly what we
designed the WebPKI to do and it works very well at that.

Criminals circumvent the WebPKI rather than trying to defeat it. If they
did start breaking the WebPKI then we can change it and do something
different.


But financial transactions are easier than protecting the privacy of
political speech because it is only money that is at stake. The criminals
are not interested in spending $X to steal $0.5X. We can do other stuff to
raise the cost of attack if it turns out we need to do that.

So I think what we are going to want is more than one trust model depending
on the context and an email security scheme has to support several.


If we want this to be a global infrastructure we have 2.4 billion users to
support. If we spend $0.01 per user on support, that is $24 million. It is
likely to be a lot more than that per user.

Enabling commercial applications of the security infrastructure is
essential if we are to achieve deployment. If the commercial users of email
can make a profit from it then we have at least a chance to co-opt them to
encourage their customers to get securely connected.

One of the reasons the Web took off like it did in 1995 was that Microsoft
and AOL were both spending hundreds of millions of dollars advertising the
benefits to potential users. Bank America, PayPal etc are potential allies
here.




-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

On Thu, Sep 19, 2013 at 4:15 PM, Ben Laurie  wrote:

>
>
>
> On 18 September 2013 21:47, Viktor Dukhovni wrote:
>
>> On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
>>
>> > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
>> > > and thus will start to be realistic for SMTP next year (provided
>> > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
>> > > with luck also a DANE-capable Exim release.
>> >
>> > What's wrong with name-constrained intermediates?
>>
>> X.509 name constraints (critical extensions in general) typically
>> don't work.
>>
>
> No. They typically work. As usual, Apple are the fly in the ointment.
>

The key to make them work is to NOT follow the IETF standard and to NOT
mark the extension critical.

If the extension is marked critical as RFC 5280 demands then the
certificates will break in Safari (and very old versions of some other top
tier browsers).

If the extension is not marked critical as CABForum and Mozilla recommend
then nothing breaks and the certificate chain will be correctly processed
by every current edition of every top tier browser apart from Safari.


The peculiar insistence that the extension be marked critical despite the
obvious fact that it breaks stuff is one of the areas where I suspect NSA
interference.


-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Max Kington]

On 19 Sep 2013 19:11, "Bill Frantz"  wrote:
>
> On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:
>
>>> I know I would be a lot more comfortable with a way to check the mail
against a piece of paper I
>>
>> received directly from my bank.
>>
>> I would say this puts you in the sub 1% of the populace.  Most people
want to do things online because it is much easier and "gets rid of paper."
 Those are the systems we need to secure.  Perhaps another way to look at
it:  how can we make out-of-band verification simpler?
>
>
> Do you have any evidence to support this contention? Remember we're
talking about money, not just social networks.
>
> I can support mine. ;-)
>
> If organizations like Consumers Union say that you should take that
number from the bank paperwork you got when you signed up for an account,
or signed up for online banking, or got with your monthly statement, or got
as a special security mailing and enter it into your email client, I
suspect a reasonable percentage of people would do it. It is, after all a
one time operation.

As with other themes though, one size does not fit all. The funny thing
being that banks are actually extremely adept at doing out of band paper
verification. Secure printing is born out of financial transactions,
everything from cheques to cash to PIN notification.

I think it was Phillip who said that other trust models need to be
developed. I'm not as down on the Web of trust as others are but I strongly
believe that there has to be an ordered set of priorities. Usability has to
be right up there as a near-peer with overall system security. Otherwise as
we've seen a real attack in this context is simply to dissuade people to
use it and developers, especially of security oriented systems can do that
of their own accord.

If you want to get your systems users to help with out of band verification
get them 'talking' to each other. Perry said that our social networks are
great for keeping spam out of our mailboxes yet were busy trying to cut out
the technology that's driven all of this.

Out of band for your banking might mean security printing techniques and
securing your email, phoning your friends.

>
> Cheers - Bill
>
> ---
> Bill Frantz| If the site is supported by  | Periwinkle
> (408)356-8506  | ads, you are the product.| 16345 Englewood Ave
> www.pwpconsult.com |  | Los Gatos, CA 95032
>
>
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Ben Laurie]

On 18 September 2013 21:47, Viktor Dukhovni wrote:

> On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
>
> > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
> > > and thus will start to be realistic for SMTP next year (provided
> > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
> > > with luck also a DANE-capable Exim release.
> >
> > What's wrong with name-constrained intermediates?
>
> X.509 name constraints (critical extensions in general) typically
> don't work.
>

No. They typically work. As usual, Apple are the fly in the ointment.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

On Wed, Sep 18, 2013 at 5:50 PM, Viktor Dukhovni
wrote:

> On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:
>
> > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
> >
> > > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
> > > > and thus will start to be realistic for SMTP next year (provided
> > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
> > > > with luck also a DANE-capable Exim release.
> > >
> > > What's wrong with name-constrained intermediates?
> >
> > X.509 name constraints (critical extensions in general) typically
> > don't work.
>
> And public CAs don't generally sell intermediate CAs with name
> constraints.  Rather undercuts their business model.
>
>
This is no longer the case. Best Practice is now considered to be to use
name constraints but not mark them critical.

This is explicitly a violation of PKIX which insists that a name constraint
extension be marked critical. Which makes it impossible to use name
constraints as they will break in Safari and a few other browsers.

The refusal to make the obvious change is either because people do not
understand the meaning of the critical bit or the result of some of that
$250 million being felt in the PKIX group. As I pointed out at RSA, the use
of name constraints might well have prevented the FLAME attack working.

-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Carl Wallace]

On 9/18/13 5:50 PM, "Viktor Dukhovni"  wrote:

>On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:
>
>> On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
>> 
>> > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
>> > > and thus will start to be realistic for SMTP next year (provided
>> > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
>> > > with luck also a DANE-capable Exim release.
>> > 
>> > What's wrong with name-constrained intermediates?
>> 
>> X.509 name constraints (critical extensions in general) typically
>> don't work.
>
>And public CAs don't generally sell intermediate CAs with name
>constraints.  Rather undercuts their business model.

The inability to constrain trust anchors doesn't help matters much either.


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Peter Gutmann]

Phillip Hallam-Baker  writes:

>I have not spent a great deal of time looking at the exact capabilities of
>PRISM vs the other programs involved because from a design point they are
>irrelevant. The objective is to harden/protect the infrastructure from any
>ubiquitous, indiscriminate intercept capability like the one Gen Alexander
>appears to have constructed.

Precisely.  I made the same point recently in an interview about PRISM, that a
well-designed, well-engineered protocol will be NSA-proof (or at least as NSA-
proof as you can get within reason).  It'll also be Russian mafia-proof,
Chinese-government-proof, and your-mother-proof.  There isn't some exotic
class of protocol or mechanism that's needed to resist the NSA, anything well-
designed and implemented can do it.

Peter.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Bill Frantz]

On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:


I know I would be a lot more comfortable with a way to check the mail against a 
piece of paper I

received directly from my bank.

I would say this puts you in the sub 1% of the populace.  Most 
people want to do things online because it is much easier and 
"gets rid of paper."  Those are the systems we need to secure.  
Perhaps another way to look at it:  how can we make out-of-band 
verification simpler?


Do you have any evidence to support this contention? Remember 
we're talking about money, not just social networks.


I can support mine. ;-)

If organizations like Consumers Union say that you should take 
that number from the bank paperwork you got when you signed up 
for an account, or signed up for online banking, or got with 
your monthly statement, or got as a special security mailing and 
enter it into your email client, I suspect a reasonable 
percentage of people would do it. It is, after all a one time operation.


Cheers - Bill

---
Bill Frantz| If the site is supported by  | Periwinkle
(408)356-8506  | ads, you are the product.| 16345 
Englewood Ave
www.pwpconsult.com |  | Los Gatos, 
CA 95032


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[ianG]

Hi John,

(I think we are in agreement here, there was just one point below where 
I didn't make myself clear.)



On 18/09/13 23:45 PM, John Kemp wrote:

On Sep 18, 2013, at 4:05 AM, ianG  wrote:


On 17/09/13 23:52 PM, John Kemp wrote:

On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker 


I am sure there are other ways to increase the work factor.


I think that "increasing the work factor" would often result in
switching the kind of "work" performed to that which is easier than
breaking secrets directly.



Yes, that's the logical consequence & approach to managing risks. Mitigate the 
attack, to push attention to easier and less costly attacks, and then start working 
on those.

There is a mindset in cryptography circles that we eliminate entirely the 
attacks we can, and ignore the rest.  This is unfortunately not how the real 
world works.  Most of risk management outside cryptography is about reducing 
risks not eliminating them, and managing the interplay between those reduced 
risks.  Most unfortunate, because it leads cryptographers to strange 
recommendations.


The technical work always needs doing. It's not that we shouldn't do our best 
to improve cryptographic protection. It's more that one can always bypass 
cryptographic protection by getting to the cleartext before it is encrypted.



Right.  So the amount of effort we should put in should not be dictated 
(solely) by received wisdom about perfect security, but (also) by how 
quickly we can push the bulk of the attackers elsewhere.  Thus releasing 
our costly resources for 'elsewhere'.


I wrote about this tradeoff many moons ago.  I called the preferred 
target Pareto-secure as a counterpoint to the expected 100% secure, 
which I defined as a point where there is no Pareto-improvement that can 
be made, because the attacker is already pushed elsewhere.


The other side of the coin is to have a gentler attitude to breaches.

When a breach is announced, we also need to consider whether anyone has 
actually lost anything, and whether the ones that weren't attacked have 
got good service.  A protocol is rarely broken for the user, even if the 
cryptographic world uses the word 'broken' for a few bits.  E.g., if one 
looks at the TLS changes of the last 5 years due to a series of attacks, 
there isn't much of a record of actual hacks to users.




That may be good. Or it may not.



If other attacks are more costly to defender and easyish for the attacker, then 
perhaps it is bad.  But it isn't really a common approach in our security world 
to leave open the easiest attack, as the best alternative.  Granted, this 
approach is used elsewhere (in warfare for example, minefields and wire will be 
laid to channel the attack).

If we can push an attacker from mass passive surveillance to targetted direct 
attacks, that is a huge win.  The former scales, the latter does not.


My point was that "mass passive surveillance" is possible with or without 
breaking SSL/TLS (for example, but also other technical attacks), and that it is often 
simpler to pay someone to create a backdoor in an otherwise well-secured system. Or to 
simply pay someone to acquire the data in cleartext form prior to the employment of any 
technical protections to those data. Other kinds of technical protections (not really 
discussed here so far) might be employed to protect data from such attacks, but they 
would still depend on the possibility for an attacker to acquire the cleartext before 
such protections were applied.



To some extent, mass passive surveillance is entirely possible because 
SSL/TLS is so poorly employed.  I haven't looked for a while, but it was 
always about 1% of web traffic.


This is the motive behind HTTPS Everywhere - All The Time.  Let's make 
SSL the norm not the exception.  Then we've got some security against 
passive surveillance, then we force the attacker to other attacks, which 
are typically much more expensive.



I would point out that it was historically the case that the best espionage was achieved 
by paying (or blackmailing) people close to the source of the information to retrieve the 
necessary information. The idea of the "mole". That would seem to still be 
possible.





"PRISM-Hardening" seems like a blunt instrument, or at least one which
may only be considered worthwhile in a particular context (technical
protection) and which ignores the wider context (in which such technical
protections alone are insufficient against this particular adversary).



If I understand it correctly, PRISM is or has become the byword for the NSA's 
vacuuming of all traffic for mass passive surveillance.  In which case, this is 
the first attack of all, and the most damaging, because it is undetectable, 
connects you to all your contacts, and stores all your open documents.

 From the position of a systems provider, mass surveillance is possibly the 
most important attack to mitigate.


If you yourself the systems provider, or a "bad" employee i

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Robin Alden]

> On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:
> > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
> > > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
> > > > and thus will start to be realistic for SMTP next year (provided
> > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
> > > > with luck also a DANE-capable Exim release.
> > >
> > > What's wrong with name-constrained intermediates?
> >
> > X.509 name constraints (critical extensions in general) typically
> > don't work.

Which is why the CAB Forum and Mozilla made the pragmatic move to promote
the use of X.509 name constraints as a non-critical extension.

> 
> And public CAs don't generally sell intermediate CAs with name
constraints.
> Rather undercuts their business model.
> 

Public CAs are starting to offer name-constrained intermediate CAs to
suitable customers.
Why wouldn't we? - It doesn't undercut our business model any more than
selling a wildcard certificate.

> --
>   Viktor.

Robin Alden
Comodo

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Salz, Rich]

> I know I would be a lot more comfortable with a way to check the mail against 
> a piece of paper I received directly from my bank.

I would say this puts you in the sub 1% of the populace.  Most people want to 
do things online because it is much easier and "gets rid of paper."  Those are 
the systems we need to secure.  Perhaps another way to look at it:  how can we 
make out-of-band verification simpler?

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Viktor Dukhovni]

On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote:

> On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:
> 
> > > This is only realistic with DANE TLSA (certificate usage 2 or 3),
> > > and thus will start to be realistic for SMTP next year (provided
> > > DNSSEC gets off the ground) with the release of Postfix 2.11, and
> > > with luck also a DANE-capable Exim release.
> > 
> > What's wrong with name-constrained intermediates?
> 
> X.509 name constraints (critical extensions in general) typically
> don't work.

And public CAs don't generally sell intermediate CAs with name
constraints.  Rather undercuts their business model.

-- 
Viktor.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[John Kemp]

On Sep 18, 2013, at 4:05 AM, ianG  wrote:

> On 17/09/13 23:52 PM, John Kemp wrote:
>> On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker  
>>> I am sure there are other ways to increase the work factor.
>> 
>> I think that "increasing the work factor" would often result in
>> switching the kind of "work" performed to that which is easier than
>> breaking secrets directly.
> 
> 
> Yes, that's the logical consequence & approach to managing risks. Mitigate 
> the attack, to push attention to easier and less costly attacks, and then 
> start working on those.
> 
> There is a mindset in cryptography circles that we eliminate entirely the 
> attacks we can, and ignore the rest.  This is unfortunately not how the real 
> world works.  Most of risk management outside cryptography is about reducing 
> risks not eliminating them, and managing the interplay between those reduced 
> risks.  Most unfortunate, because it leads cryptographers to strange 
> recommendations.

The technical work always needs doing. It's not that we shouldn't do our best 
to improve cryptographic protection. It's more that one can always bypass 
cryptographic protection by getting to the cleartext before it is encrypted. 
 
> 
> 
>> That may be good. Or it may not.
> 
> 
> If other attacks are more costly to defender and easyish for the attacker, 
> then perhaps it is bad.  But it isn't really a common approach in our 
> security world to leave open the easiest attack, as the best alternative.  
> Granted, this approach is used elsewhere (in warfare for example, minefields 
> and wire will be laid to channel the attack).
> 
> If we can push an attacker from mass passive surveillance to targetted direct 
> attacks, that is a huge win.  The former scales, the latter does not.

My point was that "mass passive surveillance" is possible with or without 
breaking SSL/TLS (for example, but also other technical attacks), and that it 
is often simpler to pay someone to create a backdoor in an otherwise 
well-secured system. Or to simply pay someone to acquire the data in cleartext 
form prior to the employment of any technical protections to those data. Other 
kinds of technical protections (not really discussed here so far) might be 
employed to protect data from such attacks, but they would still depend on the 
possibility for an attacker to acquire the cleartext before such protections 
were applied. 

I would point out that it was historically the case that the best espionage was 
achieved by paying (or blackmailing) people close to the source of the 
information to retrieve the necessary information. The idea of the "mole". That 
would seem to still be possible. 

> 
> 
>> "PRISM-Hardening" seems like a blunt instrument, or at least one which
>> may only be considered worthwhile in a particular context (technical
>> protection) and which ignores the wider context (in which such technical
>> protections alone are insufficient against this particular adversary).
> 
> 
> If I understand it correctly, PRISM is or has become the byword for the NSA's 
> vacuuming of all traffic for mass passive surveillance.  In which case, this 
> is the first attack of all, and the most damaging, because it is 
> undetectable, connects you to all your contacts, and stores all your open 
> documents.
> 
> From the position of a systems provider, mass surveillance is possibly the 
> most important attack to mitigate.

If you yourself the systems provider, or a "bad" employee in your organization, 
are not handing the necessary cleartext to the attacker…

>  This is because:  we know it is done to everyone, and therefore it is done 
> to our users, and it informs every other attack.  For all the other targetted 
> and active attacks, we have far less certainty about the targetting (user) 
> and the vulnerability (platform, etc).  And they are very costly, by several 
> orders of magnitude more than mass surveillance.

The issue for me is that it is becoming difficult to know whether one can 
reasonably trust service providers in the face of coercion. Both for the 
creation of good-enough technical protections, and the use of them. 

- johnk

> 
> 
> 
> iang
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Viktor Dukhovni]

On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote:

> > This is only realistic with DANE TLSA (certificate usage 2 or 3),
> > and thus will start to be realistic for SMTP next year (provided
> > DNSSEC gets off the ground) with the release of Postfix 2.11, and
> > with luck also a DANE-capable Exim release.
> 
> What's wrong with name-constrained intermediates?

X.509 name constraints (critical extensions in general) typically
don't work.

-- 
Viktor.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Bill Frantz]

On 9/18/13 at 6:08 AM, hal...@gmail.com (Phillip Hallam-Baker) wrote:


If I am trying to work out if an email was really sent by my bank then I
want a CA type security model because less than 0.1% of customers are ever
going to understand a PGP type web of trust for that particular purpose.
But its the bank sending the mail, not an individual at the bank.


I know I would be a lot more comfortable with a way to check the 
mail against a piece of paper I received directly from my bank 
(the PGP model). I would have no problem in entering a magic 
authentication string (the key fingerprint) into my mail agent 
to authenticate my bank. The security of my money is of more 
that trivial importance.


Second would be having my mail agent tell me that the mail came 
from the same place as the previous piece of email I received 
(the SSH model). This model would work for most of my friends 
where MitM is unlikely. In the cases where MitM worries became 
important, I could then check fingerprints.


The CA model lets a powerful attacker subvert the CA at any time 
ignoring both out of band and same-as-the-last-time 
authentications. I'm OK with CAs for credit card transactions. 
There's a $50 limit on my risk from fraud.


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


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Ben Laurie]

On 18 September 2013 15:30, Viktor Dukhovni wrote:

> On Tue, Sep 17, 2013 at 11:48:40PM -0700, Christian Huitema wrote:
>
> > > Given that many real organizations have hundreds of front end
> > > machines sharing RSA private keys, theft of RSA keys may very well be
> > > much easier in many cases than broader forms of sabotage.
> >
> > Or we could make it easy to have one separate RSA key per front end,
> signed
> > using the main RSA key of the organization.
>
> This is only realistic with DANE TLSA (certificate usage 2 or 3),
> and thus will start to be realistic for SMTP next year (provided
> DNSSEC gets off the ground) with the release of Postfix 2.11, and
> with luck also a DANE-capable Exim release.
>

What's wrong with name-constrained intermediates?


>
> For HTTPS, there is little indication yet that any of the major
> browsers are likely to implement DANE support in the near future.
>
> --
> Viktor.
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[ianG]

On 17/09/13 23:52 PM, John Kemp wrote:

On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker 


I am sure there are other ways to increase the work factor.


I think that "increasing the work factor" would often result in
switching the kind of "work" performed to that which is easier than
breaking secrets directly.



Yes, that's the logical consequence & approach to managing risks. 
Mitigate the attack, to push attention to easier and less costly 
attacks, and then start working on those.


There is a mindset in cryptography circles that we eliminate entirely 
the attacks we can, and ignore the rest.  This is unfortunately not how 
the real world works.  Most of risk management outside cryptography is 
about reducing risks not eliminating them, and managing the interplay 
between those reduced risks.  Most unfortunate, because it leads 
cryptographers to strange recommendations.




That may be good. Or it may not.



If other attacks are more costly to defender and easyish for the 
attacker, then perhaps it is bad.  But it isn't really a common approach 
in our security world to leave open the easiest attack, as the best 
alternative.  Granted, this approach is used elsewhere (in warfare for 
example, minefields and wire will be laid to channel the attack).


If we can push an attacker from mass passive surveillance to targetted 
direct attacks, that is a huge win.  The former scales, the latter does not.




"PRISM-Hardening" seems like a blunt instrument, or at least one which
may only be considered worthwhile in a particular context (technical
protection) and which ignores the wider context (in which such technical
protections alone are insufficient against this particular adversary).



If I understand it correctly, PRISM is or has become the byword for the 
NSA's vacuuming of all traffic for mass passive surveillance.  In which 
case, this is the first attack of all, and the most damaging, because it 
is undetectable, connects you to all your contacts, and stores all your 
open documents.


From the position of a systems provider, mass surveillance is possibly 
the most important attack to mitigate.  This is because:  we know it is 
done to everyone, and therefore it is done to our users, and it informs 
every other attack.  For all the other targetted and active attacks, we 
have far less certainty about the targetting (user) and the 
vulnerability (platform, etc).  And they are very costly, by several 
orders of magnitude more than mass surveillance.




iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

A few clarifications

1) PRISM-Proof is a marketing term

I have not spent a great deal of time looking at the exact capabilities of
PRISM vs the other programs involved because from a design point they are
irrelevant. The objective is to harden/protect the infrastructure from any
ubiquitous, indiscriminate intercept capability like the one Gen Alexander
appears to have constructed.

PRISM-class here is merely a handy label for a class of attack where the
attacker can spend upwards of $100 million to perform an attack which
potentially affects every Internet user. PRISM-class is a superset of
PRISM, BULLRUN, MANASAS, etc. etc.


2) SSL is not designed to resist government intercept

Back in 1993-6 when I was working on Internet security and payments at CERN
and the Web Consortium the priority was to make payments on the Web, not
make it resistant to government intercept. The next priority was to
establish the authenticity of news Web sites. There were several reasons
for that set of priorities, one of which was that the technology we had
available was limited and it was impractical to do more than one public key
operation per session and it was only practical to use public key some of
the time. Severs of the day simply could not handle the load otherwise.

Twenty years later, much has changed and we can do much more. The designs
do not need to be constrained in the way they were then.

It is not a question of whether email is encrypted in transport OR at rest,
we need both. There are different security concerns at each layer.


3) We need more than one PKI for Web and email security.

PGP and S/MIME have different key distribution models. Rather than decide
which is 'better' we need to accept that we need both approaches and in
fact need more.

If I am trying to work out if an email was really sent by my bank then I
want a CA type security model because less than 0.1% of customers are ever
going to understand a PGP type web of trust for that particular purpose.
But its the bank sending the mail, not an individual at the bank.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Albert Lunde]

Another consideration is that the NSA isn't the only bad actor out 
there. Improving the robustness of TLS and other security protocols will 
defend against other attacks.


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Viktor Dukhovni]

On Tue, Sep 17, 2013 at 11:48:40PM -0700, Christian Huitema wrote:

> > Given that many real organizations have hundreds of front end
> > machines sharing RSA private keys, theft of RSA keys may very well be
> > much easier in many cases than broader forms of sabotage.
> 
> Or we could make it easy to have one separate RSA key per front end, signed
> using the main RSA key of the organization.

This is only realistic with DANE TLSA (certificate usage 2 or 3),
and thus will start to be realistic for SMTP next year (provided
DNSSEC gets off the ground) with the release of Postfix 2.11, and
with luck also a DANE-capable Exim release.

For HTTPS, there is little indication yet that any of the major
browsers are likely to implement DANE support in the near future.

-- 
Viktor.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Perry E. Metzger]

On Tue, 17 Sep 2013 23:48:40 -0700 "Christian Huitema"
 wrote:
> > Given that many real organizations have hundreds of front end
> > machines sharing RSA private keys, theft of RSA keys may very
> > well be much easier in many cases than broader forms of sabotage.
> 
> Or we could make it easy to have one separate RSA key per front
> end, signed using the main RSA key of the organization.

Certainly, though the protection against active attacks doesn't
improve much in that situation. Merely doing DNS cache preloading
(I'd say poisoning but the host you're being pointed at would be
entirely legitimate!) or some other attacks could force a target to
use a particular server at a site, perhaps the one of several front
ends where you had stolen a key. It is hard for DNSSEC to defend
against this given that the DNS data is real, and as active attacks
go, it is quite cheap!

(This also makes various forms of certificate pinning/witnessing
harder, though not necessarily fatally so.)

I don't disagree with your point, of course. I just think defense in
depth requires that we consider all these possibilities and force
the attacker to spend as much as possible to get access to traffic
data and plaintext, and to do it only for single targets.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Christian Huitema]

> Given that many real organizations have hundreds of front end
> machines sharing RSA private keys, theft of RSA keys may very well be
> much easier in many cases than broader forms of sabotage.

Or we could make it easy to have one separate RSA key per front end, signed
using the main RSA key of the organization.

-- Christian Huitema


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Jerry Leichter]

On Sep 17, 2013, at 5:31 PM, Viktor Dukhovni  wrote:
> ...And indeed the FUD around the NIST EC curves is rather unfortunate.
> Is secp256r1 better or worse than 1024-bit EDH?
Given our state of knowledge both of the mathematics, and of games NSA has been 
playing, I don't believe anyone can give a meaningful answer to that question.  
There's a second, related question:  How are attacks on the two systems 
correlated?  If one falls, do we need to lower our estimate of the strength of 
the other?  In the case of an attack using a practical quantum computer, "very 
strongly correlated"; in the case of improvements along the lines of current 
integer factoring algorithms, "not very strongly correlated".  Over all, one 
has to make guesses.  I'd put them as "somewhat correlated".

-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Viktor Dukhovni]

On Tue, Sep 17, 2013 at 05:01:12PM -0400, Perry E. Metzger wrote:

> (Note that this assumes no cryptographic breakthroughs like doing
> discrete logs over prime fields easily or (completely theoretical
> since we don't really know how to do it) sabotage of the elliptic
> curve system in use.)
> 
> Given that many real organizations have hundreds of front end
> machines sharing RSA private keys, theft of RSA keys may very well be
> much easier in many cases than broader forms of sabotage.

There is also I suspect a lot of software with compiled-in EDH
primes (RFC 5114 or other).  Without breaking EDH generally, perhaps
they have better precomputation attacks that were effective against
the more popular groups.

I would certainly recommend that each server generate its own EDH
parameters, and change them from time to time.  Sadly when choosing
between a 1024-bit or a 2048-bit EDH prime you get one of
interoperability or best-practice security but not both.

And indeed the FUD around the NIST EC curves is rather unfortunate.
Is secp256r1 better or worse than 1024-bit EDH?

-- 
Viktor.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[Perry E. Metzger]

On Tue, 17 Sep 2013 16:52:26 -0400 John Kemp  wrote:
> On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker
>  wrote:
> > The objective of PRISM-hardening is not to prevent an
> > attack absolutely, it is to increase the work factor for the
> > attacker attempting ubiquitous surveillance.
> > 
> > Examples include:
> > 
> > Forward Secrecy: Increases work factor from one public key per
> > host to one public key per TLS session.
> 
> How does that work if one of PRISMs objectives is to compromise
> data _before_ it is transmitted by subverting its storage in one
> way or another?
> 
> Forward secrecy does nothing to impact the "work factor" in that
> case.

So, PFS stops attackers from breaking all communications by simply
stealing endpoint RSA keys. You need some sort of side channel or
reduction of the RNG output space in order break an individual
communication then.

(Note that this assumes no cryptographic breakthroughs like doing
discrete logs over prime fields easily or (completely theoretical
since we don't really know how to do it) sabotage of the elliptic
curve system in use.)

Given that many real organizations have hundreds of front end
machines sharing RSA private keys, theft of RSA keys may very well be
much easier in many cases than broader forms of sabotage.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

[John Kemp]

On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker  wrote:

> My phrase PRISM-Proofing seems to have created some interest in the press.
> 
> PRISM-Hardening might be more important, especially in the short term. The 
> objective of PRISM-hardening is not to prevent an attack absolutely, it is to 
> increase the work factor for the attacker attempting ubiquitous surveillance.
> 
> Examples include:
> 
> Forward Secrecy: Increases work factor from one public key per host to one 
> public key per TLS session.

How does that work if one of PRISMs objectives is to compromise data _before_ 
it is transmitted by subverting its storage in one way or another?

Forward secrecy does nothing to impact the "work factor" in that case.

> 
> Smart Cookies: Using cookies as authentication secrets and passing them as 
> plaintext bearer tokens is stupid. It means that all an attacker needs to do 
> is to compromise TLS once and they have the authentication secret. The HTTP 
> Session-ID draft I proposed a while back reduces the window of compromise to 
> the first attack.
> 
> 
> I am sure there are other ways to increase the work factor. 

I think that "increasing the work factor" would often result in switching the 
kind of "work" performed to that which is easier than breaking secrets 
directly. That may be good. Or it may not. "PRISM-Hardening" seems like a blunt 
instrument, or at least one which may only be considered worthwhile in a 
particular context (technical protection) and which ignores the wider context 
(in which such technical protections alone are insufficient against this 
particular adversary).  

- johnk
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[Cryptography] PRISM-Proofing and PRISM-Hardening

[Phillip Hallam-Baker]

My phrase PRISM-Proofing seems to have created some interest in the press.

PRISM-Hardening might be more important, especially in the short term. The
objective of PRISM-hardening is not to prevent an attack absolutely, it is
to increase the work factor for the attacker attempting ubiquitous
surveillance.

Examples include:

Forward Secrecy: Increases work factor from one public key per host to one
public key per TLS session.

Smart Cookies: Using cookies as authentication secrets and passing them as
plaintext bearer tokens is stupid. It means that all an attacker needs to
do is to compromise TLS once and they have the authentication secret. The
HTTP Session-ID draft I proposed a while back reduces the window of
compromise to the first attack.


I am sure there are other ways to increase the work factor.



-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography