On 7/21/2010 8:12 PM, Phillip Hallam-Baker wrote:
DNSSEC is not designed to address those particular issues.\
AMEN
X.509v3 is designed to address them, or at least is capable of doing
so if configured in the right way.
True - if its used correctly.
Now the question I think we should consider is what is going to happen
when all the people who read ICANN press releases that essentially
tell them that DNSSEC is capable of serving these security needs start
relying on the assumptions.
They will see ICANN's commentary and simply bring suit in California
Court now that Khaled opens that can of worms where the IETF refused to
allow those issues to be resolved. If the DNSSEC model doesnt pass
muster there it's toast and I think we all know what would happen...
My strong belief is that the Internet needs one PKI not two and that
we should start looking about how to use the combination of DNSSEC and
X.509 so that we get the best from both. When people suggest using
DNSSEC for the type of purposes that they have previously used self
signed certs I do not get worried. But when they start suggesting
using DNSSEC as a replacement for cases where you need non-repudiation
or accountability, I get very worried.
So in Khaled is Redflex is trying to 'have the ruling unpublished'
claiming that they could have meet these requirements if they had been
given the chance, but the real issue here is whether the Court has an
obligation to hear claims about the process from third parties with a
financial interest in the matter.
Also Redflex was the party who captured that photo so it was aware of
the whole court process for that matter and chose not to attend. As such
it was Redflex's issue about not being there.
So assume DNSSEC is attacked in a California District Court as
'non-functional from an evidence perspective' which is something very
possibly and probable today.
You realize that Khaled affects all of the Businesses everywhere in the
4th District's sphere of influence and Jurisdiction?
I would strongly suggest that anyone who is interested in the legal
side of technology take a look at the case whether they consider it
relevant to DNSSEC or not.
http://www.thenewspaper.com/rlc/docs/2010/ca-khaled.pdf
My reading of the case is that the appeals court knows that there are
much better processes and technical means that could have been used to
protect the chain of custody for the evidence in that case and they
want to ensure that their concerns are urgently attended to.
Meaning if DNSSEC is flawed - there are now precedents which can be used
easily in California Courts to make DNSSEC a nightmare come true...
I think the application of the ruling is dead on which is why I posted
it and I am also sure it will seriously annoy many Sr. Professional IETF
Standards people since it totally rains on their parade but since they
refused to address these issues or even allow the discussion of these
issues long ago - the IETF is once again standing waste deep in its own
sh*t.
Sorry folks but reality is what it is and it that is that it's law that
shapes technology not the reverse.
Todd
On Wed, Jul 21, 2010 at 8:09 PM, todd glassey
<tglassey(_at_)earthlink(_dot_)net> wrote:
On 7/21/2010 1:41 PM, Peter DeVries wrote:
Todd, I just read the ruling on this and am confused as to why you
would think this applies to DNSSEC rather than DNS (or other
information systems).
Because I read the opinion and looked at what the idea of trustworthy
meant to the court. Something that is really really different than what
technical people think trustworthy meets.
The reason this case was unable to proceed and
the evidence was rejected seems to be because of the police handling
of the system and witness. The ruling specifically states that
video/evidence capture devices are still admissible (See section II
"analysis") as long as timeline and/or "reasonable representation of
what it is alleged to portray." is available.
So then the time-service and sequence of events would need to be
provable... I totally get that.
The problem is that the officer made available to the court had no
firsthand knowledge of the incident, no understanding of the system,
no knowledge of the time of information handling, and no internal
knowledge of the development / testing of the system
Yep...
Either this applies everywhere and DNSSEC is not unique or it applies
nowhere as the data path will be further confirmed by
administrator/operator knowledge.
Bingo - it applies everywhere. But the idea of DNSSEC being a solution
to the issue of evidence capture regarding any and all processes
Can you explain in more detail with specific references as to how this
applies to DNSSEC or IS systems as a whole. I fail to see your
concern.
It applies to everything that creates data which could come to be
reviewed by a court.
Also, operations is separate from prosecution. DNSSEC has
other purposes than prosecution and can most certainly be operated
within this ruling. I don't personally see issues with prosecution as
long as the witnesses understand and explain how the situation was
handled.
The problem is the integrity of the data model and whether it produces
BTW, the appeals case number I read is: 30-2009-00304893. Please let
me know if there is another case you are referencing.
No that's it.
Peter
On Wed, Jul 21, 2010 at 3:56 PM, todd glassey
<tglassey(_at_)earthlink(_dot_)net> wrote:
Folks - there is a Court Ruling from the 4th Appellate District which
is turning off Red Light Camera's everywhere and there is a question as
to whether that ruling would also effect how Secure DNS Services are run
and if so what would it do.
The ruling is called California v Khaled and is getting significant
traction here in the State of California in all courts.
Todd
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf