On Thu, Feb 16, 2012 at 3:11 PM, Stephen Kent wrote:
yes, the Federal bridge CA is a bad idea, as implemented.
Federal Bridge CA is a much better idea than what we have now.
Currently, we have large numbers of absolutely-trusted roots with no controls
on them other than ultimate distrust.
Credential equivalence is not for every application. In particular
there are cases where you want a user to have exactly one physical
credential and that is a part of the security scheme.
But I still think that the rule of 'private keys never move outside
the device once they are in' is a good one
At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote:
On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent wrote:
So, I don't agree that the distinction between the user and a machine
operated by a user is really significant, in the end. (Yes, I am ware of
the many security problems that arise because the us
At 6:12 PM -0800 2/10/12, Kyle Hamilton wrote:
On Thu, Feb 9, 2012 at 3:05 PM, Stephen Kent wrote:
At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
>...and I do agree with you in that whichever entity making such
assertion (X.509, SAML, JWT·) has to be authoritative for the identity
assert
On 11 Feb 2012, at 03:12 , Kyle Hamilton wrote:
> What are these 'identities' that need to be asserted with authoritative
> backing? I hope you're not just talking about state identities, even though
> state identity is an important part of it. The current crop of authoritative
> information
On Thu, Feb 9, 2012 at 3:05 PM, Stephen Kent wrote:
At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
>...and I do agree with you in that whichever entity making such
assertion (X.509, SAML, JWTŠ) has to be authoritative for the identity
asserted if you want it to be usable.
I think we are
On 10 Feb 2012, at 01:22 , Stephen Kent wrote:
>> Or should we just be trusting a certification authority to do what it
>> says it will do in its CPS, perhaps just confirming that an email address
>> asserted in a certificate request is indeed accessible by the party that's
>> requesting a cert wi
On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent wrote:
So, I don't agree that the distinction between the user and a machine
operated by a user is really significant, in the end. (Yes, I am ware of
the many security problems that arise because the user doesn't really know
what the code is doing,
At 3:14 PM -0800 2/9/12, Joe St Sauver wrote:
Steve commented:
#I think we are in agreement. CAs that are not authoritative for asserted
#identities are as bad as federated trust entities with similar properties.
I tend to be a concrete thinker, so I hope you'll indulge me for a minute
in a con
Steve commented:
#I think we are in agreement. CAs that are not authoritative for asserted
#identities are as bad as federated trust entities with similar properties.
I tend to be a concrete thinker, so I hope you'll indulge me for a minute
in a concrete exercise related to your assertion.
-- As
At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
On 8 Feb 2012, at 20:30 , Stephen Kent wrote:
>...and I do agree with you in that whichever
entity making such assertion (X.509, SAML, JWT)
has to be authoritative for the identity
asserted if you want it to be usable.
I think we are in a
On 8 Feb 2012, at 20:30 , Stephen Kent wrote:
> I think the real issue, which you ay have overlooked in my comments
> above, is the notion that the best candidate for a CA is an entity
> that is authoritative for the identity asserted in the cert.
I cannot agree more with you in that statement. A
At 8:22 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
Alice has three mobile phones and six laptops.
Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices tha
At 2:40 PM -0800 2/8/12, Bill Frantz wrote:
On 2/7/12 at 11:55, k...@bbn.com (Stephen Kent) wrote:
Keys are not really great identifiers; they change,
Keys don't change. People or programs may wish to change the keys
they are using, but keys themselves are constant.
Touche! You're right, b
On 02/08/2012 08:22 PM, Phillip Hallam-Baker wrote:
> Worse, Alice has to repeat the process once a year.
Why would Alice have to repeat the process once a year? Are you
suggesting she has to replace her decryption key every year? Does this
have to do with the "repeat customer" lock-in model op
Umm, no, I was showing why end-to-end works for authentication (no
need for the same key in every device) but not for S/MIME.
The way to make S/MIME practical for Alice would be to do as you
suggest and have Alice's private key out there in the cloud somewhere
and have the server where it is kept
On Wed, Feb 8, 2012 at 5:22 PM, Phillip Hallam-Baker wrote:
> Alice has three mobile phones and six laptops.
...
> Trying to make S/MIME email work in that scenario is futile. The
> sender only tracks one private key for Alice. So Alice has to export
> her private key to all her S/MIME clients. No
Alice has three mobile phones and six laptops.
Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices that
might authenticate Alice.
The same model can even be
On 2/7/12 at 11:55, k...@bbn.com (Stephen Kent) wrote:
Keys are not really great identifiers; they change,
Keys don't change. People or programs may wish to change the
keys they are using, but keys themselves are constant.
they are not human meaningful (and thus there has to be another
la
At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
But authentication works in that scenario because the protocols can
allow each user to have as many keys as they need. The key is not
shared across devices, the protocols allow for multiple cards per
end user
Sorry, I don't understand you
But authentication works in that scenario because the protocols can allow each
user to have as many keys as they need. The key is not shared across devices,
the protocols allow for multiple cards per end user
Sent from my iPad
On Feb 8, 2012, at 12:06, Stephen Kent wrote:
> At 6:52 PM -050
At 7:56 PM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
On 8 Feb 2012, at 17:36 , Stephen Kent wrote:
In the physical world we recognize that certain
entities are authoritative for identifying people
or orgs. These entities issue credentials to
people and orgs, and these credentials are
accepted
On 8 Feb 2012, at 17:36 , Stephen Kent wrote:
> In the physical world we recognize that certain
> entities are authoritative for identifying people
> or orgs. These entities issue credentials to
> people and orgs, and these credentials are
> accepted for identification and/or authorization
> purpo
At 6:52 PM -0500 2/7/12, Phillip Hallam-Baker wrote:
...
The reason I no longer believe in end-to-end solutions is that the
endpoint for a public key is always a machine and the desired endpoint
is a person.
yes, the machine is the endpoint, but machines are always in the loop
for the sorts
At 8:52 AM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
On 7 Feb 2012, at 23:25 , Stephen Kent wrote:
federated authentication systems using certs generally seem to be
motivated because folks can make cross-certification work properly.
other federated auth systems seem to be based on having one or
Yes, STARTTLS is broken in precisely the way I pointed out.
BT!
Now imagine that we have a mechanism that allows the mail server to
state 'TLS is always offered'. The problem can be solved.
On Wed, Feb 8, 2012 at 1:12 AM, Martin Rex wrote:
> Phillip Hallam-Baker wrote:
>>
>> In practice m
On 7 Feb 2012, at 23:25 , Stephen Kent wrote:
> federated authentication systems using certs generally seem to be
> motivated because folks can make cross-certification work properly.
> other federated auth systems seem to be based on having one org trust
> another to assert and identity for a use
Phillip Hallam-Baker wrote:
>
> In practice most email that is sent encrypted is encrypted using TLS.
> If we had an infrastructure that allowed mail servers to know that
> their corresponding servers required use of TLS, the man in the middle
> downgrade attack could be defeated.
I'm sorry Phil
3:53 PM
To: Stephen Kent
Cc: Joe St Sauver; therightkey@ietf.org
Subject: Re: [therightkey] Will the real RPF please stand up?
On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent wrote:
> I think there are multiple reasons why client certs have not taken
> off, based on 20+ years of experience
On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent wrote:
> I think there are multiple reasons why client certs have not taken off,
> based on 20+ years of experience in the area. We provided a client cert
> system for a financial firm in the early 90's. It was easy to use,
> bootstrapped from the pass
At 12:05 PM -0800 2/7/12, Joe St Sauver wrote:
...
This is actually a fascinating question, and one where the answer you
get for "Why don't people deploy client certs?" varies from person to
person. I attempt to capture a little of that in a talk I did a week
or so ago at Internet2/ESNet Joint T
Kent commented on Kyle Hamilton's remarks...
#>Using the same key across multiple places may not seem to be
#>something which has turned out to be a problem in practice, in that
#>TLS sites use the same keys across every client. However, it's a
#>major reason why client-side authentication isn
At 9:25 PM -0800 2/6/12, Kyle Hamilton wrote:
...
And keys are just labels. I'm enough of an SPKI revanchist
to say that keys are just names or labels. You can no more
determine trustworthiness from a mere name than you can
tell a book by its cover. To talk about trust, let alone
trust*worththi
On Wed, Feb 1, 2012 at 12:28 AM, Jon Callas wrote:
You might trust your mother, but do you trust your mother to set up
your VPN?
Finally, someone talking some sense.
And keys are just labels. I'm enough of an SPKI revanchist
to say that keys are just names or labels. You can no more
determ
As security engineers, our role is to (a) reduce the number of
entities we trust; (b) reduce the extent to which we trust the
remaining trusted entities; and (c) determine the trustworthiness of
trusted entities.
A system with voting like Convergence (depending on configuration) has
the nice pro
On 02/01/2012 08:20 PM, Paul Lambert wrote:
> I may be looking at the back end of the elephant, but terms like "pinning"
> and such seem wrong. With a "key centric" view, the DNS address or other
> information are attributes that can be assigned to a key versus a name
> centric perspective that
On Feb 1, 2012, at 10:43 AM, Phillip Hallam-Baker wrote:
> That is a good point, and one that threatens to create a whole new chapter.
>
>
> First, replying to Jon, what we are managing is not risk itself but
> the cost imposed by the possibility of unintended outcomes. If the guy
> is jumping
Hi Martin,
I think we may all be looking at this elephant from several different angles.
We are having to write essays on our perspective to describe some broad
generalizations that we are making.
>> >> One of the better definitions I've heard. I would question whether
>> >(c) is even in scop
AM, Thomas Hardjono wrote:
>
>
>> -Original Message-
>> From: therightkey-boun...@ietf.org [mailto:therightkey-
>> boun...@ietf.org] On Behalf Of Jon Callas
>> Sent: Wednesday, February 01, 2012 3:28 AM
>> To: therightkey@ietf.org
>> Subject: Re: [therigh
On Feb 1, 2012, at 5:31 AM, Kyle Hamilton wrote:
> * PGP - S/MIME Signed by an unverified key: 02/01/2012 at 05:31:54 AM
>
> I do see a problem with defining the term 'trustworthy', because it's
> reinventing the wheel. It's already been defined in law as "fiduciary". This
> is the kind of re
> -Original Message-
> From: therightkey-boun...@ietf.org [mailto:therightkey-
> boun...@ietf.org] On Behalf Of Jon Callas
> Sent: Wednesday, February 01, 2012 3:28 AM
> To: therightkey@ietf.org
> Subject: Re: [therightkey] Will the real RPF please stand up?
>
>
I do see a problem with defining the term 'trustworthy', because it's reinventing the
wheel. It's already been defined in law as "fiduciary". This is the kind of
relationship you have with your doctor, your lawyer, your accountant, your bank, your
insurance company, even your cemetary, every o
On Jan 31, 2012, at 7:35 PM, Phillip Hallam-Baker wrote:
> I don't see the problem with defining the term 'trustworthy'
>
> Risk = Cost imposed by likelihood of probable loss.
> Trust = Confidence with which risk is assessed.
> Trusted = An entity that is relied on to mitigate risk (whether
> tr
I don't see the problem with defining the term 'trustworthy'
Risk = Cost imposed by likelihood of probable loss.
Trust = Confidence with which risk is assessed.
Trusted = An entity that is relied on to mitigate risk (whether
trustworthy or not).
Trustworthy = An entity that meets rational criteria
On Tue, 2012-01-31 at 17:14 -0800, Paul Lambert wrote:
> >-Original Message-
> >From: therightkey-boun...@ietf.org [mailto:therightkey-boun...@ietf.org]
> >On Behalf Of Jon Callas
> ...
> >
> >On Jan 26, 2012, at 2:55 PM, Richard L. Barnes wrote:
> >
> > As security engineers, our role
>-Original Message-
>From: therightkey-boun...@ietf.org [mailto:therightkey-boun...@ietf.org]
>On Behalf Of Jon Callas
...
>
>On Jan 26, 2012, at 2:55 PM, Richard L. Barnes wrote:
>
> As security engineers, our role is to (a) reduce the number of
> entities we trust; (b) reduce the
On Jan 26, 2012, at 2:55 PM, Richard L. Barnes wrote:
As security engineers, our role is to (a) reduce the number of
entities we trust; (b) reduce the extent to which we trust the
remaining trusted entities; and (c) determine the trustworthiness of
trusted entities.
>>>
>>> R
On Fri, Jan 27, 2012 at 5:21 AM, Ralph Holz wrote:
> Hi,
>
Separation of duties - increases the number of trusted parties
No sequential access - increases the number of trusted parties
No lone zone - increases the number of trusted parties.
Those are all NSA/GCHQ doctrines
Hi,
>>> Separation of duties - increases the number of trusted parties
>>> No sequential access - increases the number of trusted parties
>>> No lone zone - increases the number of trusted parties.
>>>
>>> Those are all NSA/GCHQ doctrines. I am pretty sure that they
>>> understand security enginee
That reminds me of the Media Lab idea that binary choices are bad and
things should be specified as a range.
What we are doing here is attempting to reduce risk and risk is a
continuous variable.
In the simplest model of risk we merely consider if there is a non
negligible probability of a loss.
On Thu, 2012-01-26 at 14:10 -0800, Chris Palmer wrote:
> On Thu, Jan 26, 2012 at 1:43 PM, David Conrad wrote:
>
> > I'm curious: where do you draw the line? Should routing system security be
> > included? Email security (since many transactions relating to DNS zone
> > administration occur vi
The way I was taught to do security analysis is you start off with
everything on the table and look to identify all possible sources of
risk. You do that by identifying assets, the risks against those
assets etc. etc. It is an iterative process and it is frequently
useful to work in both directions
David Conrad wrote:
>
> On Jan 26, 2012, at 1:52 PM, Martin Rex wrote:
> >> Security that looks at 'all possible sources of error' seems to me
> >> to be a halting state problem
>
> > Drawing a line amounts to sticking your head in the sand.
>
> Or a realization that it isn't realistic to try to
On Thu, Jan 26, 2012 at 6:15 PM, Ralph Holz wrote:
> Hi,
>
>> Let us consider a Tier 6 security regime applied to management of a CA:
>>
>> Separation of duties - increases the number of trusted parties
>> No sequential access - increases the number of trusted parties
>> No lone zone - increases t
On Jan 26, 2012, at 1:52 PM, Martin Rex wrote:
>> Security that looks at 'all possible sources of error' seems to me
>> to be a halting state problem
> Drawing a line amounts to sticking your head in the sand.
Or a realization that it isn't realistic to try to solve "all possible sources
of error
Hi,
> I prefer trying to help people manage risk. People have assets that
> they would like to protect. What matters to them is
>
> 1) The cost of protecting those assets (financial and non-financial)
> 2) The value of those assets (financial, human, etc.) 3) The
> reduction in risk that is ach
In other words, they mitigate risk.
If we talk in terms of risk and risk alone as I proposed we can put
numbers on things and use that as a basis for an objective comparison
of the schemes.
You have three separate degrees of freedom and no principle to compare
them by so putting numbers on your s
Those are all (b).
On Jan 26, 2012, at 6:03 PM, Phillip Hallam-Baker wrote:
> It is nonsense.
>
> Let us consider a Tier 6 security regime applied to management of a CA:
>
> Separation of duties - increases the number of trusted parties
> No sequential access - increases the number of trusted
Hi,
> Let us consider a Tier 6 security regime applied to management of a CA:
>
> Separation of duties - increases the number of trusted parties
> No sequential access - increases the number of trusted parties
> No lone zone - increases the number of trusted parties.
>
> Those are all NSA/GCHQ d
On Thu, Jan 26, 2012 at 3:03 PM, Phillip Hallam-Baker wrote:
> Separation of duties - increases the number of trusted parties
> No sequential access - increases the number of trusted parties
> No lone zone - increases the number of trusted parties.
But they can reduce the extent to which you mus
It is nonsense.
Let us consider a Tier 6 security regime applied to management of a CA:
Separation of duties - increases the number of trusted parties
No sequential access - increases the number of trusted parties
No lone zone - increases the number of trusted parties.
Those are all NSA/GCHQ doc
>>> As security engineers, our role is to (a) reduce the number of
>>> entities we trust; (b) reduce the extent to which we trust the
>>> remaining trusted entities; and (c) determine the trustworthiness of
>>> trusted entities.
>>
>> Really?
>
> Yep.
+1
One of the better definitions I've hea
Richard L. Barnes wrote:
>
> >>> If a system is going to be robust in practice it has to take account
> >>> of all possible sources of error including administrative incompetence
> >>> and user error.
> >>
> >> I'm curious: where do you draw the line? Should routing system security
> >> be inclu
On Thu, Jan 26, 2012 at 2:21 PM, Phillip Hallam-Baker wrote:
>> As security engineers, our role is to (a) reduce the number of
>> entities we trust; (b) reduce the extent to which we trust the
>> remaining trusted entities; and (c) determine the trustworthiness of
>> trusted entities.
>
> Really?
On Thu, Jan 26, 2012 at 5:10 PM, Chris Palmer wrote:
> On Thu, Jan 26, 2012 at 1:43 PM, David Conrad wrote:
>
>> I'm curious: where do you draw the line? Should routing system security be
>> included? Email security (since many transactions relating to DNS zone
>> administration occur via ema
As I said in the original post, look at this problem and then ask
yourselves how Perspectives, Convergence, SK and CT might help solve
it.
I can see the potential for leverage in all four schemes since they
all provide a means of persisting information over time.
On Thu, Jan 26, 2012 at 5:02 PM,
On Thu, Jan 26, 2012 at 1:43 PM, David Conrad wrote:
> I'm curious: where do you draw the line? Should routing system security be
> included? Email security (since many transactions relating to DNS zone
> administration occur via email)? Telephone? Etc.
>
> Security that looks at 'all possibl
On Thu, Jan 26, 2012 at 04:34:07PM -0500, Phillip Hallam-Baker wrote:
> Getting defensive about problems is not going to solve them.
I'd like to know what you thought to be defensive in what I said. I
was merely trying to point out that we need to make distinctions about
pieces of the system if
Of course routing security is considered.
The reason that you want TLS in the first place is precisely the fact
that routing can be compromised (ranging from WiFi evil twin up to BGP
attack).
Security has to look at all sources of error but that does not mean it
has to eliminate them. Security i
>>> If a system is going to be robust in practice it has to take account
>>> of all possible sources of error including administrative incompetence
>>> and user error.
>>
>> I'm curious: where do you draw the line? Should routing system security
>> be included? Email security (since many transac
David Conrad wrote:
>
> Phillip Hallam-Baker wrote:
> >
> > If a system is going to be robust in practice it has to take account
> > of all possible sources of error including administrative incompetence
> > and user error.
>
> I'm curious: where do you draw the line? Should routing system secur
On Jan 26, 2012, at 1:34 PM, Phillip Hallam-Baker wrote:
> If a system is going to be robust in practice it has to take account
> of all possible sources of error including administrative incompetence
> and user error.
I'm curious: where do you draw the line? Should routing system security be
in
>From a security point of view it is the security of the system that
matters, not the security of the individual components.
The S in DNS stands for System.
If a system is going to be robust in practice it has to take account
of all possible sources of error including administrative incompetence
Maybe to you, but not to me. If we are going to do any good we have to
deal with all the problems and not just a few cherry picked problems
that we think should be the ones people are worried about.
As I pointed out, there is actually quite a bit that technology can do here.
This is a real proble
On Thu, Jan 26, 2012 at 03:06:52PM -0500, Daniel Kahn Gillmor wrote:
>
> DNS is certainly not a shining beacon when it comes to resistance to
> fraud or coercion. Let's not make it a single point of failure.
I think it would be really nice if we would make some distinctions
among different phæno
Thanks to Phillip for raising this point.
On 01/26/2012 02:35 PM, Richard L. Barnes wrote:
> Illegitimate transfers are out of scope. From the point of view of the DNS,
> an illegitimate transfer is indistinguishable from a legitimate transfer.
eh? The whole point of this discussion, as i unde
Illegitimate transfers are out of scope. From the point of view of the DNS, an
illegitimate transfer is indistinguishable from a legitimate transfer.
The only thing technology could do for this case is allow the web site to tell
customers "I'm not planning to change anything in the next N days"
This is a site I have been using for over a year now.
How would I as a regular Internet user be expected to work out which
site is the real one? This could be site napping or it could be
phishing fraud.
I tend to suspect that the email is telling the truth, but it is also
possible that it is a p
78 matches
Mail list logo
