Tony Finch wrote:
I have the beginnings of a solution to this problem. It is based on using
tlsdate, which gets the time from a server with minimal risk of
interference by a man-in-the-middle.
TLS is another PKI and is inherently insecure as CAs can be
compromised.
As David Conrad wrote in
Hi, Hosnieh,
Do you think it will be relevant to this document or it can be
another informational document only discuss about the
vulnerabilities of cryptographic algorithms?
As I said, it is a known vulnerability. That is, we don't
need a generic new document very much.
However, Snowden
On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote:
TLS is another PKI and is inherently insecure as CAs can be
compromised.
True, but Tony's quorum-based approach could be made exhaustive enough
that the adversary would have to have compromised *every* CA. If they
can do that, I'm
On 1 Nov 2013, at 06:35, Evan Hunt e...@isc.org wrote:
On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote:
TLS is another PKI and is inherently insecure as CAs can be
compromised.
True, but Tony's quorum-based approach could be made exhaustive enough
that the adversary would
On Nov 1, 2013, at 7:57 AM, Derek Atkins de...@ihtfp.com wrote:
It is unclear to me that ECC as a generic technology is bad, although
any specific curves creates by NIST/NSA are certainly suspect.
Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash,
Public Key, or Cipher
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp writes:
Hi, Hosnieh,
Do you think it will be relevant to this document or it can be
another informational document only discuss about the
vulnerabilities of cryptographic algorithms?
As I said, it is a known vulnerability. That is, we don't
Nicholas Weaver nwea...@icsi.berkeley.edu writes:
On Nov 1, 2013, at 7:57 AM, Derek Atkins de...@ihtfp.com wrote:
It is unclear to me that ECC as a generic technology is bad, although
any specific curves creates by NIST/NSA are certainly suspect.
Having said that, Dual-EC-DRBG is a Random
Derek Atkins wrote:
However, Snowden taught us that we must avoid any fancy
cryptography strongly promoted by NIST, including all the
EC related ones, which may be documented somewhere.
It is unclear to me that ECC as a generic technology is bad, although
any specific curves creates by
Hi Masataka,
Thank you for your useful inputs.
While this is, in theory, a known vulnerability, it is still surprising that
USG
actively used it.
Mocana Purges NSA-Compromised Key-Generation Scheme from Its Popular
Nanocrypto Embedded Security Engine
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote:
As was discussed recently in IETF ML, a serious vulnerability of,
so called, DNSSEC is lack of secure time.
I have the beginnings of a solution to this problem. It is based on using
tlsdate, which gets the time from a server with minimal
Guangqing Deng wrote:
I am wondering is it possible to provide a mechanism for people
manually modifying the clock
of home routers just as people setting the clock of their laptops.
A problem is that there are too much ways to do so such as
http://192.168.0.*
Hosnieh Rafiee wrote:
I have gathered some vulnerabilities in the current DNS security approaches
such as DNSSEC and etc. We think it is useful to have a survey of existing
vulnerabilities or any new vulnerabilities so that we can address those
issues in other standard RFC. This is why we
Mark Andrews wrote:
Not necessarily. Some security protocol can safely assume
clocks of related equipments are manually managed by skilled
operators, which is not the case with DNS clients.
Most people are capable of setting the clocks on their laptops,
phones and other portable equiment
David Conrad wrote:
Then, plain DNS modified to have 32 (or 64?) bit messages
ID is as secure as DNSSEC.
How does a 32 or 64 bit message ID protect you from on-path
MITM/injection attacks?
Tell it to those who are asserting plain NTP were good enough
for DNSSEC.
On Oct 28, 2013, at 12:07 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
Then, plain DNS modified to have 32 (or 64?) bit messages
ID is as secure as DNSSEC.
How does a 32 or 64 bit message ID protect you from on-path MITM/injection
attacks?
Protecting the communication channel
How could a local time problem lead to using an expired (zone) key for
arbitrary data of the zone ?
~ DNSKEY info itself does not expire - only signatures have expiration date
~ admitting a local time problem can allow for replay attacks
in the sense of : making a validating resolver believe
On Mon, Oct 28, 2013 at 04:57:46PM +0100, Marc Lampo wrote:
How could a local time problem lead to using an expired (zone) key for
arbitrary data of the zone ?
There is a genuine theoretical concern here, but IMHO it's unrealistic.
Imagine some shadowy omnipotent organization has tapped your
In message 526baeae.6080...@necom830.hpcl.titech.ac.jp, Masataka
Ohta writes:
Hosnieh Rafiee wrote:
I have gathered some vulnerabilities in the current DNS security
approaches such as DNSSEC and etc. We think it is useful to have a
survey of existing vulnerabilities or any new
Hosnieh Rafiee wrote:
I guess this problem is also true for any protocol that uses timestamp in
their signature and not DNSSEC specific.
Not necessarily. Some security protocol can safely assume
clocks of related equipments are manually managed by skilled
operators, which is not the case with
In message 526de2ff.3040...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Hosnieh Rafiee wrote:
I guess this problem is also true for any protocol that uses timestamp in
their signature and not DNSSEC specific.
Not necessarily. Some security protocol can safely assume
clocks of
its hard to distinguish an implementation error and a DNS protocol error, so
yes, it might
be a very good idea to triage your failures properly.
/bill
On Sat, Oct 26, 2013 at 01:28:10AM +0200, Hosnieh Rafiee wrote:
Hi Bill,
Thanks for your message.
are your new collection, DNS
are your new collection, DNS vulnerabilities, configuration mistakes, or
implementation faults?
/bill
On Sat, Oct 26, 2013 at 01:16:29AM +0200, Hosnieh Rafiee wrote:
Hello,
I have gathered some vulnerabilities in the current DNS security approaches
such as DNSSEC and etc. We think it
Thank you again, Bill.
it's hard to distinguish an implementation error and a DNS protocol
error, so
yes, it might be a very good idea to triage your failures properly.
Yes I guess it's really a good comment to consider in this work.
@list: Any other ideas?
---smile--
In message 526baeae.6080...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Hosnieh Rafiee wrote:
I have gathered some vulnerabilities in the current DNS security approaches
such as DNSSEC and etc. We think it is useful to have a survey of existing
vulnerabilities or any new
Hi Bill,
Thanks for your message.
are your new collection, DNS vulnerabilities, configuration mistakes, or
implementation faults?
Currently I collected some information regarding DNS vulnerabilities and
some about configuration mistakes. But I haven't included anything regarding
25 matches
Mail list logo
