On Mon, Aug 25, 2008 at 04:24:08PM -0400,
Andrew Sullivan <[EMAIL PROTECTED]> wrote
a message of 61 lines which said:
> Moreover, it will aid interoperation and user experience if clients
> can, in corner cases, learn what rules the server has in place so
> that clients can perform mappings con
On Tue, Aug 26, 2008 at 05:25:44PM -0400, Dean Anderson wrote:
> An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty
Wait a minute. You're proposing to show that "a DNSSEC cache" that
doesn't actually do DNSSEC (whatever that would mean) can be poisoned?
I'm not sure I see th
In your previous mail you wrote:
> it seems T/TCP is dead because of some security issues.
Correct (RFC 4614, section 5) but, unfortunately, these issues were
apparently never properly documented (no "T/TCP deprecated" RFC) and
it is hard to find a reference to a description of th
On Tue, 26 Aug 2008, Ted Lemon wrote:
> On Aug 26, 2008, at 1:06 PM, Dean Anderson wrote:
> > How could their testing and analysis be considered 'thorough' or
> > credible when they didn't find the very serious flaws just recently
> > identified on this list?
>
> To summarize, the two "flaws" to
I suggest you review the past emails and the RFC's to find out what is
meant by a 'non-verifying DNSSEC cache'.
A DNSSEC-aware cache need not verify the responses it caches. It can
leave that task to the stub-resolver. By having the stub resolvers
perform the crypto checks, the crypto computation
On Tue, 26 Aug 2008, Ted Lemon wrote:
> If you had a problem with (1), you should have raised this back when
> the working group made this change.
The above criticism is an entirely disingenuous comment. Mr Lemon has
previously been made aware that critics of DNSSEC were silenced on
DNSEXT W
On Aug 27, 2008, at 3:45 PM, Dean Anderson wrote:
> I'm not sure I agree with your summary of the NSEC/NSEC3 issues. I'll
> mostly ignore your summary for now and just note that there are a
> number
> of other serious flaws.
It's hard to take a statement like this seriously when it's not backed
> Some comments on incorrect assertions on the NSEC/NSEC3 attacks.
>
> >(1) there is no cryptographic defense against an attack where the
> > attacker convinces the target that a zone that does not exist at all
> > does exist.
It is not possible to do this with NSEC. Names eithe
Dean Anderson wrote:
> On Sun, 24 Aug 2008, Brian Dickson wrote:
>
>
>> Dean Anderson wrote:
>>
>>> On Sun, 24 Aug 2008, Dean Anderson wrote:
>>>
>>>
>>>
Ok. But when you resign using arbitrary data controlled by the
attacker, the private key can be obtained. [There is
[EMAIL PROTECTED] wrote:
> On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
>
>> The DS may be provided by the operator of the subordinate zone, or built
>> by the parent operator,
>> most likely the latter.
>>
>
>
> thats an interesting premise.
> why do you th
10 matches
Mail list logo
