Phillip Hallam-Baker wrote:
>
> David P. Kemp wrote:
> >
> > For the DNS/PKI case, if A is an IP address for a dnsname and B is a
> > public key for a dnsname, then it is necessary to attack the sources of
> > A and B in order to successfully spoof a named server. If A and B come
> > from the sam
On Fri, Oct 01, 2010 at 11:29:35AM -0400, Phillip Hallam-Baker wrote:
> What I object to is the approach being taken which is to use DNSSEC to
> replace PKIX certificate validation entirely.
>
> Now the proponents are trying to downplay this by saying that 'all' they are
> doing is to tell people
At 2:30 PM -0400 10/4/10, Michael StJohns wrote:
Hi -
DNSSEC seems to be picking on PKIX and vice versa - maybe the right
answer is both?
I don't see the proposed work as a war between X.509 certs and signed
DNS records. I think that they are potentially complementary security
mechanisms.
On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote:
Clearly if you have two controls, A and B and BOTH must be compromised,
the system is less likely to be compromised than either A or B.
But the design approach taken in the Hoffman et. al. proposal is that
publication of a DNSSEC assurance for
Kemp, David P. writes:
> For the DNS/PKI case, if A is an IP address for a dnsname and B is a
> public key for a dnsname, then it is necessary to attack the sources of
> A and B in order to successfully spoof a named server. If A and B come
> from the same system (e.g., DNS) it is necessary to at
As much as I hate to spam multiple lists, I need to correct a technical error.
And, really, this discussion should be happening on the keyassure mailing list.
At 12:56 PM -0400 10/5/10, Phillip Hallam-Baker wrote:
>But the design approach taken in the Hoffman et. al. proposal is that
>publicatio
> You are working on wrong assumptions. The DV certs are exactly as
> strong as your DNS is. You only need to attack DNS to issue a DV cert.
>
> Ondrej Sury
Certificate issuance is not the end of the game. Clients have opportunity to
avoid being fooled by a DV certificate if they choose. Why
David,
When I originally looked at this scheme I thought that it was intended to
reduce the attack surface in the manner you describe.
Clearly if you have two controls, A and B and BOTH must be compromised, the
system is less likely to be compromised than either A or B.
But the design approach t
You are working on wrong assumptions. The DV certs are exactly as strong as
your DNS is. You only need to attack DNS to issue a DV cert.
Ondrej Sury
On 5.10.2010, at 18:32, "Kemp, David P." wrote:
> You are confusing attack surface with vulnerability. Without getting
> into technology specifi
You are confusing attack surface with vulnerability. Without getting
into technology specifics, if A .and. B must be successfully attacked in
order to cause a problem, then having two systems can only reduce the
vulnerability even though there are more places to attack.
If the problem is availabi
>>> DNSSEC provides a "secure" association FROM the name TO the IP
>>> address.
>> Incorrect characterisation. DNSSEC provides only for secure
>> distribution of DNS records. Whether the distributed DNS records
>> are accurate or trustworthy is a completely distinct issue.
> I think secure distri
On Oct 4, 2010, at 5:46 PM, Martin Rex wrote:
>> DNSSEC provides a "secure" association FROM the name TO the IP address.
>> But the DNS domain owner tends not to be the host owner so this asserted
>> association may not reflect the intent of the host owner.
>> Also, DNSSEC doesn't protect from IP
Michael StJohns wrote:
>
> DNSSEC seems to be picking on PKIX and vice versa
> - maybe the right answer is both?
In theory, PKIX could provide real value.
In practice, the PKIX abuse commonly described as "TLS PKI"
that performs a non-popup server endpoint identification with the help
of target
Michael and all,
Nice outline. What still bothers me is all this is still tied
to trust anchors. How do we or anyone know or do about a trust
anchor that has been corrupted or otherwise breached? It is likely
that the knowing of same will be delayed by some time factor and the
potential damag
14 matches
Mail list logo
