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 create
Nicholas Weaver writes:
> On Nov 1, 2013, at 7:57 AM, Derek Atkins 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,
>>
Masataka Ohta 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
> need a generic new docu
On Nov 1, 2013, at 7:57 AM, Derek Atkins 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 algorithm,
> On 1 Nov 2013, at 06:35, Evan Hunt 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 ha
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 t
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
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
Masataka Ohta 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 risk of
interference by a man-in
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
> http://www.businesswire.com/
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 plan
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.*
http://192.168
> From: Masataka Ohta
> Date: 2013-10-29 14:22
> To: Mark Andrews
> CC: 'Andrew Sullivan'; DNSOP; Hosnieh Rafiee; dnsext
> Subject: Re: [DNSOP] [dnsext] DNS vulnerabilities
> Mark Andrews wrote:
>>> Not necessarily. Some security protocol can safely assume
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.
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 eq
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
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 beli
On Oct 28, 2013, at 12:07 AM, Masataka Ohta
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 does not equal protecting the dat
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
> clo
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 <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 vulnerabiliti
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
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--
Ho
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 v
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 i
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
implementati
26 matches
Mail list logo