Re: [dnsext] Practically secure DNS

[Brian Dickson <[e-mail]>]

The proposal does not in any way define "secure", which I believe is
going to be problematic for it to be considered by the WG,
let alone the IETF.

Could you please elaborate on what you mean by "secure"?

On Mon, Oct 24, 2011 at 7:56 PM, Masataka Ohta
<[e-mail]> wrote:
> Paul Wouters wrote:
>
>> Isn't all of this already proposed in
>> http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01
>
> Which one?
>
>> It also totally ignores the fact that if all involved name servers are
>> "secure" (definition unknown) but
>
> SDNS also totally ignores the fact that SDNS with automatic servers
> for clients to modify domain information is not secure if related
> servers are not secure.

SDNS considers the modification of domain information out-of-scope.

However, DNS registry operators, registrars, and DNS hosting operators
do not ignore this, and generally employ
whatever they consider best practice in securing their servers, and in
limiting the extent of problems if a server
which by necessity is exposed to the Internet, gets compromised.

>> the traffic path is not,
>
> SDNS with automatic servers for clients to modify domain
> information with password confirmation is not secure if the
> traffic path is not secure.

By negating the conclusion, we in turn infer the negation of the preposition.
If the traffic path is secure, SDNS ... is secure.

Current best (and common) practice is to submit domain information
over secure channels.
This includes encrypted email (2048 RSA), physical devices (flash
memory), out-of-band (fax),
and SSL-protected or IPsec-protected connections (e.g. https).

>> the "secure" client is still going to take
>> rewritten replies. Eg this draft
>> does not even handle the "starbucks wifi" scenario or any transparent
>> DNS proxy scenario.
>
> SDNS also ignores the fact that secure time is practically
> impossible to obtain within certain private networks.

SDNS does not require secure time, only "pretty good" time to prevent
replay and never-expired data usage.
Wall-clock time from a reasonably reputable source, such as WWV, the
TV, or the USNO web site, are all good enough.
Set once, and check every 6 months by comparing to another reasonably
okay source, is more than enough for SDNS.

SDNS addresses man-in-the-middle (providing modified-but-consistent
results). That meets my definition of "secure".

How does not addressing man-in-the-middle (which your proposal does
not) in any way meet the definition of "pretty secure"?

Brian
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext