Joe Baptista | 1 Jun 03:02 2009

DNSSEC is NOT secure end to end


DNSSEC indeed violates the end to end principle.  It's simply that simple.  And it asks us to put our trust in the root a.k.a. ICANN.  I don't think governments world wide are going to put their trust and faith in ICANN.  The U.S. Government is the only government that has been bamboozled into adopting DNSSEC into .gov infrastructure.

I wonder how President Obama would feel about handing over the keys to U.S. Government infrastructure to a U.S. contractor.  I'd have trouble sleeping at night if that was the case.

I've addressed this at length in my comments to the NTIA.

http://www.ntia.doc.gov/DNS/comments/comment034.pdf

If the U.S. government wants DNSSEC today then it must nationalize the roots.  I don't even trust Vixie with the root.  I remember when he hijacked the root with Postel.  Or as they put it "we were only running an experiment".

In any case the new infrastructure campaign demands U.S. government roots be set up to exclusively serve U.S. network infrastructure.

regards
joe baptista

p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.

http://dnscurve.org/


On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta <mohta <at> necom830.hpcl.titech.ac.jp> wrote:
Francis Dupont wrote:

> => not only this is very arguable (for instance about the resource
> exhaustion) but no hop-by-hop/channel security, even something as
> strong as TSIG, can provide what we need, i.e., end-to-end/object
> security (*).

Unless your meaning of end-to-end differs from that of David Clark,
the following argument of his paper is applicable to DNSSEC.

       http://portal.acm.org/citation.cfm?doid=383034.383037
       Rethinking the design of the Internet:
       The end to end arguments vs. the brave new world

       The certificate is an assertion by that (presumably
       trustworthy) third party that the indicated public key
       actually goes with the particular user.

       These certificates are principal components of essentially
       all public key schemes,

That is, security of DNSSEC involves third parties and is not end
to end.

> PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one.

I'm afraid you don't know who David Clark is and how he is related
to the end to end argument.

However, all the people who are qualified to discuss end to end do
know him and his argument.

                                                       Masataka Ohta

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf



--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community <at> large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com



--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community <at> large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Mark Andrews | 1 Jun 03:38 2009

Re: DNSSEC is NOT secure end to end


In message <874c02a20905311802r2b9b4544j374bb374eb7a7ee4 <at> mail.gmail.com>, Joe Baptista writes:
> DNSSEC indeed violates the end to end principle.  It's simply that simple.
> And it asks us to put our trust in the root a.k.a. ICANN.  I don't think
> governments world wide are going to put their trust and faith in ICANN.  The
> U.S. Government is the only government that has been bamboozled into
> adopting DNSSEC into .gov infrastructure.
> 
> I wonder how President Obama would feel about handing over the keys to U.S.
> Government infrastructure to a U.S. contractor.  I'd have trouble sleeping
> at night if that was the case.
> 
> I've addressed this at length in my comments to the NTIA.
> 
> http://www.ntia.doc.gov/DNS/comments/comment034.pdf
> 
> If the U.S. government wants DNSSEC today then it must nationalize the
> roots.  I don't even trust Vixie with the root.  I remember when he hijacked
> the root with Postel.  Or as they put it "we were only running an
> experiment".
> 
> In any case the new infrastructure campaign demands U.S. government roots be
> set up to exclusively serve U.S. network infrastructure.
> 
> regards
> joe baptista
> 
> p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.
> 
> http://dnscurve.org/

	DNSCurve has exactly the same trust issues as DNSSEC does.
	You are trusting the parent to give you a secure introduction
	to the child.  The introduction is just encoded differently.

	Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
Joe Baptista | 1 Jun 06:00 2009

Re: DNSSEC is NOT secure end to end

I disagree.  DNSCurve has nothing to do with trust.  It simply ensure the system you are connected to is in fact the system that gives you the answer.  DNSCurve addresses the UDP issues without the need for a root or any other third party enjoying any degree of trust.

Totally different from DNSSEC.

regards
joe baptista

On Sun, May 31, 2009 at 9:38 PM, Mark Andrews <marka <at> isc.org> wrote:

In message <874c02a20905311802r2b9b4544j374bb374eb7a7ee4 <at> mail.gmail.com>, Joe Baptista writes:
> DNSSEC indeed violates the end to end principle.  It's simply that simple.
> And it asks us to put our trust in the root a.k.a. ICANN.  I don't think
> governments world wide are going to put their trust and faith in ICANN.  The
> U.S. Government is the only government that has been bamboozled into
> adopting DNSSEC into .gov infrastructure.
>
> I wonder how President Obama would feel about handing over the keys to U.S.
> Government infrastructure to a U.S. contractor.  I'd have trouble sleeping
> at night if that was the case.
>
> I've addressed this at length in my comments to the NTIA.
>
> http://www.ntia.doc.gov/DNS/comments/comment034.pdf
>
> If the U.S. government wants DNSSEC today then it must nationalize the
> roots.  I don't even trust Vixie with the root.  I remember when he hijacked
> the root with Postel.  Or as they put it "we were only running an
> experiment".
>
> In any case the new infrastructure campaign demands U.S. government roots be
> set up to exclusively serve U.S. network infrastructure.
>
> regards
> joe baptista
>
> p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC.
>
> http://dnscurve.org/

       DNSCurve has exactly the same trust issues as DNSSEC does.
       You are trusting the parent to give you a secure introduction
       to the child.  The introduction is just encoded differently.

       Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org



--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community <at> large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Mark Andrews | 1 Jun 06:30 2009

Re: DNSSEC is NOT secure end to end


In message <874c02a20905312100g120b83c7ufbfc13b2849a4aa8 <at> mail.gmail.com>, Joe Baptista writes:
> 
> I disagree.  DNSCurve has nothing to do with trust.  It simply ensure the
> system you are connected to is in fact the system that gives you the
> answer.  DNSCurve addresses the UDP issues without the need for a root or
> any other third party enjoying any degree of trust.

	If you believe that I have a bridge to sell you.

> Totally different from DNSSEC.
> 
> regards
> joe baptista

	You can disagree all you want but it doesn't change the
	fact that DNSSEC and DNSCurve both have chains of trusts.
	The proponents of DNSCurve even say this.
	
	Note the chain of trust as described on
	http://www.dnscurve.org/tld.html/.

The root DNS servers can also be protected with DNSCurve. Once a
cache knows DNSCurve server names for the root servers, its packets
to and from those servers are protected, so it securely learns the
DNSCurve server names for .com and other top-level domains, so its
packets to and from the .com servers are protected, so it securely
learns the DNSCurve server names for nytimes.com, etc.

	Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
Joe Baptista | 1 Jun 15:08 2009

Re: DNSSEC is NOT secure end to end



On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews <marka <at> isc.org> wrote:

       If you believe that I have a bridge to sell you.

Keep the bridge - it's all yours.  Remember - in order to sell the bridge you first have to own it.  Your convenced you have something to sell.  I am not.


> Totally different from DNSSEC.
 

       You can disagree all you want but it doesn't change the
       fact that DNSSEC and DNSCurve both have chains of trusts.
       The proponents of DNSCurve even say this.

       Note the chain of trust as described on
       http://www.dnscurve.org/tld.html/.

The correct URL is http://www.dnscurve.org/tld.html not http://www.dnscurve.org/tld.html/

And yet again - it has nothing to do with chains of trust.  It does learn how to trust and whom to trust.  Thats part of the job.  What DNSCurve does do is it "adds link-level public-key protection to DNS packets" therefore guaranteeing the integrity of the packets end to end. 

Totally different from DNSSEC which indeed uses chains of trust - i.e. root to tld to sld etc.etc.

I am totally amazed at the propaganda that comes out of ISC these days.  When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is this - I have this really nice bridge on the Hudson I'd like to sell you that will compliment the bridge you've already have.

cheers
joe baptista

--
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community <at> large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Jari Arkko | 1 Jun 16:47 2009
Picon

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

I am bringing this draft to its second last call. After the completion 
of the headers and boilerplates document and extensive discussions 
within the IESG, it has become clear that several ADs had an issue with 
the 3932bis draft. I have asked Russ to post a new version which I 
believe resolves the issue. However, the changes -- even if small -- 
relate to what information there exists about the status of RFCs in the 
RFCs themselves, so I felt that it this is an issue that needs to be 
taken to the community. I am formally asking for the community review of 
the new version of the draft, but I like to think about this last call 
as a way to find out what the IETF community is thinking about the 
topic. Once we know, I hope we can approve the draft version that 
matches that opinion. Comments should be sent to the ietf <at> ietf.org 
mailing list.

Note that there has been past discussion of what the header and 
boilerplates should say. This discussion happened on the rfc-interest 
list. 3932bis is about IESG notes and IESG processing, and the notes are 
of course very much related to what the boilerplates have already said. 
However, the boilerplates should be taken as given for the purposes of 
our discussion here. The rfc-interest list had consensus to publish the 
headers and boilerplates in its final form. Only changes to 3932bis are 
under consideration now.

The core of the issue is what non-IETF RFCs say about their relationship 
to IETF. According to the new headers and boilerplates document, the 
source is clearly indicated. However, the issue brought up in the IESG 
review was that this can be insufficient at times. In general, 
additional information about the role of the relationship of the RFC to 
the IETF work would be useful for readers. The new version of the 
3932bis draft suggests that the IESG may add a statement to a non-IETF 
RFC about its relationship to IETF work. Previous language indicated 
that such statements would be exceptional.

´╗┐The consensus view on the h&b document was that the front matter should 
say what the RFC is, as opposed to saying what the RFC is not. IESG's 
issue with the 3932bis notes under this situation was three-fold. First, 
there is an assumption that the readers are familiar with the different 
streams (what they are and what they're not) -- which many readers of 
RFCs might not be. Second, the relationship between some non-IETF RFC 
and IETF work is often more complex than is captured by just the stream 
and maturity level. Third, additional explanation (not boilerplate) 
specific to the situation could help putting the work in context

The relevant changes from the previous version of the draft are in 
Section 1.1:

OLD:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label eliminates the need for a mandatory IESG note on all 
Independent Submission and IRTF Stream documents.
NEW:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label replaces some of the information that was previously provided 
in mandatory IESG notes on non-IETF-stream documents. The IESG may 
choose to add an IESG note to an Independent Submission or IRTF Stream 
document that explains the specific relationship, if any, to IETF work.

and Section 3:

OLD:
Generally, the RFC headers and boilerplate clearly describe the 
relationship of the document to the IETF standards process [N3]. In 
exceptional cases, when the relationship of the document to the IETF 
standards process might be unclear, the IESG response may be accompanied 
by a clarifying IESG note and a request that the RFC Editor include the 
IESG note in the document if the document is published.
NEW:
The RFC headers and boilerplate is intended to describe the relationship 
of the document to the IETF standards process [N3]. In addition the IESG 
may request that the RFC Editor include the IESG note to clarify the 
relationship of the document to the IETF standards process, such as 
pointers to related IETF RFCs.

A more detailed diff is available at 
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt

Jari

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Jari Arkko | 1 Jun 16:56 2009
Picon

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

And to start off the comments, I wanted tell my personal opinion about this.

First, I have not been extremely happy with either the h&b or the 
3932bis document, as some people who have been reading the various lists 
may gather. However, I think they were already good enough to be shipped 
before the changes to 3932bis. (And indeed, h&b has been shipped by the 
IAB.) And I can't get that excited about debates regarding the role of 
the various boilerplate texts, because I suspect that the only people 
reading them are the ones who are going to respond to this thread :-)

I do think though that additional information at the level of "This RFC 
describes FOO. A standardized version of FOO can be found from RFC 
NNNN." is useful. I think -07 version of the 3932bis is an improvement 
over the previous one, and should be approved.

Jari
Joel M. Halpern | 1 Jun 17:05 2009

Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP

The changes described in your other note (copied after your text to 
preserve context) are reasonable in the abstract.  However, the devil is 
in the details.
As I understand it, the reason for calling the extra note "exceptional" 
is that the IESG has in the past sometimes used that note to place far 
more pejorative language than you suggest, in places that it really does 
not belong.  That can turn a reasoanble publicaiton request into a 
political fight.

In fact, in most cases where there is a published RFC on the same topic, 
the RFC Editor has demonstrated an expectation that the author will 
define accurately and clearly the relationship of their work to the 
existing published work.  So it is not at all clear to me that the case 
you site is even particularly important.

My inclination would be to stick with the "OLD" wording.

Yours,
Joel

Jari Arkko wrote:
> And to start off the comments, I wanted tell my personal opinion about 
> this.
> 
> First, I have not been extremely happy with either the h&b or the 
> 3932bis document, as some people who have been reading the various lists 
> may gather. However, I think they were already good enough to be shipped 
> before the changes to 3932bis. (And indeed, h&b has been shipped by the 
> IAB.) And I can't get that excited about debates regarding the role of 
> the various boilerplate texts, because I suspect that the only people 
> reading them are the ones who are going to respond to this thread :-)
> 
> I do think though that additional information at the level of "This RFC 
> describes FOO. A standardized version of FOO can be found from RFC 
> NNNN." is useful. I think -07 version of the 3932bis is an improvement 
> over the previous one, and should be approved.
> 
> Jari

(From Jari's earlier message...)
The relevant changes from the previous version of the draft are in 
Section 1.1:

OLD:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label eliminates the need for a mandatory IESG note on all 
Independent Submission and IRTF Stream documents.
NEW:
The IAB and the RFC Editor have made updates to the formatting of the 
title page for all RFCs [N3]. With these changes, the upper left hand 
corner of the title page indicates the stream that produced the RFC. 
This label replaces some of the information that was previously provided 
in mandatory IESG notes on non-IETF-stream documents. The IESG may 
choose to add an IESG note to an Independent Submission or IRTF Stream 
document that explains the specific relationship, if any, to IETF work.

and Section 3:

OLD:
Generally, the RFC headers and boilerplate clearly describe the 
relationship of the document to the IETF standards process [N3]. In 
exceptional cases, when the relationship of the document to the IETF 
standards process might be unclear, the IESG response may be accompanied 
by a clarifying IESG note and a request that the RFC Editor include the 
IESG note in the document if the document is published.
NEW:
The RFC headers and boilerplate is intended to describe the relationship 
of the document to the IETF standards process [N3]. In addition the IESG 
may request that the RFC Editor include the IESG note to clarify the 
relationship of the document to the IETF standards process, such as 
pointers to related IETF RFCs.

A more detailed diff is available at 
http://tools.ietf.org/rfcdiff?url2=draft-housley-iesg-rfc3932bis-07.txt
Mark Andrews | 1 Jun 17:09 2009

Re: DNSSEC is NOT secure end to end


In message <874c02a20906010608p3e7fbdd3wa31c9ea5452a7ab9 <at> mail.gmail.com>, Joe Baptista writes:
> On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews <marka <at> isc.org> wrote:
> 
> >
> >        If you believe that I have a bridge to sell you.
> 
> 
> Keep the bridge - it's all yours.  Remember - in order to sell the bridge
> you first have to own it.  Your convenced you have something to sell.  I am
> not.
> 
> > > Totally different from DNSSEC.
> >
> >
> >        You can disagree all you want but it doesn't change the
> >        fact that DNSSEC and DNSCurve both have chains of trusts.
> >        The proponents of DNSCurve even say this.
> >
> >        Note the chain of trust as described on
> >        http://www.dnscurve.org/tld.html/.
> 
> 
> The correct URL is http://www.dnscurve.org/tld.html not
> http://www.dnscurve.org/tld.html/
> 
> And yet again - it has nothing to do with chains of trust.  It does learn
> how to trust and whom to trust.  Thats part of the job.  What DNSCurve does
> do is it "adds link-level public-key protection to DNS packets" therefore
> guaranteeing the integrity of the packets end to end.

	DNSCurve protects authoritative server to iterative resolver
	if and only if you can authenticate the names of the
	nameservers and that they are supposed to be serving the
	zone you are querying against.  If you can't do that then
	you are just talking to some random server using a cryptographic
	channel and you shouldn't be trusting the results.

> Totally different from DNSSEC which indeed uses chains of trust - i.e. root
> to tld to sld etc.etc.

	And DNSCurve uses chains of trust from root servers to tld
	servers to sld servers etc. etc.

> I am totally amazed at the propaganda that comes out of ISC these days.
> When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is
> this - I have this really nice bridge on the Hudson I'd like to sell you
> that will compliment the bridge you've already have.

> cheers
> joe baptista
> 
> -- 
> Joe Baptista
> 
> www.publicroot.org
> PublicRoot Consortium
> ----------------------------------------------------------------
> The future of the Internet is Open, Transparent, Inclusive, Representative &
> Accountable to the Internet community  <at> large.
> ----------------------------------------------------------------
>  Office: +1 (360) 526-6077 (extension 052)
>     Fax: +1 (509) 479-0084
> 
> Personal: www.joebaptista.wordpress.com
> 
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
Anantha Ramaiah (ananth | 1 Jun 08:30 2009
Picon

RE: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard

Fernando,
    I was modifying the document to update the last call comments and I
would want to make sure if we are on same page w.r.t to your comments.
Pl see inline. 

> -----Original Message-----
> From: fernando.gont.netbook.win <at> gmail.com 
> [mailto:fernando.gont.netbook.win <at> gmail.com] On Behalf Of 
> Fernando Gont
> Sent: Thursday, April 16, 2009 10:15 PM
> To: Anantha Ramaiah (ananth)
> Cc: ietf <at> ietf.org; tcpm <at> ietf.org
> Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure 
> (Improving TCP's Robustness to Blind In-Window Attacks) to 
> Proposed Standard
> 
> On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth) 
> <ananth <at> cisco.com> wrote:
> 
> > > * The document never mentions the fact that this document is 
> > > IPR-encumbered. As far as I recall, much of the dicussion within 
> > > tcpm with respect to the level of requirements of this document 
> > > (MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the 
> > > document should include a warning mentioning that there's 
> an IPR on 
> > > the document, so that implementers can consider this 
> point in their 
> > > decision of whether to implement the described mechanisms or not.
> >
> > I am confused what to do since this is being brought up 
> very late in 
> > the game. That said, there are *many* drafts/RFC's that have IPR on 
> > them in the whole of ietf. Do all them explicitly state the 
> IPR link ? 
> > I'll leave it to the collective wisdom of the group and the 
> chairs to 
> > offer guidance on this matter.
> 
> I personally believe this should be noted in all RFCs on 
> which there's a known IPR. However, Joel Halpern mentioned 
> this is not current practice. If that's the case, I'd have no 
> problem with leaving it "as is". (FWIW, if you look at our 
> tcp-security document, we do recommend the implementation of 
> the counter-measures you propose, but just note that there's 
> an IPR, and that implementers should research how this would 
> affect them).

I think we seem to have concluded this. As per Brian Carpenter's
suggestion I have done an iprnotified = yes in my xml2rfc. I hope that
should take care of this.

<snip>

> 
> > Now the scope of this document is to improve robustness to 
> TCP esp. in 
> > cases where the TCP connection is not protected by other means like 
> > TCP MD5 or TCP AO etc., Now this point is very clear in the 
> document. 
> > That said I have no issues putting a reference to the port 
> > randomization in the document.
> 
> What I mean is that anybody that cares about this stuff 
> (FWIW, I do) would also implement port randmization, ISN 
> randomization, etc. One might argue that there's no use in

It depends on how you view this document. To me, this document is about
improving TCP's robustness on some type of scenarios. It is not intended
to be a plethora of all possible TCP attacks and mitigations.  
> 
> > > and other quite a few times in the tcpm wg list, pre and 
> post wglc, 
> > > but this comment was never addressed. It's particularly 
> curious that 
> > > port randomization is not mentioned when tsvwg is working on it 
> > > (draft-ietf-tsvwg-port-randomization).
> >
> > Yes, you did raise this issue last time, but I did defer it 
> to the WG 
> > and did not receive any response, so I simply left it at that.
> 
> IIRC, both Joe and me had agreed on this one (yeah, we did :-) ).

Like I said earlier, I have no issues putting a reference to port
randomization document. Can you suggest a right place for this?
> 
> 
> 
> > > * Among the factors that determine how easy these attacks be 
> > > exploited is the window size. This document should 
> provide, at the 
> > > very least, pointers with advice on what to do with the 
> tcp window. 
> > > While quickly skimming through RFC 4953, it
> >
> > It does mentions about the window size relationship, For example in 
> > the beginning sections of the document we briefly mention 
> the window 
> > size and the # of packets that is required to generate a 
> successful attack.
> 
> What I mean is: you should not use windows that are larger 
> than necessary. Using larger windows than necessary doesn't 
> come for free (e.g., it increases the chances of an attacker 
> of successfully performing these attacks).

Provide advice on window sizes is deemed beyond the scope of this
document, IMO.

> 
> 
> > > * Yet another factor is TCP ISN randomization. At the very least, 
> > > this document could/should a pointer to RFC 1948. We do offer a 
> > > lengthy discussion of this and other issues in 
> > > draft-gont-tcp-security and 
> > > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
> >
> > Why should it talk about ISN randomization since ISN 
> randomization, is 
> > somewhat orthogonal to the type of attack here, it is not 
> even one of 
> > the attack vector.
> 
> If I can predict the ISN, I don't have to guess it. 
> Therefore, it's easier to successfully perform the attack.

Well, predicting ISN helps, but it really depends on how much volume of
data that got exchanged and the current sliding window snapshot (snduna
-- sndnxt) which really determines the acceptability of a segment.

> 
> 
> 
> > > * The counter-measure of for the SYN-based reset attack may have 
> > > missed a common heuristics for the handling of SYN segments. See 
> > > pages 86 and
> > > 87 of the UK CPNI paper on TCP security. FWIW, we argue that the 
> > > processing of SYN segments proposed in [Ramaiah et al, 
> 2008] should 
> > > apply only for connections in any of the synchronized 
> states other 
> > > than the TIME-WAIT state.
> >
> > We just followed RFC 793 as the base and the changes are made w.r.t 
> > that. TIME-WAIT may be an exception but doesn't RFC 793 already has 
> > that language correct?
> 
> Well, the timestamps was published *after* RFC 793. So RFC 
> imsply doesn't address this, because timestamps didn't exist 
> at the time.

Why are you bringing in timestamps, the huerisitic suggested by RFC 1122
applies *without* timestamps in place.

Just to be clear : The current mitigation *does* not preclude any host
to have the TIME-WAIT hueristic suggested as a MAY condition in RFC
1122. The scope of the document is to only change the language w.r.t
793.

That said, I'll leave it to the collective wisdom of the WG to comment
on this, if there is a strong consensus I don't issues to add some text.

> 
> 
> 
> > > * When it comes to TCP-based blind-connection reset 
> attacks, there's 
> > > a much more trivial -- yet not discussed before? -- 
> alternative. See 
> > > Section 11.1.3 and Section 11.1.4 in 
> draft-gont-tcp-security and the 
> > > CPNI paper 
> > > 
> (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf).
> > > These variants should, at the very least, be mentioned 
> and a pointer 
> > > provided to them as, at least in theory, are much easier 
> to exploit.
> >
> > Those sounds like some new proposals (security and precedence) 
> > different stacks would have taken different measures to 
> address this issue.
> > Anyways this is something new and hence needs more discussion and 
> > evaluation. Has these ideas been submitted in a draft to 
> TCPM? (your 
> > recent BCP document tcp-security, covers it ?)
> 
> Yes, the tcp-security I-D covers it. This stuff came as a 
> surprise while assessing RFC 793. One would expect that these 
> attacks don't work in practice--- but you never know. 
> However, IETF-wise they do...
> therefore I think it should be mentioned as another potential 
> connection-reset attack vector (*much* easier, as you don't 
> even have to guess the sequence number)

Like I said this document has been only taking about the 3 attacks from
the beginning when this document was out (5 years), I see no point in
delaying this document any further by adding new attacks without the
consensus of the WG.

Thanks,
-Anantha 

Gmane