headers
Rob Austein | 6 Aug 2007 04:40

Re: Request for IETF69 DNSOP Agenda Items

At Fri, 6 Jul 2007 11:45:25 -0400 (EDT), Dean Anderson wrote:
> 
> I would like to have the WG discuss taking up my draft 
> (draft-anderson-reverse-dns-status) as a WG document.
> 
> Thanks,
> 
> 		--Dean

<hat wg-co-chair="on">

  Per Dean's request, I asked those WG participants who were present
  at the Chicago meeting two questions:

  Q1) How many had read Dean's draft?

  A1) 12 people claimed to have read Dean's draft.

  Q2) Of those who had read Dean's draft, how many supported adoption as
      of Dean's draft as a WG document instead of
      draft-ietf-dnsop-reverse-mapping-considerations

  A2) Nobody present in the room supported adoption of Dean's draft.

  As with any decision made at a face to face meeting this is not
  official until confirmed on the mailing list.  So if there is anyone
  who:

  1) Has read Dean's draft, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Austein | 6 Aug 2007 04:43

Confirmation of Chicago decision on draft-anderson-reverse-dns-status

[Resending with fixed subject line, sorry for the duplication --sra]

At Fri, 6 Jul 2007 11:45:25 -0400 (EDT), Dean Anderson wrote:
> 
> I would like to have the WG discuss taking up my draft 
> (draft-anderson-reverse-dns-status) as a WG document.
> 
> Thanks,
> 
> 		--Dean

<hat wg-co-chair="on">

  Per Dean's request, I asked those WG participants who were present
  at the Chicago meeting two questions:

  Q1) How many had read Dean's draft?

  A1) 12 people claimed to have read Dean's draft.

  Q2) Of those who had read Dean's draft, how many supported adoption as
      of Dean's draft as a WG document instead of
      draft-ietf-dnsop-reverse-mapping-considerations

  A2) Nobody present in the room supported adoption of Dean's draft.

  As with any decision made at a face to face meeting this is not
  official until confirmed on the mailing list.  So if there is anyone
  who:
(Continue reading)

Permalink | Reply | 10 comments |
headers
Dean Anderson | 6 Aug 2007 22:33

Re: Confirmation of Chicago decision on draft-anderson-reverse-dns-status

Would it be too much to ask the 12 people who read the draft, what 
problems they have with the draft?

What changes would be necessary to obtain support?

Thanks,

		--Dean

On Sun, 5 Aug 2007, Rob Austein wrote:

> [Resending with fixed subject line, sorry for the duplication --sra]
> 
> At Fri, 6 Jul 2007 11:45:25 -0400 (EDT), Dean Anderson wrote:
> > 
> > I would like to have the WG discuss taking up my draft 
> > (draft-anderson-reverse-dns-status) as a WG document.
> > 
> > Thanks,
> > 
> > 		--Dean
> 
> <hat wg-co-chair="on">
> 
>   Per Dean's request, I asked those WG participants who were present
>   at the Chicago meeting two questions:
> 
>   Q1) How many had read Dean's draft?
> 
>   A1) 12 people claimed to have read Dean's draft.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Andrew Sullivan | 8 Aug 2007 01:00

Re: Confirmation of Chicago decision on draft-anderson-reverse-dns-status

Dear colleagues,

On Mon, Aug 06, 2007 at 04:33:18PM -0400, Dean Anderson wrote:
> Would it be too much to ask the 12 people who read the draft, what 
> problems they have with the draft?
> 
> What changes would be necessary to obtain support?

<hat="none">
I have read the draft.  Dean, do you solicit my feedback as to what
changes would be necessary to obtain my (individual) support?  If so,
I will send those remarks.
</hat>

<hat="draft editor">
I note that I asked explicitly about two sets of remarks from the
-anderson- draft that the current editors thought were possible
candidates for inclusion in the current working group draft, and
received no feedback in the meeting for such inclusion.
</hat>

Best regards,

A

--

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew <at> ca.afilias.info>                              M2P 2A8
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stephane Bortzmeyer | 8 Aug 2007 12:35
Picon

DNS pinning, anti-pinning and rebinding in DNSOP?

I'm afraid that we will be sollicited one day or the other to write a
RFC about DNS practices to limit rebinding? It seems trendy.

Do note that many advices in "Protecting Browsers from DNS Rebinding
Attacks" (http://crypto.stanford.edu/dns/dns-rebinding.pdf) belong in
our perimeter (some remind me of
draft-ietf-dnsop-reverse-mapping-considerations, some ask for a
violation of the DNS protocol). Advices?

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 3 comments |
headers
Pekka Savola | 8 Aug 2007 14:09
Picon

Re: DNS pinning, anti-pinning and rebinding in DNSOP?

On Wed, 8 Aug 2007, Stephane Bortzmeyer wrote:
> I'm afraid that we will be sollicited one day or the other to write a
> RFC about DNS practices to limit rebinding? It seems trendy.
>
> Do note that many advices in "Protecting Browsers from DNS Rebinding
> Attacks" (http://crypto.stanford.edu/dns/dns-rebinding.pdf) belong in
> our perimeter (some remind me of
> draft-ietf-dnsop-reverse-mapping-considerations, some ask for a
> violation of the DNS protocol). Advices?

Thanks for the interesting link.  This certainly shows that "use 
hostnames everywhere" idiom that the IETF has been repeating doesn't 
quite work as intended in the real life :-)

I wonder if the authors and vendors have considered if there are 
conseuqences for IPv4/IPv6 dual-stack operation where a standard 
practice is to provide multiple IP addresses under a single name.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
Permalink | Reply | 1 comment |
headers
Phil Regnauld | 8 Aug 2007 14:21

Re: DNS pinning, anti-pinning and rebinding in DNSOP?

Pekka Savola (pekkas) writes:
> 
>  Thanks for the interesting link.  This certainly shows that "use hostnames 
>  everywhere" idiom that the IETF has been repeating doesn't quite work as 
>  intended in the real life :-)

    Yes it does, it's not a bug, it's a feature.  It does exactly the right
    thing from the point of view of the implementation.  This is, in my
    opinion, the same problem scope as IDN homographic attacks, just one
    level of interaction (App <-> DNS, as opposed to User <-> APP).

    Section 5.2 of the paper suggests:

"Instead of trying to prevent a host name from rebinding 
 from one IP address to another -- a fairly common event --
 a different approach to defending against rebinding is to 
 prevent the attacker from naming the target server."

    IMHO the problem is there, i.e.: fix the application (browser
    javascript/sandboxing mechanisms), don't blame DNS for doing exactly
    what it was intended to do.

    It'd be even more stupid to look up IPs once and stick to those
    during the life of the application (== execution of the Flash code,
    or JS code, which can be anything from a few milliseconds to several
    hours).  The problem is the same as for traditional (read: standalone)
    applications which lookup IPs once and never look them up again.

    Other solutions are outlined such as blocking direct DNS queries to
    the outside world, and/or using DNS software that refuses to relay
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Koch | 8 Aug 2007 20:10
Picon
Favicon

Publication Request: draft-ietf-dnsop-reflectors-are-evil-04.txt

Dear ADs,

this is a request to publish

	"Preventing Use of Recursive Nameservers in Reflector Attacks"
        draft-ietf-dnsop-reflectors-are-evil-04.txt

as a Best Current Practice RFC. This is a DNSOP work item.
Please find below the PROTO questionnaire.

Thanks,
  Peter

-----------------------------------------------------------------------------

(1.a)  Who is the Document Shepherd for this document?  Has the
       Document Shepherd personally reviewed this version of the
       document and, in particular, does he or she believe this
       version is ready for forwarding to the IESG for publication?

	Peter Koch (==me) is the Document Shepherd for this document.
	I have read the latest version (-04) of the draft and believe it
	is ready for consideration by the IESG.

(1.b)  Has the document had adequate review both from key WG members
       and from key non-WG members?  Does the Document Shepherd have
       any concerns about the depth or breadth of the reviews that
       have been performed?

	The draft has undergone in-depth review in the DNSOP WG and has
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Anderson | 8 Aug 2007 21:25

Re: Confirmation of Chicago decision on draft-anderson-reverse-dns-status

On Tue, 7 Aug 2007, Andrew Sullivan wrote:

> Dear colleagues,
> 
> On Mon, Aug 06, 2007 at 04:33:18PM -0400, Dean Anderson wrote:
> > Would it be too much to ask the 12 people who read the draft, what 
> > problems they have with the draft?
> > 
> > What changes would be necessary to obtain support?
> 
> <hat="none">
> I have read the draft.  Dean, do you solicit my feedback as to what
> changes would be necessary to obtain my (individual) support?  If so,
> I will send those remarks.
> </hat>

Yes, thanks.

	--Dean

--

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dean Anderson | 8 Aug 2007 22:04

Re: DNS pinning, anti-pinning and rebinding in DNSOP?

This attack is at once more nefarious and less nefarious than article 
documents.

It is more nefarious because many 'single site' schemes based on DNS 
trust *.somedomain.tld as IP resources belonging to somedomain.tld.  You 
don't have to rebind even.  The site www.attacker.com gives a script 
that accesses www1.attacker.com, and www1.attacker.com has internal ip 
addresses.

This is just another in a series of mistaken assumptions made about DNS,
and (mis) using DNS for trust purposes. In this case, the trust that the
same name resolves to (essentially) the same site is misplaced.

I think the correct solution for browsers is not to open additional
connections based on requests from external scripts, but to hold open
the original connection.  External scripts should not be long lived, and
not longer than the original connection.  If the script should live
longer, the original IP address should be used for connection, not the
DNS entry.  The external script has no business outlasting the external
web server.

Cross Site Scripting is a serious and tough problem, and DNS rebinding
is a very small part of it.  But the core of both problems is misplaced
assumptions of trust.  The difficulty with XSS is that the malicous code
has access to the document model, and can alter other scripts, access
other fields, and do quite a lot.  Infection is not just limited to
visiting a suspicious web site. The malicious code can be placed in your
own database, or some other sites database, and output to your browser.  
It can be placed in pdfs, in anything that does javascript.  And the
malicious code doesn't even have to exploit vulnerabilities in the local
(Continue reading)

Permalink | Reply | 0 comments |

Gmane