Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Ian G]

Frank Hecker wrote:

Nelson B Bolyard wrote:

What does "https cannot be easily shared across one IP numbers" mean?


I presume Ian is referring to the case of multiple virtual hosts sharing 
a single IP address (due to lack of SNI support in deployed versions of 
Apache).



Yes;  one Apache httpd opens SSL port, and this can (effectively) be 
only used for one certificate.


This is because the design assumed that the certificate choice was made 
outside the protocol, so there was no need to select.  TLS/SNI solves this.


To be fair, there are a number hacks:  using other port numbers, using 
shared certs, etc.  Left as an exercise to the reader...


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Frank Hecker]

Nelson B Bolyard wrote:

What does "https cannot be easily shared across one IP numbers" mean?


I presume Ian is referring to the case of multiple virtual hosts sharing 
a single IP address (due to lack of SNI support in deployed versions of 
Apache).


Frank

--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Ian G wrote, On 2008-12-04 05:38:
> The first cause of the failure to use SSL for security is that https
> cannot be easily shared across one IP numbers, a crucial, limited
> resource.

What does "https cannot be easily shared across one IP numbers" mean?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Ian G]

Nelson B Bolyard wrote:
(Snipped.  Your interpretation is not inaccurate but isn't where we are 
heading.)



I think this list is NOT the place for the debate over the superiority
of open vs. closed source software.  This is the open source locker room,
not the open/closed source battle field.



Agreed, all.


Now, if the discussion can be steered to how Mozilla's crypto can succeed at
becoming as popular as Skype may be, WITHOUT it having to resort to
- closed source,


Indeed, if we look at Skype's closed source, it isn't really an 
advantage to them in security or popularity terms, only in competition, 
which doesn't interest us here, so much.




- proprietary designs (restricted intellectual property),


Sure, I concur with that, for the same reasons as open source.



- being a closed system with no interoperability,
that may be worthwhile for this forum, IMO.



This may be an issue, but let's see how it develops.  My issue is not 
one of source, open v. closed, but one of:


standards v. non-standards.

Before we get to that, let's see how the open source thing works and see 
if we have an agreement on that.


Open source leads to interoperability and the ability for any number of 
players to play in the market.  This counterbalances the economies of 
scale in IT, and holds back the dominant players -- Microsoft -- by 
ensuring there is a steady series of small ideas from small players. 
Because it is *our net* we also feel good about these things, which has 
a very important side-effect:  people want to contribute and they want 
to download when the product is open.


That's Mozilla's space & place; agreed?  And, we are probably agreed 
that open source is better for security [1] so I'll assume that too.


Now, there is a side-effect of the interoperability argument that 
creates a need for *standards*.  Simply put, so that all can play, the 
new successful technology needs to be turned into a standard.


The problem with this is that it slows down any change.  Indeed, by some 
lights it may make change impossible, or reduce it to only trivial or 
inoffensive things [2].


What's the problem with that?  Well, it might be that slowness is the 
price of open source and interoperability, combined, and for general 
purpose open source we might accept that price.  The IETF is the 
expression of our acceptance of the price, in the net.  However, there 
is one exception to that where it isn't so rosy:  security.




For this, let me leap across to Boyd's OODA model.  In Boyd's world of 
observe-orient-decide-act, he modelled combat between adversaries.  This 
happens to match security;  we have the defenders and attackers.  OODA 
is a loop; what he presents as one for each:  one adversary goes through 
OODA, the other does too, again the first, again the other each time 
bettering their position w.r.t. last round, each time trying to out-do 
the other.


Here's the punchline:  the one who can turn faster wins.  The one who 
can turn inside the other guy's OODA (this metaphor is taken from the 
old fighter combat days of Spitfires v. Messerschmitt 109s) is the one 
that gains more each time, and eventually wins [3].


We can measure the times that defender and attacker can turn their OODA 
loops .  Suffice to say, in the internet world of security, the attacker 
turns in his loop around much faster than the defender.


To the extent that this model applies, the difference is so severe in 
some areas that it is "game over."  Assuming a real combat as opposed to 
a parade ground review, the attackers will turn their OODA loop faster, 
much faster, and win.  Examples are spam, phishing, viruses, malware, 
etc;  as soon as a defence comes out, the attacker has turned inside and 
attacked us from elsewhere.  Proof?  When was the last time that you 
heard of one of these things going down in volume/losses?


Why is this?  Well, one reason is that the defender OODA loop is simply 
larger.  If it includes extra nodes, then it takes time to travel all 
the nodes.  E.g., anti-virus has to include the OS, and PKI has to 
include the standards body [4], and a bug fix has to include the 
user-update effort.  The entire loop must then be slower, even if we 
know everyone is working at the same speed.




Why doesn't this matter in general purpose open source?  Because outside 
security, we have an absence of active attacker and an absence of real 
losses.  When Firefox blows up, the user restarts, switches browser or 
even files a bug.  Only slight losses of time & patience there.  Also, 
when an Internet security system is breached by an active attacker, the 
value that can be lost could be an entire bank account [5].  In general 
purpose software failures, there isn't an attacker that turns faster, 
and takes more of our money when he wins.


In summary, there is no disagreement between open source and general 
internet software.  But there is a clash between security and standards 
[6].  Standards slow do

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 12/03/2008 07:09 PM, Nelson B Bolyard:

Kaspar Brand wrote, On 2008-12-03 08:36 PST:


http://sni.velox.ch/httpd-2.2.x-sni.patch is working pretty well for
2.2, though (have a look at https://sni.velox.ch).


Kaspar,  Thank you for building and maintaining that web site.
It is the ONLY web site known to me that implements SNI.
I use it from time to time for testing the client-side SNI in NSS.
I appreciate your leadership in this area, and your contributions to Mozilla.



I wonder if mod_nss supports SNI the same way the patched mod_ssl 
version does. I knew about mod_gnutls did, but since there were other 
issues with it, I never went for it...


I took the opportunity to blog about SNI and (shamelessly promoting) our 
patched SNI capable packages. The post includes a test case as well: 
https://blog.startcom.org/?p=131



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Eddy Nigg wrote, On 2008-12-05 04:48:
> On 12/05/2008 09:17 AM, Nelson Bolyard:
>> Ian,
>>
>> Now, in contrast to that, I have been led to believe that Skype's:
>> - protocols, security designs and parameters are proprietary, secret, have
>> not been openly published, and thus not subjected to public scrutiny
>> - components are all proprietary.  Their clients only interoperate with their
>> servers and their other clients.  It's a closed system, as far as I know.
>> - security claims are not independently verifiable by those who have no
>> economic interest in keeping unfavorable findings secret
> 
> Nelson, you know what truly amazes me? That people like Ian actually 
> promote a closed, proprietary source and proprietary standards, 
> unaudited and secretive model of a commercial vendor who's product locks 
> in its users and who's security model is highly questionable. All this 
> in order to bash PKI, CAs and digital certificates. I wonder if this has 
> something to do with a certain CA not being included in NSS?

I think Ian has a valid and interesting perspective to consider, which
(if I may attempt to summarize) is that, to the consumer who is not very
discerning in security matters, and who takes no side in the open/closed
source religious conflict as long as the software/service that he wants
is free or dirt cheap, a turn key product that appears to "work", and
that claims to have some security (whether real or not), is more attractive
than a product that claims moral high-ground on the open/closed battle
front, and may have security that appeals to nerds, but takes more effort to
learn and use.

I don't doubt that at all.  There's a reason why people keep paying for
Windows or MacOS rather than getting Linux for free.

My main point in that message to Ian was that, like it or not, Mozilla
is very much allied with the open source movement, and the newsgroups
and mailing lists that Mozilla sponsors are intended (I believe) to be
places for the people who want to see Mozilla's software succeed, within
its self-imposed boundaries (which I listed), to congregate, communicate,
(maybe) commiserate, and try to help one another succeed with Mozilla's
software.

I think this list is NOT the place for the debate over the superiority
of open vs. closed source software.  This is the open source locker room,
not the open/closed source battle field.

Now, if the discussion can be steered to how Mozilla's crypto can succeed at
becoming as popular as Skype may be, WITHOUT it having to resort to
- closed source,
- proprietary designs (restricted intellectual property),
- being a closed system with no interoperability,
that may be worthwhile for this forum, IMO.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 12/05/2008 09:17 AM, Nelson Bolyard:

Ian,

Now, in contrast to that, I have been led to believe that Skype's:
- protocols, security designs and parameters are proprietary, secret, have
not been openly published, and thus not subjected to public scrutiny
- components are all proprietary.  Their clients only interoperate with their
servers and their other clients.  It's a closed system, as far as I know.
- security claims are not independently verifiable by those who have no
economic interest in keeping unfavorable findings secret



Nelson, you know what truly amazes me? That people like Ian actually 
promote a closed, proprietary source and proprietary standards, 
unaudited and secretive model of a commercial vendor who's product locks 
in its users and who's security model is highly questionable. All this 
in order to bash PKI, CAs and digital certificates. I wonder if this has 
something to do with a certain CA not being included in NSS?



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Ian G]

Nelson Bolyard wrote:

Ian,

Previously in this thread, you wrote:


For me, the purpose of this debate is finding out what users can expect from
Mozilla by way of security.



Thank you for taking the time to lay out your views!



The answers to that quest probably include these properties:
- open, openly specified, not secret,
- inner workings subjected to public scrutiny.
- security claims independently verifiable
- interoperability with products from other sources is desired, not avoided
- interoperability with products from other sources is based on standards
compliance - not proprietary specifications controlled solely by Mozilla



Yes, a laudable goal.  (Leaving aside Mozilla for now.)


Now, in contrast to that, I have been led to believe that Skype's:
- protocols, security designs and parameters are proprietary, secret, have
not been openly published, and thus not subjected to public scrutiny
- components are all proprietary.  Their clients only interoperate with their
servers and their other clients.  It's a closed system, as far as I know.


I think these two claims are completely correct!


- security claims are not independently verifiable by those who have no
economic interest in keeping unfavorable findings secret


In essence, your claim is approximately sustainable, notwithstanding a 
single audit, and I suggest some additional stuff below.



I suspect that part of the reason you look so favorably on Skype is
precisely that its security claims have NOT been subjected to public
scrutiny.


Not at all, that is not my mind speaking :)

Actually I find it really irritating, but I have different motives from 
you.  I would like the chance to criticise the design, especially as it 
is a new design (relatively speaking) and has incorporated a lot of the 
new learning in it.  In the crypto world, we often talk about how we 
should break others' designs before we design our own, and I follow that 
principle.


That's why I have that silly SSL page:  to criticise is to hone.  But, 
you have no idea how boring it is to criticise the older designs;  when 
one comes across the same mistakes over and over again, one has to keep 
reminding oneself how "we know so much more these days..."




I think you tend to give them the benefit of a (very large) doubt.



Well, that is relative.  Consider:  those who have taken the above 
laudable goal and decided this is the beginning and end of everything 
... have obviously found that Skype doesn't meet this goal.  Therefore, 
not having met your primary, first, up-front goal, everything else is 
nonsense.


It's not open, therefore it cannot be secure.  Right?

In contrast, I tend to look at the user interest.  And specifically, I 
tend to look at the security delivered to the user.  Although I approve 
the open source goal, I have over time come to view it as 
not-unchallengeable.


So, you -- and most here -- look at Skype and decide because it is 
closed, it cannot be secure.  I look at Skype and say, well, how much 
security does it deliver?  Objectively?  Does it confirm or deny the 
open source hypothesis?


As it turns out, Skype delivers more security than practically every 
other example out there.  Yes, I can and will argue that, even though 
you will doubt it. :)


Which leads us to a conundrum:  if this is true, then open source may 
not be the best (or only) way to deliver security.


Which, if you are religious about open source, will be very troubling. 
And, even if you are more like me, a fan about open source, it is still 
rather irritating.




In the absence of published faults in their technology, in your debates
it seems you tend to treat that technology as flawless, which gives them an
advantage that no openly specified system can ever have.



Well, nobody here has asked me about their flaws, so that's another 
assumption which I'm happy to address.


Here are their *security* flaws, as far as my view goes:  obviously, not 
open source.  So we don't know who is listening.  So we have to conduct 
some wider research.  Here's what I have found:  it is possible to fork 
off a subnet and intercept using a borked client, this was demonstrated 
by the EADS guys over a year ago.  If you pay them lots of money, 
they'll sell you an intercept kit (probably, at least, that's their 
business).  China has a borked client.  There is another minor published 
weakness, which I forget now.  The super-servers are a cause for 
concern.  The company is now owned by a US company so we can assume that 
the NSA has achieved quiet satisfaction, if not anyone else.  There is a 
view that the intel agencies of other countries in UKUSA can now breach 
Skype, and there is a view that this breach is now either leaking to 
non-UKUSA-G20 countries, and from there to police, in countries where 
police have an ability or desire to listen in, as para-intel agencies. 
However, this is all secret, and being interpolated from claims and 
counter-claims.  The evidence

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson Bolyard]

Ian,

Previously in this thread, you wrote:

> For me, the purpose of this debate is finding out what users can expect from
> Mozilla by way of security.

The answers to that quest probably include these properties:
- open, openly specified, not secret,
- inner workings subjected to public scrutiny.
- security claims independently verifiable
- interoperability with products from other sources is desired, not avoided
- interoperability with products from other sources is based on standards
compliance - not proprietary specifications controlled solely by Mozilla

Now, in contrast to that, I have been led to believe that Skype's:
- protocols, security designs and parameters are proprietary, secret, have
not been openly published, and thus not subjected to public scrutiny
- components are all proprietary.  Their clients only interoperate with their
servers and their other clients.  It's a closed system, as far as I know.
- security claims are not independently verifiable by those who have no
economic interest in keeping unfavorable findings secret

I suspect that part of the reason you look so favorably on Skype is
precisely that its security claims have NOT been subjected to public
scrutiny.  I think you tend to give them the benefit of a (very large) doubt.
In the absence of published faults in their technology, in your debates
it seems you tend to treat that technology as flawless, which gives them an
advantage that no openly specified system can ever have.

I believe you will not get Mozilla or its community members interested in
developing a solution that requires that
- all clients and all servers come from Mozilla,
- protocol specifications, source code, and other technologies be kept secret
- security claims must be taken on faith.

Consequently, I think there's little to be gained by continuing to hold
Skype up as a shining example in this list/group.  So, please don't keep
flogging us with praise for Skype or other systems that are antithetical
to the values of the open-source community.

Thanks.

/Nelson (speaking only for myself, as always)
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Kaspar Brand wrote, On 2008-12-03 08:36 PST:

> http://sni.velox.ch/httpd-2.2.x-sni.patch is working pretty well for
> 2.2, though (have a look at https://sni.velox.ch).

Kaspar,  Thank you for building and maintaining that web site.
It is the ONLY web site known to me that implements SNI.
I use it from time to time for testing the client-side SNI in NSS.
I appreciate your leadership in this area, and your contributions to Mozilla.

/Nelson Bolyard
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Michael Ströder wrote, On 2008-11-27 06:02:
> Anders Rundgren wrote:
>>  >> So what is then real problem?
>>  >> 1. The European Smart Card industry who do not want to become suppliers
>>  >> of commodities.
>>
>>  >???
>>  >Each time I talked to smartcard vendors they were keen on selling their
>>  >stuff. The more the better.
>>  
>> You mean there is a standard blank smartcard that you can buy from 
>> multiple vendors that works right-out-of-the-box in most computer 
>> systems?   Using what kind of standard personalization software?
> 
> Different vendors have different smartcards but you can use them from 
> different applications through PKCS#11 and CAPI/CSP. The software 
> quality differs.
> 
> You claimed that banks do not use PKI with smartcards for authc because 
> there's nothing available. I don't think so. The banks do not want to 
> get involved with supporting software/hardware installed at the user's 
> PC. You should look at the HBCI history.

I recently had lunch with a Swiss banking executive whose bank now
supports two different USB hardware PKI token gizmos for authentication.
As I recall, one is distributed and supported by the Swiss post office.
The bank seems quite happy to support the devices, given that the bank
is not the sole service to use it, and therefore does not bear the sole
support burden.

I have contacts in the former Soviet Union who claim that Russian banks
now routinely require PKI hardware for authentication as a condition of
online banking.

How sad that I live is a nation that is such a technological back-water. :)
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 11/26/2008 01:30 AM, Eddy Nigg:


Well, as a matter of fact, Jabber/XMPP inclusion into Thunderbird has
been a widely requested feature (see
https://bugzilla.mozilla.org/show_bug.cgi?id=385758 ) and is part of the
broader road map of Mozilla Messaging. Unfortunately it will not make it
into TB 3, but it might be in successive releases. I'm just afraid that
not much work has been done yet however...



Forgot to mention this: https://addons.mozilla.org/en-US/firefox/addon/3633

Same goes for Thunderbird: 
https://addons.mozilla.org/en-US/thunderbird/search?q=sameplace&cat=all



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 11/26/2008 01:11 AM, Frank Hecker:

I agree with Ian here: The focus of Mozilla Messaging and of Thunderbird
should be on end users in general, not Mozilla community members
specifically. And the interest of typical end users would be on
connecting with their friends, who are not in general on IRC but on AIM
and other "consumer" IM networks. Whether it makes sense to include chat
in Thunderbird is an open question, but certainly if it were to be done
then it should be done as a general-purpose IM capability and not just
as an IRC client.



Well, as a matter of fact, Jabber/XMPP inclusion into Thunderbird has 
been a widely requested feature (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=385758 ) and is part of the 
broader road map of Mozilla Messaging. Unfortunately it will not make it 
into TB 3, but it might be in successive releases. I'm just afraid that 
not much work has been done yet however...



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Frank Hecker]

Nelson B Bolyard wrote:

Are you aware of chatzilla?  It's been around for a long time.
Protocols and architecture are defined in RFCs 2810-2813. Chatzilla
interoperates with many other chat clients that follow those RFCs.


For the record, there's also InstantBird  which 
appears to be a multiprotocol IM client using the Mozilla code base. 
(I'm guessing, but have not confirmed, that it's a XULRunner app.)



Mozilla runs an Internet Relay Chat server for use by chatzilla users.
It's widely and heavily used by mozilla developers and other community
members.  I think you'd have a difficult time convincing mozilla they need a
SECOND chat client/service.


I agree with Ian here: The focus of Mozilla Messaging and of Thunderbird 
should be on end users in general, not Mozilla community members 
specifically. And the interest of typical end users would be on 
connecting with their friends, who are not in general on IRC but on AIM 
and other "consumer" IM networks. Whether it makes sense to include chat 
in Thunderbird is an open question, but certainly if it were to be done 
then it should be done as a general-purpose IM capability and not just 
as an IRC client.


Frank


--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Ian G]

Nelson B Bolyard wrote:

Ian G wrote, On 2008-11-22 07:39:

So an obvious thing is to add chat to Tbird.  How to do this?  


Are you aware of chatzilla?  It's been around for a long time.
Protocols and architecture are defined in RFCs 2810-2813. Chatzilla
interoperates with many other chat clients that follow those RFCs.



No, I wasn't aware.  I'm guessing chatzilla is an IRC client only?  So 
it needs a central server, and it is only encrypted client-server?  (To 
be frank, I don't use IRC that much because it doesn't appeal to a wide 
base of my communicators.  I'm guessing that is because the old 
client-server model is less scalable, but that's a long debate.)




Mozilla runs an Internet Relay Chat server for use by chatzilla users.
It's widely and heavily used by mozilla developers and other community
members.  I think you'd have a difficult time convincing mozilla they need a
SECOND chat client/service.



I'm not sure about those statements.  I thought Mozilla objectives were 
to support end-users with what they wanted, not developers?  Are you 
suggesting that the Mozilla developers think users want IRC?  I've never 
seen that, this would be new to me.  IRC seems to be a developer-heavy 
community.


Also, your proposal seems to suggest that you place "standards chat" 
above "secure chat".  It doesn't take much elegance of argumentation to 
show that these are not really the same thing, nor can they easily 
align.  E.g., standards bodies haven't updated their security model in a 
decade or more, but the attackers have (updated their respective 
models).  (The users, too.)


This dilemma is most easily shown in the form of Col. Boyd's OODA loop

http://en.wikipedia.org/wiki/OODA_Loop



iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Ian G wrote, On 2008-11-22 07:39:

> So an obvious thing is to add chat to Tbird.  How to do this?  

Are you aware of chatzilla?  It's been around for a long time.
Protocols and architecture are defined in RFCs 2810-2813. Chatzilla
interoperates with many other chat clients that follow those RFCs.

Mozilla runs an Internet Relay Chat server for use by chatzilla users.
It's widely and heavily used by mozilla developers and other community
members.  I think you'd have a difficult time convincing mozilla they need a
SECOND chat client/service.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 11/22/2008 05:39 PM, Ian G:

I see this as an interesting question. There are pros and cons. First
con; why would we want to do that? Just use Skype. Or, Nelson talked
about AIM having some form of crypto. Also Jabber has something.



Jabber doesn't just have "something", but the XMPP Foundation runs an 
intermediate CA under the auspices and at the infrastructure of 
StartCom. Currently it only includes client-to-server and 
server-to-server encryption, but they are on the way to implement 
client-to-client encryption as well.
All server certificates are (obviously) domain name control validated 
and the keys are under the control of the server operator - as this is a 
decentralized network. Similarly client certificates will be validated 
to be under the control of the XMPP address (looks like an email 
address) and keys under the control of the user. Small but important 
difference I thought worth mentioning.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Ian G]

Anders Rundgren wrote:

The following is related to the S/MIME discussions.

...


If we (security experts) want to create anything that could match closed 
networks such as Skype, having 100M+ users enjoying full 
end-2-end-security, I think we need to be a bit pragmatic and not hoping 
that users should be extremely interested in certificates, or that the 
UN should provide us with a universal root certificate.



I see this as an interesting question.  There are pros and cons.  First 
con;  why would we want to do that?  Just use Skype.  Or, Nelson talked 
about AIM having some form of crypto.  Also Jabber has something.


In contrast to that, one of the things that Mozilla Messaging should be 
looking at is exactly that.  The comparisons between email and chat are 
strong if not perfect, and while old things like email aren't likely to 
die any time soon (telegrams just got shutdown last year!), all new 
interesting work is being done in the peer2peer domain.


So an obvious thing is to add chat to Tbird.  How to do this?  An 
interesting question.  However, this is a business-level requirement, 
not a user-level or tech-level comment.


...
Each domain (host) have a "pseudo-CA" using a commercial-grade SSL 
certificate as a CA certificate.  Certificates created by such a CA 
should have a specific DN format (in order to be valid), where the 
host-name of course must be a core component (you can only certify 
things in your own domain).



The problem I see here is that you are (all) starting from a tech pov. 
Bottom up.  What's the point of that?  Granted, it will work in theory, 
but the market has shown that successful things start from a top-down, 
market focus, they win out in the end.


So, I would suggest defining what the chat system is that users of say 
Tbird would want.  (Or Firefox.)  Then, once you've figured that out, 
start meeting those requirements.


Alternatively, if you do want to take a tool -- "I have a cert" -- and 
wish to thrust it down people's throats, then you are reducing your 
chances to essentially lottery proportions.  You have to be right about 
things you aren't looking at and don't know exist, and users have no 
difficulty in ditching tools that are too cumbersome.


Based on such a trust infrastructure, an on-line-based secure messaging 
system should be able to achieve Skype-level scalability while still 
being fully distributed.  I haven't really gotten down to the 
nitty-gritty with the messaging itself, because a system like 
this obviously requires a bunch of other hot-shots as well :-)



So from this, I gather you want:  scalability + distribution.  Do you 
want no center(s) at all?



Enrolment issues?  Skype does this without the user having to know what 
a certificate is.



I sense an easy enrolment process.  OK, I agree with that.

Applications include all kinds of interactive communication with mobile 
phones as a really interesting target unless it gets outlawed.



Mobile phones -> strange messaging formats like SMS.  Avoid Internet 
assumptions like TCP/IP, make it strictly messaging.  Well, ok, any chat 
system should have done that anyway.  But this is getting too deep.



Do you want file-sharing?  Do you want video?  These are both common 
with modern day chat, and they strain the architecture depending on what 
choices you made.  Do you want integration into other things?  E.g., if 
you ended up piggybacking on some p2p networks, you might end up with 
file-sharing and backup possibilities.


Do you want to have:

   no originated authentication (leave it to the users)
   an upgrade path to third party auth (aka CAs)
   third party auth form the start?

It depends on your user base I would guess.  If we are talking ordinary 
mom & pop, they are happy with whatever works immediately, so the first. 
 If we are talking corporates, sometimes they want authentication from 
a third party, and sometimes they want it from a first party (themselves).


just some thoughts!

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Eddy Nigg]

On 11/22/2008 12:12 PM, Anders Rundgren:

Enrolment issues? Skype does this without the user having to know what a
certificate is.


LOL! And nobody knows what those keys are, nor if it's authentic and who 
else can listen and decrypt. Who controls what exactly? Does the user 
has control over his key(s)? I don'tdo you?


Skype's encryption is security theater at best! :-) Did Skype ever 
disclose what it does, what their infrastructure looks like, what kind 
of encryption is in force and most important, why the user doesn't 
control his supposedly own private key(s)?


I suggest to treat Skype's encryption or any similar scheme as plain text.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

[Nelson B Bolyard]

Anders Rundgren wrote, On 2008-11-22 02:12:
> The following is related to the S/MIME discussions.

Anders, here are your choices:
You may either have
a) encryption using authenticated keys or
b) encryption using unauthenticated keys.

Certificates are used for authenticated encryption.  If you don't want
authenticated encryption, you don't use certificates.  It's that simple.

The idea of producing phony certificates, so called "self signed"
certificates, or certs from "pseudo CAs" is an attempt to force
unauthenticated keys into a system whose ENTIRE and SOLE purpose is to
authenticate keys, and avoid the use of unauthenticated keys.

If you want to design an application protocol that uses purely
unauthenticated keys (and it appears that you do), then design it to not
use certificates at all, but to simply use unauthenticated keys.  Yes,
there are application protocols out there that do that.  They're vulnerable
to Man in the middle attacks, but that's the price you pay for choosing to
use unauthenticated keys.  SSL supports the use of unauthenticated "bare"
keys, without any certs.  If that's what you want, go for it.

But first consider the capabilities of authenticated keys carefully.
There's absolutely NOTHING that says that in every application protocol,
key authentication must be tied to DNS names.  The decision to bind keys
to DNS names is a decision made by the designers of the https application
protocol, and it fits their model, where contact is initiated based on
a DNS name.  But for other applications, where contact is NOT initiated
based on DNS name, binding of keys to DNS names in meaningless.  In
other applications, which identify end points with identities in other
spaces besides DNS names, authentication of keys requires binding them
to what ever identities are used by that application.

That's why authenticated email encryption protocols don't bind to
DNS names, they bind to mailbox names (email addresses).

There's a certain world-wide instant messaging service that offers file
transfer capabilities.  It has the ability to offer authenticated and
encrypted IM and authenticated and encrypted file transfer.  It uses
S/MIME for the IM and SSL for the file transfer.  Every one of its clients
offers both. It doesn't require that certs have DNS names in them, because
users identify each other through names that  are not DNS names and are not
mailbox addresses.

The certificates that the users use to authenticate each other for the
S/MIME based IM service are the same certificates used for the SSL file
transfer.  The reasoning is that when you've determined the certificate
of the party to whom you're IMing, and you want to do file transfer,
you know that you want to transfer your files to the same party to
whom you've been IMing.  So, the very same cert used to identify the
party for IM is the cert used to identify that party's SSL server.

When the SSL client connects to the peer's SSL server for file transfer,
it checks to see that the cert is the same cert used in the IM.  It does
not check for a DNS name or an email address.  It checks that the cert is
the very same cert.  This is SSL peer-to-peer.

In this system, there are servers that act as relays between the IM
endpoints, and also between the SSL endpoints (if necessary desired).
Those servers don't decrypt anything (they can't).  They just pass the
traffic through from one end to the other.  All encryption is end to
end.  If one peer is able to receive incoming connections (many are not)
then one client can connect directly to the other over the internet,
bypassing the IM servers for file transfer, but if the receiving party
cannot receive incoming connections, it connects to the IM servers,
and the file transfer takes place through the IM server.  It's still
end to end encryption.  The IM servers don't decrypt anything because
a) they don't have the keys, and b) it would be way too slow anyway.

The clients all require certs from real CAs, Self-signed certs are not
an option, but there are no predefined requirements on what cert names
must contain.  The UI clearly presents the peer's cert name to the user
and the user must decide if that is a name with whom he wants to IM (or file
transfer) or not.

This system has been around for years.  The clients all use NSS for all
the SMIME IM messages and for all the SSL file transfers.  Works with
any cert issued by any of the CAs in Mozilla's list.  I use it every day.
Chances are good that you do too.  It's the worlds largest IM network.
If you have your own cert, such as (say) an email cert, and would like
to try secure IM over AOL's instant messenger network, write to me off
list.

Please don't waste any more time talking about "pseudo CAs".  That's
pointless.  If your application wants unauthenticated keys, then use
them and don't bother with certs.  My long standing objection to
self signed certs is not an objection to unauthenticated encryption
(although I have no use for unauthenticat