On Mon, 4 Oct 2010, Phillip Hallam-Baker wrote:
2) Sanction CAs that issue unauthorized certificates
What would you say a valid sanction would be for a CA that issues a bad
certificate for 10 major websites like Mozilla and Yahoo?
What should the sanction be for a CA whose reseller's subCAs i
On 10/05/2010 02:46 PM, Martin Rex wrote:
The DNS admin that controls A can always get a perfectly valid
certificate B issued and successfully impersonate all services
offered on servers in his DNS domain.
By most people's definition, it's not "unauthorized impersonation" if
the DNS admin doe
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 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
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
For the past five years, CA certificates have been divided into Domain
Validated and Extended Validated. As some of you know, I instigated the
process that led to the creation of EV certs because I was very worried
about the low quality of many DV certificates.
Some DV certificates are of very
On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote:
> What is actually being proposed is to replace the fifteen year established
> system of CAs with a new scheme starting in November.
[. . .]
> I really don't think that we want to replace the existing infrastructure a
> new PKI
On 4 okt 2010, at 17.12, Marsh Ray wrote:
> Say, what's the link to the Internet Draft proposal we're discussing anyway?
https://datatracker.ietf.org/doc/draft-hoffman-keys-linkage-from-dns/, among
others.
j
___
DNSOP mailing list
DNSOP@ietf.
Marsh Ray wrote:
>
> On 10/04/2010 09:37 AM, Martin Rex wrote:
> >
> > It seems that you do not realize that the entire TLS PKI security model,
> > as far as the automatic / no-prompt "server endpoint identification" is
> > concerned, has always been relying completely on that DNS data being
> > a
On 10/04/2010 09:37 AM, Martin Rex wrote:
Phillip Hallam-Baker wrote:
The problem with the DNSSEC path is that it is vulnerable to attacks against
the information input to the DNS system. The weakest link there is the
safeguards on registration of the DNS names.
It seems that you do not reali
Phillip Hallam-Baker wrote:
>
> The attack surface is the number of paths that are open to an attacker.
>
> In the current model there is only one trust path, the PKIX path.
>
> In the new model, the attacker has a choice of trust paths, the PKIX path
> and the DNSSEC path and they can attack ei
On 3 Oct 2010, at 16:14, Phillip Hallam-Baker wrote:
>
> Moving from a market based solution with multiple CAs to a monopoly with one
> trust provider does not help at all. It makes the situation much worse
> because there is now no possibility of choice in the future.
It has the advantage of
If the problem is the lack of checks and balances, the solution should be to
introduce checks and balances.
Moving from a market based solution with multiple CAs to a monopoly with one
trust provider does not help at all. It makes the situation much worse
because there is now no possibility of cho
On 3 Oct 2010, at 02:49, Marsh Ray wrote:
>
> In the meantime, we'd end up with the DNS root effectively having the power
> of yet another CA. Except that it's not, because the various arms of ICANN
> and VeriSign/Symantec are probably already trusted many times over.
I agree with your points
On 10/02/2010 03:16 PM, Ben Laurie wrote:
On 1 October 2010 16:15, Phillip Hallam-Baker wrote:
The problem with that approach is that the attacker now has two
infrastructures that they can attack rather than just one.
If I deploy the DNS solution, stating that DNS is authoritative, then
my a
The attack surface is the number of paths that are open to an attacker.
In the current model there is only one trust path, the PKIX path.
In the new model, the attacker has a choice of trust paths, the PKIX path
and the DNSSEC path and they can attack either of them.
The problem with the DNSSEC
On 1 October 2010 16:15, Phillip Hallam-Baker wrote:
>
>
> On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen
> wrote:
>>
>> On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote:
>> > In particular I am very concerned about the particular approach being
>> > taken to security policy. What th
19 matches
Mail list logo
