On Wed, Feb 8, 2012 at 9:35 PM, Nico Williams wrote:
E-mail is not an online protocol between two MUAs. When you send an
e-mail your MUA is not talking directly to the recipient's MUA, and
there are no automated replies except for vacation replies.
That last assertion is demonstrably false.
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.
On Thu, Feb 9, 2012 at 5:16 AM, Phillip Hallam-Baker wrote:
So now we see why security policy driven by MUA published security
policy is going to fail: there is no consistency in the MUA loop. I
read mail on four separate devices. They have no way to communicate
between themselves to negotiate
. We should consider what our own customers need
from us, not merely what we think they need.
-Kyle H
So the thing that saved DKIM policy statements was the fact that they
are only interpreted by services that are actually very experienced in
handling bad data and in fact data that people are int
On Tue, Feb 14, 2012 at 7:04 PM, Paul Lambert wrote:
I notice you're still attaching a root certificate of unknown quality as part
of your signature. Since it is different than my current class 2 root for the
same named authority it may or may not be valid. If I accept your certificate
a
On Tue, Feb 14, 2012 at 2:55 PM, Martin Rex wrote:
We can continue to outlaw it, in which case it will continue to exist
outside of our sight.
There are two solutions for this type of "usage".
- Provide terminal servers that you monitor, to which your users have
to dial-in when they want t
On Tue, Feb 14, 2012 at 4:14 PM, Stephen Farrell
wrote:
So we don't have a moderator/chair for this list for now
so I'll have to do for the moment...
On 02/14/2012 11:54 PM, Kyle Hamilton wrote:
Your prejudices and preconceptions are, indeed, the root cause of the
problem
On Mon, Feb 13, 2012 at 4:06 PM, Paul Lambert wrote:
Kyle,
It's ironic that you're email includes a root certificate
for "Startcom Class 2" that is not the same as the one
currently in my browser.
It's ironic that it's not a root, it's an intermediate that chains from
Mozilla's Built-In Ob
over TCP/IP on the network.
Closest you get to that kind of thing is voice telecoms where the crypto is
hop-by-hop and most likely broken by design ciphers etc but there is no SSL
mitm of 3g/4g gsm-data etc at least in western countries, nor even
advertised/admitted anywhere else.
Did you have so
On Mon, Feb 13, 2012 at 3:16 PM, Chris Palmer wrote:
On Mon, Feb 13, 2012 at 3:08 PM, Kyle Hamilton wrote:
We can continue to outlaw it, in which case it will continue to exist
outside of our sight. We can continue to do the things we've tried to do
before, to break what currently e
On Mon, Feb 13, 2012 at 11:21 AM, Martin Rex wrote:
Phillip Hallam-Baker wrote:
What I find wrong with the MITM proxies is that they offer a
completely transparent mechanism. The user is not notified that they
are being logged. I think that is a broken approach because the whole
point of acc
On Mon, Feb 13, 2012 at 8:36 AM, Martin Rex wrote:
The fact that there are products (client-side HTTPS proxies that
perform MITM and inspect content) actively sold and used,
which are vitally dependent on being able to exploit weaknesses
of the existing TLS X.509 PKI security&trust model, is a
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 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,
On Thu, Feb 9, 2012 at 7:49 AM, Phillip Hallam-Baker wrote:
I agree on the problem of Web middleboxen being a problem.
What I really dislike about the BlueCoat solution is that it is
transparent. Which is of course why enterprises like them. They can
just deploy and forget. The fact that the
Once upon a time in the IETF, there was a mandatory-to-implement cipher. This
cipher was the best-selected at the time, using cutting-edge technologies.
Time changed. The new mandatory-to-implement cipher came along.
Why haven't we ever considered that maybe S/MIME doesn't have to be fully
a
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
On Fri, Jan 27, 2012 at 1:26 PM, Daniel Kahn Gillmor
wrote:
On 01/27/2012 04:02 PM, Kyle Hamilton wrote:
Why is everything so single-point-of-failure in the Security working
area? Does it really have to be?
You seem to be suggesting that we should be considering redundant,
corroborative
On Fri, Jan 27, 2012 at 8:10 PM, Phillip Hallam-Baker wrote:
I think we should focus on identifying problems at this stage.
I agree.
1) We need to figure out what we're really trying to do. I think it's an
attempt to improve the detection rate of impersonation fraud, in an attempt to
r
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
All,
Why are we focusing on 'the' anything?
Key pinning and CA pinning don't work with only One True Key. The only usable
way to do that kind of thing is to present multiple options. As certificate
chains expire or are discovered to be revoked, those keys would be removed from
the list of a
21 matches
Mail list logo
