Re: Question - Can DNSSEC be operated in a manner which meets Khaled mandates?

[Ted Ts'o]

On Wed, Jul 21, 2010 at 12:56:00PM -0700, todd glassey wrote:
>  Folks - there is a Court Ruling from the 4th Appellate District which
> is turning off Red Light Camera's everywhere and there is a question as
> to whether that ruling would also effect how Secure DNS Services are run
> and if so what would it do.
> 
> The ruling is called California v Khaled and is getting significant
> traction here in the State of California in all courts.

I'd suggest that the IETF mailing list is probably not the best place
to discuss whether or not a particular ruling regarding traffic
cameras might be applicable to Secure DNS services.  That's really
best done by a lawyer whom you have hired to represent you and your
specific interests.

I will note that one of the things begged by your rather opened-ended
question is an assumption about the goals of Secure DNS.  If it is
just to make it harder for DNS spoofing attacks to succeed, the answer
is probably nothing (but check with a lawyer if you want to be sure;
IANAL and I don't play one on TV).  If the goal is to establish a
binding between a DNS name and an IP address which is suitable to be
considered evidence in either a civil or criminal court of law, that's
a different question.

It's not clear to me that this latter goal is one that was considered
one of high importantance when the Secure DNS design was first
proposed --- or whether it's a goal that we should try to have now.
This is especially true since there are a huge number of legal
jourisdictions involved, and what might satisfy one appellate court
might not satisfy another.

Best regards,

- Ted
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Question - Can DNSSEC be operated in a manner which meets Khaled mandates?

[todd glassey]

 On 7/21/2010 8:12 PM, Phillip Hallam-Baker wrote:
> DNSSEC is not designed to address those particular issues.\
AMEN
> X.509v3 is designed to address them, or at least is capable of doing
> so if configured in the right way.
True - if its used correctly.
> Now the question I think we should consider is what is going to happen
> when all the people who read ICANN press releases that essentially
> tell them that DNSSEC is capable of serving these security needs start
> relying on the assumptions. 
They will see ICANN's commentary and simply bring suit in California
Court now that Khaled opens that can of worms where the IETF refused to
allow those issues to be resolved.  If the DNSSEC model doesnt pass
muster there it's toast and I think we all know what would happen...
> My strong belief is that the Internet needs one PKI not two and that
> we should start looking about how to use the combination of DNSSEC and
> X.509 so that we get the best from both. When people suggest using
> DNSSEC for the type of purposes that they have previously used self
> signed certs I do not get worried. But when they start suggesting
> using DNSSEC as a replacement for cases where you need non-repudiation
> or accountability, I get very worried.

So in Khaled is Redflex is trying to 'have the ruling unpublished'
claiming that they could have meet these requirements if they had been
given the chance, but the real issue here is whether the Court has an
obligation to hear claims about the process from third parties with a
financial interest in the matter.

Also Redflex was the party who captured that photo so it was aware of
the whole court process for that matter and chose not to attend. As such
it was Redflex's issue about not being there.

So assume DNSSEC is attacked in a California District Court as
'non-functional from an evidence perspective' which is something very
possibly and probable today.

You realize that Khaled affects all of the Businesses everywhere in the
4th District's sphere of influence and Jurisdiction?

>
> I would strongly suggest that anyone who is interested in the legal
> side of technology take a look at the case whether they consider it
> relevant to DNSSEC or not.
>
> http://www.thenewspaper.com/rlc/docs/2010/ca-khaled.pdf
>
> My reading of the case is that the appeals court knows that there are
> much better processes and technical means that could have been used to
> protect the chain of custody for the evidence in that case and they
> want to ensure that their concerns are urgently attended to.
Meaning if DNSSEC is flawed - there are now precedents which can be used
easily in California Courts to make DNSSEC a nightmare come true...

I think the application of the ruling is dead on which is why I posted
it and I am also sure it will seriously annoy many Sr. Professional IETF
Standards people since it totally rains on their parade but since they
refused to address these issues or even allow the discussion of these
issues long ago - the IETF is once again standing waste deep in its own
sh*t.

Sorry folks but reality is what it is and it that is that it's  law that
shapes technology not the reverse.

Todd
>
> On Wed, Jul 21, 2010 at 8:09 PM, todd glassey  wrote:
>>  On 7/21/2010 1:41 PM, Peter DeVries wrote:
>>> Todd, I just read the ruling on this and am confused as to why you
>>> would think this applies to DNSSEC rather than DNS (or other
>>> information systems).
>> Because I read the opinion and looked at what the idea of trustworthy
>> meant to the court. Something that is really really different than what
>> technical people think trustworthy meets.
>>> The reason this case was unable to proceed and
>>> the evidence was rejected seems to be because of the police handling
>>> of the system and witness.  The ruling specifically states that
>>> video/evidence capture devices are still admissible (See section II
>>> "analysis") as long as timeline and/or "reasonable representation of
>>> what it is alleged to portray." is available.
>> So then the time-service and sequence of events would need to be
>> provable... I totally get that.
>>> The problem is that the officer made available to the court had no
>>> firsthand knowledge of the incident, no understanding of the system,
>>> no knowledge of the time of information handling, and no internal
>>> knowledge of the development / testing of the system
>> Yep...
>>> Either this applies everywhere and DNSSEC is not unique or it applies
>>> nowhere as the data path will be further confirmed by
>>> administrator/operator knowledge.
>> Bingo - it applies everywhere. But the idea of DNSSEC being a solution
>> to the issue of evidence capture regarding any and all processes
>>> Can you explain in more detail with specific references as to how this
>>> applies to DNSSEC or IS systems as a whole.  I fail to see your
>>> concern.
>> It applies to everything that creates data which could come to be
>> reviewed by a court.
>>> Also, operations is separate from 

Re: Question - Can DNSSEC be operated in a manner which meets Khaled mandates?

[todd glassey]

 On 7/22/2010 7:25 AM, Ted Ts'o wrote:
> On Wed, Jul 21, 2010 at 12:56:00PM -0700, todd glassey wrote:
>>  Folks - there is a Court Ruling from the 4th Appellate District which
>> is turning off Red Light Camera's everywhere and there is a question as
>> to whether that ruling would also effect how Secure DNS Services are run
>> and if so what would it do.
>>
>> The ruling is called California v Khaled and is getting significant
>> traction here in the State of California in all courts.
> I'd suggest that the IETF mailing list is probably not the best place
> to discuss whether or not a particular ruling regarding traffic
> cameras might be applicable to Secure DNS services.  That's really
> best done by a lawyer whom you have hired to represent you and your
> specific interests.
>
> I will note that one of the things begged by your rather opened-ended
> question is an assumption about the goals of Secure DNS.  If it is
> just to make it harder for DNS spoofing attacks to succeed, the answer
> is probably nothing (but check with a lawyer if you want to be sure;
> IANAL and I don't play one on TV).  If the goal is to establish a
> binding between a DNS name and an IP address which is suitable to be
> considered evidence in either a civil or criminal court of law, that's
> a different question.
>
> It's not clear to me that this latter goal is one that was considered
> one of high importantance when the Secure DNS design was first
> proposed --- or whether it's a goal that we should try to have now.
> This is especially true since there are a huge number of legal
> jourisdictions involved, and what might satisfy one appellate court
> might not satisfy another.
>
> Best regards,
>
>   - Ted 

No offense Ted but this is exactly what I expect from you.

As it happens the reality is that the Use Model for DNSSEC which was in
fact set here in the IETF is critical to whether the DNSOP and DNSSEC
teams screwed the pooch by claiming that their secure DNS Service met
the legal requirements for evidence-systems operations. Or more
importantly - by intentionally and repeatedly refusing to review or meet
those in the design and operations-guidelines for the DNSSEC model which
is what many people said to that group formally

That you (or the management of the IETF and the DNSSEC initiative) would
try and duck around this now - that being their responsibility for that
set of decisions in the administrative and design process is yet another
reason the IETF needs much more transparency in its process  IMHO.

Todd Glassey



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: Re: Question - Can DNSSEC be operated in a manner which meets

[todd glassey]

 On 7/21/2010 8:07 PM, Martin Rex wrote:
> todd glassey wrote:
>>  On 7/21/2010 1:02 PM, Dan Schutzer wrote:
>>> Can you briefly explain the relationship of Red Light Camera's to
>>> DNSSEC?
>> What that means is any and all DNSSEC records operated out of a Root or
>> lower level system in the state of California who would operate under
>> these rules will need to meet the "legal definitions of trustworthy"
>> which are much different that those here I am betting.
> DNSSEC ist trust-free.
>
> As I previously said in this forum(*)
>
>   Anyone who thinks that information in the DNS could be trusted 
>   is either using a funny definition of trust or has no clue how 
>   DNS is actually used and what kind of data it contains (and 
>   how that data is created and maintained). 
>  
> Any discussion about new legal liabilities for information conveyed
> by DNSSEC will likely impede the further adoption of DNSSEC.
>
>
> -Martin
>
> (*) 
> https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=50326&tid=1279767429
>
Martin - since SAP's business is legally enforceable commerce are you
saying that there is no legal requirement for DNSSEC to return provable
content and if so where is the liability for it?

Todd Glassey

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Nomcom Enhancements: Improving the IETF leadership selection process

[Phillip Hallam-Baker]

I suspect I am not the only member of the Oxford Union Society here.

However for at least the last hundred years the society has had strict
rules against campaigning for office 'Rule 33' and a fairly elaborate
system of enforcement (the returning officer has ten deputies to
assist in observing and reporting breaches, there are tribunals etc.).

None of which has had the slightest impact. In fact the society is
generally considered a training ground for politicians precisely
because election to any office requires the use of a fairly
sophisticated political machine.



On Sun, Jul 18, 2010 at 11:27 AM, Yoav Nir  wrote:
> Hi Adrian
>
> It depends on the definition of politicking. In this, umm, draft, there's 
> this definition:
>
> "An organized campaign that seeks selection of a particular nominee"
>
> So you can't promote Dave all by yourself. You'll have to get a bunch of 
> people sending over-the-top opinions ("Dave will save the world as AD. 
> Electing him ensures a cure for cancer and world peace over IPv6"). It's this 
> organized effort that gets reported. It is then up to the NomCom to consider 
> this, just like any other piece of information. If they conclude that this is 
> an attempt to sabotage Dave's candidacy, they can choose to ignore it. OTOH 
> they can choose to wonder why Dave generates such animosity, that people go 
> to all this trouble.
>
> Of course, if they notice that a dozen people working for the same company 
> send in such opinions about Dave, they may choose to ignore all opinions from 
> that group.
>
> You may be right. This is looking more investigative than the NomCom can be 
> expected to do.
>
> Yoav
>
> On Jul 18, 2010, at 1:58 PM, Adrian Farrel wrote:
>
>> Hi Dave,
>>
>> I read the Summary
>> (http://www.bbiw.net/specifications/IETF-Nomcom-Process-Summary.html) -
>> timing being short at the moment. Looks mainly very good.
>>
>> In Section 5.2 I find...
>>
>>> RECOMMENDATION -- Politicking
>>> - Any evidence of politicking should be reported to Nomcom and should be
>>> treated as a significant, negative factor when considering the nominee who
>>>  is intended to benefit from the politicking.
>>
>> It may be that my mind is unnecessarily devious, but it seems to me that
>> this assumes that either no-one will execute a bluff, or that Nomcom will
>> detect it. That is, if I wish to ensure that Dave Crocker does not become
>> the next Foo Area Director, I could engineer a campaign of lobbying in his
>> support. According to your recommendation, this would have a significant
>> negative impact.
>>
>> IMHO, the actions of others have absolutely zero relevance to the competence
>> of an individual performing their IETF management tasks. NomCom should
>> consider only material facts (positive or negative) and should not be
>> distracted by any politicking or lobbying.
>>
>> I note that this is probably a simplistic statement since the line between
>> sending your fair and honest opinion that Dave would be good or bad as the
>> Foo AD can only truly be construed as not lobbying if you are entirely
>> unconcerned as to whether the final selection matches your own preferences
>> and opinions.
>>
>> It may also make a difference if it is the candidate who is organising or
>> instigating the lobbying on his own behalf. But determining this is likely
>> to require some form of court! So perhaps it is best to simply stick to the
>> candidates' competences, and to interviews advised by feedback from the
>> community.
>>
>> Cheers,
>> Adrian
>>
>>
>> - Original Message -
>> From: "Dave CROCKER" 
>> To: "IETF Discussion" 
>> Sent: Saturday, July 17, 2010 4:48 PM
>> Subject: Nomcom Enhancements: Improving the IETF leadership selection
>> process
>>
>>
>>> Folks,
>>>
>>> Nomcom has been an integral part of the IETF for nearly 20 years.
>>>
>>> A number of us have been developing a set of recommendations designed to
>>> adapt the Nomcom process to better match current realities of the IETF
>>> community.  The draft has progressed far enough to call for public
>>> consideration.
>>>
>>> Some of the proposal's recommendations require no changes in formal rules.
>>> They
>>> can be adopted immediately, possibly by the current Nomcom, should it so
>>> choose.
>>> Others require a formal development and approval cycle.
>>>
>>> At:
>>>
>>>     
>>>
>>> there is a copy of the Full Proposal, and a Summary which primarily
>>> contains just the recommendations.
>>>
>>>
>>> The proposal's Abstract is:
>>>
 Every year the IETF's Nominating Committee (Nomcom) reviews and selects
 half
 of the IETF's leadership on the IESG, IAB and IAOC/Trust. In the 18 years
 since the inception of the Nomcom process, the Internet industry and the
 IETF
 have gone through many changes in funding, participation and focus, but
 not
 in the basic formation, structure or operation of Nomcom. This paper
 explores
 challenges tha

Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

[Phillip Hallam-Baker]

On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews  wrote:
>
> In message , 
> Phil
> lip Hallam-Baker writes:
>> Being able to verify signatures is of no value.
>>
>> The system only has value when you can act differently according to
>> whether the signature verifies or not.
>>
>> I keep asking, but nobody will tell me how I get the keys for my
>> domains into the TLD.
>
> Firstly you get DS records into the TLD not DNSKEY records.  Secondly
> it is/will be by a mechanism similar to how you get NS records into
> the TLD.  In other words go ask your registrar when they are going
> to support adding DS records and stop complaining here.

I am not asking about the TLD keys, I am asking about my keys.

And I really hope that the mechanism for handling the name holder keys
recognizes that registering a million keys is different to
distributing a hundred where all the parties know each other
personally.

You would not be saying "go ask your registrar when they are going to
support adding DS records" if you didn't know that the answer was that
the registrars have made no commitment to deploy.

Holding a key signing ceremony is not a new technological achievement.
It is being held now with great fanfare in the hope that if everyone
makes enough noise about how much momentum DNSSEC has that the
opposition of the registrars will somehow disappear.

I don't see why that strategy would work. I have certainly never seen
it work in the past.


> This is not a technological problem.  It is a business problem
> between you, your registrar and the registry.

You are an engineer. If the technology does not meet the business
needs then you have failed.

If DNSSEC is not going to fail we need to re-engineer it to propose a
business model that actually works. Sitting on the sidelines and
shouting 'the technology is perfect damit, go make the business model
work', is not going to solve the problem. Nor is 'go away, my
technology is perfect, perfect I tell you'.

What has me very worried here are the comments to the effect 'the
registrars are behind'. What if the registrars are not 'behind', what
if they have no interest in deployment or are actively opposed but
unable to say so openly while Cerf and co are saying that DNSSEC is
the historic solution to solve the problem of Internet security?


>> This is not a trivial issue. There is a question of liability to be
>> addressed. So far ICANN and VeriSign Registry Services have addressed
>> the issue by booting it down the chain. But the system as a whole
>> cannot work until there is someone willing to accept the liability and
>> for that to happen they are going to require tools to manage their
>> litigation risk.
>
> How is the liability different from that of accepting NS records?
> DS records don't magically change the liability.  Stuffing up either
> NS or DS records will break the delegation.

Yes they do.

An NS record specifies the address of the DNS server

A DS record specifies an intermediate certificate in the chain of
trust for authenticating any entity that is attached to the domain.

In the case of an NS record it is established that the design does not
provide security in the DNS layer and this has to be provided
independently via an end to end mechanism such as SSL with DV or EV
certs.

In the case of a DS record the design is expressly designed to provide
for authentication of assertions relating to a domain name distributed
through the DNS.


-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [78attendees] wanted: your old NAT home router

[Yuchung Cheng]

Hi Lars,

This is very interesting study! it provides many useful information for the
TCP research at Google.

The queuing and processing delays on slide 12 (or figure 9 in the paper) are
mostly <50ms, but the following paper
"Characterizing residential broadband networks"  published in IMC 2007
measures much higher queuing length ranging from 100ms to a few secs (
http://portal.acm.org/citation.cfm?id=1298306.1298313 figure 13).

Any idea about the differences?

Thanks,

Yuchung

On Fri, Jul 9, 2010 at 12:15 AM, Lars Eggert  wrote:

> Hi,
>
> a quick status update. We now have received over 100 donated home gateways,
> plus a DSLAM. The students are on their summer break, after which we'll
> start running a significantly expanded set of tests over this much larger
> population of devices.
>
> Many of yo have donated boxes and suggested more experiments and better
> ways of performing our current tests - thank you!
>
> In case you are attending IETF-78 in Maastricht and would like to donate a
> home gateway, simply bring it. (Or contact me now for shipping details; no
> cost to you.)
>
> We're especially interested in devices from outside the EU and North
> America, or any other model we may not have yet (see
> http://fit.nokia.com/lars/tmp/2010-hgw-study-devices.txt). And we're still
> lacking a CMTS for testing cable modems...
>
> See you in Maastricht,
> Lars
>
> On 2010-6-2, at 18:36, Lars Eggert wrote:
> > Hi,
> >
> > FYI, a first report with test results for 34 devices is available at
> http://fit.nokia.com/lars/tmp/2010-hgw-study.pdf. Slides that summarize
> the results are at http://fit.nokia.com/lars/tmp/2010-hgw-study-slides.pdf
> .
> >
> > We have received another 30-odd devices as donations, which we'll add to
> the testbed and include in a follow-up study.
> >
> > If you have an unused, spare home gateway to donate to this effort,
> please contact us at nat-st...@fit.nokia.com. We're also interested in
> obtaining a DSLAM and a CMTS.
> >
> > Thanks,
> > Lars
> >
> > On 2010-4-29, at 12:34, Lars Eggert wrote:
> >> Hi,
> >>
> >> for a measurement study done together with Markku Kojo's team at the
> University of Helsinki, we're looking to collect as many different NAT home
> routers as possible. If you have an old clunker lying around somewhere,
> please contact me off-list. I'll cover shipping via DHL. Feel free to
> forward this email as you see fit.
> >>
> >> The boxes will find a permanent home at the University of Helsinki.
> Study results will be published openly. The intent is that this collection
> become a resource for the community to be shared for future studies.
> >>
> >> Caveat: The boxes should NAT between Ethernet interfaces - we don't have
> DSL or cable access equipment in the lab setup at the moment.
> >>
> >> Thanks,
> >> Lars
> >
>
>
> ___
> 78attendees mailing list
> 78attend...@ietf.org
> https://www.ietf.org/mailman/listinfo/78attendees
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08

[Ben Campbell]

Sorry for the late response--I just got back online after being out a few days 
for surgery.

Your response addresses my (final) concern.

Thanks!

Ben.

On Jul 16, 2010, at 9:29 AM, Bob Briscoe wrote:

> Ben,
> 
> At 20:47 14/07/2010, Ben Campbell wrote:
>> Thanks for the response. Further comments inline. (If I don't comment on a 
>> point, please take that to mean "okay" :-) )
>> 
>> On Jul 13, 2010, at 6:13 AM, Bob Briscoe wrote:
>> 
>>> Ben,
>>> 
>>> Thank you for your review comments from the GEN-ART perspective.
>>> 
>>> I think I have dealt with all your points in my responses, which are 
>>> inline...
>>> 
>>> There is just one outstanding question for you concerning updating 
>>> BCP4774...
>>> 
>>> At 22:23 01/07/2010, Ben Campbell wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 .
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-tsvwg-ecn-tunnel-08
 Reviewer: Ben Campbell
 Review Date: 2010-07-01
 IETF LC End Date: 2010-07-06
 IESG Telechat date: (if known)
 
 Summary:
 
 This draft is almost ready for publication as a proposed standard. I have 
 a couple of procedural questions that should be considered first, as well 
 as a few editorial comments.
 
 Major Issues: None.
 
 Minor Issues:
 
 -- RFC Editor request (immediately after ToC): "In the RFC index, RFC3168 
 should be identified as an update to RFC2003.
 RFC4301 should be identified as an update to RFC3168."
 
 This seems odd. I assume the intent is that this draft says that things 
 from 3168 should be applied to 2003, therefore updating 2003, etc? If so, 
 wouldn't it be more correct to say that _this_ draft updates 2003 and 3168?
>>> 
>>> Quoting from the RFC Index:
>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>>> Updates  refers to other RFCs that this one merely updates but
>>> does not replace); ...
>>> Generally, only immediately succeeding
>>> and/or preceding RFCs are indicated, not the entire history of each
>>> related earlier or later RFC in a related series.
>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>>> The consensus on the TSVWG list was that the updates should be identified 
>>> in the RFC Index as follows
>>> 2003 -> 3168 -> ecn-tunnel
>>> 3168 -> 4301 -> ecn-tunnel
>>> 
>>> In the headers of this draft we have said:
>>> Updates: 3168, 4301
>>> 
>>> But we also noticed that the RFC Index incorrectly omits to identify that 
>>> these RFCs in turn already update the earlier RFCs. The note to the RFC 
>>> Editor was the result of this consensus request from the TSVWG list.
>>> 
>>> [BTW, There is nonetheless text on backward compatibility between this I-D 
>>> and these early RFCs in Section 6. And "Appendix A; Early ECN Tunnelling 
>>> RFCs" explains the interactions.]
>>> 
>>> Summary: I propose no change on this point.
>> 
>> It's not entirely clear to me how the RFC index quote supports the argument 
>> one way or another. I was not proposing we needed to maintain the entire 
>> history of updates.
>> 
>> Was the work group consensus that 3168 _already_ updated 2003 (i.e. the 
>> original intent of 3618 was to update 2003), and the notation of that fact 
>> was simply missing? Or that it _should_have_ updated 2003 but did not? If 
>> the first, then I agree with the proposed approach. But if the second, then 
>> I think you have a case of _this_ draft updating 2003 by calling out text in 
>> 3618 that should now apply to it.
> 
> The first.
> 
> Even though section 9 of RFC3168 on updates to tunnel processing
> 
> contained two parallel subsections (9.1 & 9.2) on respectively IP in IP 
> tunnels referencing 2003 and IPsec tunnels referencing 2401 (IPsec), it only 
> included 2401 in the "Updates" header. There can be no other explanation than 
> simple error for omitting "Updates 2003".
> 
> 
>> In particular, does 3168 contain text on how it updates 2003? Could someone 
>> understand how 3168 applies to 2003 by reading that document alone?
> 
> Yes
> 
>> Or does that text reside in this draft?
> 
> No
> 
> 
>> In any case, if you still believe it should stand as is, I will not push the 
>> point further. If the IESG is okay with the approach, then it's fine with me.
> 
> I guess I ought to submit an erratum for RFC3168 and RFC4301 at the same 
> time, in order to add these two "Updates" headers.
> 
> 
> 
> 
>>> 
>>> 
 -- 7, first paragraph: "The guidance below extends RFC4774, giving 
 additional guidance on designing any alternate ECN semantics
 that would also require alternate tunnelling semantics."
 
 Should this draft be listed as updating 4774? Also, you've declared th

Re: Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08

[Bob Briscoe]

Ben,

Tx for the review and follow-up.
I've added you to the acks in the rev of the 
draft I plan to post shortly, which takes account 
of comments from you & some minor editorial 
comments off list during IETF last call.


Over & Out.
Cheers


Bob

At 21:41 20/07/2010, Ben Campbell wrote:
Sorry for the late response--I just got back 
online after being out a few days for surgery.


Your response addresses my (final) concern.

Thanks!

Ben.

On Jul 16, 2010, at 9:29 AM, Bob Briscoe wrote:

> Ben,
>
> At 20:47 14/07/2010, Ben Campbell wrote:
>> Thanks for the response. Further comments 
inline. (If I don't comment on a point, please take that to mean "okay" :-) )

>>
>> On Jul 13, 2010, at 6:13 AM, Bob Briscoe wrote:
>>
>>> Ben,
>>>
>>> Thank you for your review comments from the GEN-ART perspective.
>>>
>>> I think I have dealt with all your points 
in my responses, which are inline...

>>>
>>> There is just one outstanding question for 
you concerning updating BCP4774...

>>>
>>> At 22:23 01/07/2010, Ben Campbell wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 .

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-tsvwg-ecn-tunnel-08
 Reviewer: Ben Campbell
 Review Date: 2010-07-01
 IETF LC End Date: 2010-07-06
 IESG Telechat date: (if known)

 Summary:

 This draft is almost ready for publication 
as a proposed standard. I have a couple of 
procedural questions that should be considered 
first, as well as a few editorial comments.


 Major Issues: None.

 Minor Issues:

 -- RFC Editor request (immediately after 
ToC): "In the RFC index, RFC3168 should be identified as an update to RFC2003.

 RFC4301 should be identified as an update to RFC3168."

 This seems odd. I assume the intent is 
that this draft says that things from 3168 
should be applied to 2003, therefore updating 
2003, etc? If so, wouldn't it be more correct 
to say that _this_ draft updates 2003 and 3168?

>>>
>>> Quoting from the RFC Index:
>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>>> Updates  refers to other RFCs that this one merely updates but
>>> does not replace); ...
>>> Generally, only immediately succeeding
>>> and/or preceding RFCs are indicated, not the entire history of each
>>> related earlier or later RFC in a related series.
>>> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>>> The consensus on the TSVWG list was that 
the updates should be identified in the RFC Index as follows

>>> 2003 -> 3168 -> ecn-tunnel
>>> 3168 -> 4301 -> ecn-tunnel
>>>
>>> In the headers of this draft we have said:
>>> Updates: 3168, 4301
>>>
>>> But we also noticed that the RFC Index 
incorrectly omits to identify that these RFCs 
in turn already update the earlier RFCs. The 
note to the RFC Editor was the result of this 
consensus request from the TSVWG list.

>>>
>>> [BTW, There is nonetheless text on backward 
compatibility between this I-D and these early 
RFCs in Section 6. And "Appendix A; Early ECN 
Tunnelling RFCs" explains the interactions.]

>>>
>>> Summary: I propose no change on this point.
>>
>> It's not entirely clear to me how the RFC 
index quote supports the argument one way or 
another. I was not proposing we needed to 
maintain the entire history of updates.

>>
>> Was the work group consensus that 3168 
_already_ updated 2003 (i.e. the original 
intent of 3618 was to update 2003), and the 
notation of that fact was simply missing? Or 
that it _should_have_ updated 2003 but did not? 
If the first, then I agree with the proposed 
approach. But if the second, then I think you 
have a case of _this_ draft updating 2003 by 
calling out text in 3618 that should now apply to it.

>
> The first.
>
> Even though section 9 of RFC3168 on updates to tunnel processing
> 
> contained two parallel subsections (9.1 & 
9.2) on respectively IP in IP tunnels 
referencing 2003 and IPsec tunnels referencing 
2401 (IPsec), it only included 2401 in the 
"Updates" header. There can be no other 
explanation than simple error for omitting "Updates 2003".

>
>
>> In particular, does 3168 contain text on how 
it updates 2003? Could someone understand how 
3168 applies to 2003 by reading that document alone?

>
> Yes
>
>> Or does that text reside in this draft?
>
> No
>
>
>> In any case, if you still believe it should 
stand as is, I will not push the point further. 
If the IESG is okay with the approach, then it's fine with me.

>
> I guess I ought to submit an erratum for 
RFC3168 and RFC4301 at the same time, in order 
to add these two "Updates" headers.

>
>
>
>
>>>
>>>
 -- 7, first paragraph: "The guidance below 
extends RFC4774, giving additional guid

Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

[Phillip Hallam-Baker]

Quite, and completely eliminate the risk of a DDoS attack on the root servers.

Very easy today when the root file is 200 nodes. But what is it going
to be like after ICANN has managed to sell TLDs to everyone in the
F500 and so on?

Might be some interesting fireworks there as 'non-profit' ICANN
charges $50,000 per application but the root zone operators are
unpaid. Nice little earner that. Trebles and pay rises all round.

Beckstrom is at least a serious contender for whom the ICANN money
might be considered a competitive salary. The same could not be said
of his predecessor with a straight face.


On Wed, Jul 21, 2010 at 4:08 AM, Iljitsch van Beijnum
 wrote:
> On 21 jul 2010, at 5:27, Mark Andrews wrote:
>
>> The only keys that have to be widely distributed are those for the
>> root zone and that's a similar problem to distributing the list of
>> root nameservers and their addresses.  Millions of recursives server
>> operators have managed that.
>
> Would be great if the list of root servers and list of trusted root 
> certificates could be distributed in one easy to install file...



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

[Phillip Hallam-Baker]

Mark,

If you didn't know I was right you would have addressed my actual
argument rather than look for idiotic technical details that have no
bearing on the issue itself.

Yes, I know what a DS record is technically, and you know that I know.
And you know that as far as liability is concerned putting a DS record
in there is going to provide the location of a server, albeit by
reference.

Now I worked in the practices section of a major CA at the time that
it was being established. I saw the development of the risk and
liability mitigation strategy being developed first hand. I had
frequent discussions on the matter with Michael Baum who was leading
the effort.

The expertise you are quibbling over can be found in a O'Rielly
nutshell handbook. You are not quibbling to elucidate the issue, you
are quibbling in the hope that by demonstrating I got something
'wrong' that you can ignore the issues that I am raising. Looking
through your post I cannot see how you could be confused in the manner
you purport to be confused.

If there is going to be an unbroken chain of trust then at some point
there has to be a point where the registry signs the domain owner key
and it is damned obvious that that is the potential weak link in the
chain. I don't want to be more specific that that because I know from
previous interactions that if I try to be precise the response will be
to try to distract with irrelevant nitpicking.


What is worrying me is that if the liability issues had actually been
considered, the answer to how my keys get into the domain would be 'go
read document X.' because it really isn't possible to do the liability
analysis on 'that will work the same way as it happens today'.

It is very easy for the large registrars to sign the DNS zones for the
servers they operate in house. It is not easy for the zones operated
locally - which are the ones that people are most likely to want to
DNSSEC.

And before I place any reliance on this contraption, I want to know
the full process by which the keys get into the domain and how each
link in that process is secured. Because it would be rather sad if I
spend time signing my zone and the link between the registrar and the
registry is secured by the type of password an idiot would have on his
luggage.

If any registrar can validate keys in any zone in any way they please
then that means that there really isn't any security here at all. I
might think I am going to microsoft.com but mcolo registrar may have
just  hijacked the domain. Yes I know about domain locking, but I want
to know what controls are in place to put it into effect.


This avoidance of difficult questions is precisely the reason it has
taken fifteen years to get to this point and the reason I do not have
any confidence in DNSSEC being usable in the next ten. The same people
responded in the same way when I brought up the NXT record issue and
then we went through the same thing again with the EU privacy laws.

Every time the response is to try to beat down any question.

If my questions seem vague it is because they are about the real world
and that is rather vague.


On Tue, Jul 20, 2010 at 11:27 PM, Mark Andrews  wrote:
>
> In message , 
> Phil
> lip Hallam-Baker writes:
>> On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews  wrote:
>> >
>> > In message =
>> , Phil
>> > lip Hallam-Baker writes:
>> >> Being able to verify signatures is of no value.
>> >>
>> >> The system only has value when you can act differently according to
>> >> whether the signature verifies or not.
>> >>
>> >> I keep asking, but nobody will tell me how I get the keys for my
>> >> domains into the TLD.
>> >
>> > Firstly you get DS records into the TLD not DNSKEY records.  Secondly
>> > it is/will be by a mechanism similar to how you get NS records into
>> > the TLD.  In other words go ask your registrar when they are going
>> > to support adding DS records and stop complaining here.
>>
>> I am not asking about the TLD keys, I am asking about my keys.
>
> I will repeat myself.  The parent zone has DS records added to it
> not DNSKEY records.  Your keys are added to your zone so I presume
> you know how to update your zones.
>
>> And I really hope that the mechanism for handling the name holder keys
>> recognizes that registering a million keys is different to
>> distributing a hundred where all the parties know each other
>> personally.
>
> Well you know your parent or its agent (registrar).  You hand the
> DS to them to publish.  The rest of the world gets the DS from them.
> The only keys that have to be widely distributed are those for the
> root zone and that's a similar problem to distributing the list of
> root nameservers and their addresses.  Millions of recursives server
> operators have managed that.
>
>> You would not be saying "go ask your registrar when they are going to
>> support adding DS records" if you didn't know that the answer was that
>> the registrars have made no commitment to deploy.
>
> Well pick one that does.

Re: IETF privacy policy - still a bad idea

[Phillip Hallam-Baker]

My memory of partnership law is that if an agreement has the form of a
partnership it is a partnership regardless of claims in the contract
document explicitly stating it is not. It does not seem very likely
that the courts would take a different line with respect to
organizations that claim not to be organizations.

There may be some ambiguity as to what the status of the IETF is, but
that does not help.

Exceptionalism really does not work very well as a legal strategy.

On Wed, Jul 21, 2010 at 6:33 PM, John Levine  wrote:
>>You appear to be concerned about exposing the IETF to risk by the
>>adoption of a privacy policy (but apologies if I am misunderstanding
>>the concern you expressed).  The absence of a privacy policy, however,
>>actually increases risk to the IETF in at least three ways:
>
>  ... none of which applies since
>
> a) the IETF has no formal legal existence
> b) the IETF has no employees
> c) the IETF signs no contracts
>
> It would be helpful for someone, anyone, to explain in terms specific
> to the IETF what a privacy policy will accomplish.  Please be sure to
> make no references whatsoever to any other organization, since none of
> them are (un)organized like the IETF is.  While you're at it, be sure
> not to use the word "obvious" or its synonyms.
>
> I could be persuaded that there is a reason to have a privacy policy,
> but everything I've seen so far has been a combination of faulty
> analogies and mistaken premises.
>
> R's,
> John
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF privacy policy - still a bad idea

[Phillip Hallam-Baker]

On Wed, Jul 21, 2010 at 8:10 PM, Dave CROCKER  wrote:
>
>
> On 7/21/2010 3:33 PM, John Levine wrote:
>>>
>>> You appear to be concerned about exposing the IETF to risk by the
>>> adoption of a privacy policy (but apologies if I am misunderstanding
>>> the concern you expressed).  The absence of a privacy policy, however,
>>> actually increases risk to the IETF in at least three ways:
>>
>>  ... none of which applies since
>>
>> a) the IETF has no formal legal existence
>
> With creation of the IETF Trust, that is no longer true.  There also have
> been comments from one or another attorney that the absence of formal legal
> formation is not the same as no "formal" legal existence.  All of which at
> least suggests, once again, that we ought to leave legal pronouncements to
> attorneys (and even then, seek a second opinion.)

Especially when what is being suggested is an exception to the normal
case. In general, the more different a legal situation is, the more
important it is to take regular and specific legal advice.

A => B does not mean that !A => !B.

That is called denying the antecedent.


-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!

[Phillip Hallam-Baker]

What Mark is saying here is that DNSSEC is not designed to provide
very much security and so does not need to be very secure.

What I am saying is that people are already assuming that DNSSEC
provides a very much higher standard of security and that this is
going to lead to new security failures. Remember that an initial
response to the Kaminsky attack from at least one vendor was that DNS
was designed to be vulnerable to cache poisoning.


I see three options

1) Cancel DNSSEC

Not happening, move on.

2) Educate people so that they understand exactly what security DNSSEC
is going to provide.

Good luck with that one. People will do silly things, ignore all the
warning labels and then blame the protocol. There is a real risk that
some will sue. And telling people that DNSSEC is not going to secure
the Internet is not going to be very easy while Vint Cerf is out there
telling people that it is.

3) Design a DNSSEC 2.0 that meets the expectations.

Which is I think a lot easier than it may appear.


On Wed, Jul 21, 2010 at 9:04 PM, Masataka Ohta
 wrote:
> Mark Andrews wrote:
>
>>> If there is going to be an unbroken chain of trust then at some point
>>> there has to be a point where the registry signs the domain owner key
>>> and it is damned obvious that that is the potential weak link in the
>>> chain. I don't want to be more specific that that because I know from
>>> previous interactions that if I try to be precise the response will be
>>> to try to distract with irrelevant nitpicking.
>
> Any chain is breakable by MitM attacks on its intermediate links.
>
>> Yes adding data to the parent zone requires secure authenticated
>> communication.  DS however are no diffent to NS.  Both require the
>> same level of authentication.  Yes it is subject to potential social
>> engineering attacks.
>
> That's how DNSSEC is not secure end to end and only as secure as
> plain old DNS (assuming both are properly implemented, though
> proper implementation of DNSSEC should be a lot more complex
> and, thus, difficult, if not impossible, than plain old DNS).
>
> The end to end security can be established only by sharing a security
> information directly and securely by ends without any intermediate
> entities such as CAs.
>
>                                                Masataka Ohta
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Question - Can DNSSEC be operated in a manner which meets Khaled mandates?

[Phillip Hallam-Baker]

DNSSEC is not designed to address those particular issues.

X.509v3 is designed to address them, or at least is capable of doing
so if configured in the right way.

Now the question I think we should consider is what is going to happen
when all the people who read ICANN press releases that essentially
tell them that DNSSEC is capable of serving these security needs start
relying on the assumptions.

My strong belief is that the Internet needs one PKI not two and that
we should start looking about how to use the combination of DNSSEC and
X.509 so that we get the best from both. When people suggest using
DNSSEC for the type of purposes that they have previously used self
signed certs I do not get worried. But when they start suggesting
using DNSSEC as a replacement for cases where you need non-repudiation
or accountability, I get very worried.


I would strongly suggest that anyone who is interested in the legal
side of technology take a look at the case whether they consider it
relevant to DNSSEC or not.

http://www.thenewspaper.com/rlc/docs/2010/ca-khaled.pdf

My reading of the case is that the appeals court knows that there are
much better processes and technical means that could have been used to
protect the chain of custody for the evidence in that case and they
want to ensure that their concerns are urgently attended to.


On Wed, Jul 21, 2010 at 8:09 PM, todd glassey  wrote:
>  On 7/21/2010 1:41 PM, Peter DeVries wrote:
>> Todd, I just read the ruling on this and am confused as to why you
>> would think this applies to DNSSEC rather than DNS (or other
>> information systems).
> Because I read the opinion and looked at what the idea of trustworthy
> meant to the court. Something that is really really different than what
> technical people think trustworthy meets.
>> The reason this case was unable to proceed and
>> the evidence was rejected seems to be because of the police handling
>> of the system and witness.  The ruling specifically states that
>> video/evidence capture devices are still admissible (See section II
>> "analysis") as long as timeline and/or "reasonable representation of
>> what it is alleged to portray." is available.
> So then the time-service and sequence of events would need to be
> provable... I totally get that.
>> The problem is that the officer made available to the court had no
>> firsthand knowledge of the incident, no understanding of the system,
>> no knowledge of the time of information handling, and no internal
>> knowledge of the development / testing of the system
> Yep...
>> Either this applies everywhere and DNSSEC is not unique or it applies
>> nowhere as the data path will be further confirmed by
>> administrator/operator knowledge.
> Bingo - it applies everywhere. But the idea of DNSSEC being a solution
> to the issue of evidence capture regarding any and all processes
>> Can you explain in more detail with specific references as to how this
>> applies to DNSSEC or IS systems as a whole.  I fail to see your
>> concern.
> It applies to everything that creates data which could come to be
> reviewed by a court.
>> Also, operations is separate from prosecution.  DNSSEC has
>> other purposes than prosecution and can most certainly be operated
>> within this ruling.  I don't personally see issues with prosecution as
>> long as the witnesses understand and explain how the situation was
>> handled.
> The problem is the integrity of the data model and whether it produces
>> BTW, the appeals case number I read is: 30-2009-00304893.  Please let
>> me know if there is another case you are referencing.
>
> No that's it.
>> Peter
>>
>> On Wed, Jul 21, 2010 at 3:56 PM, todd glassey  wrote:
>>>  Folks - there is a Court Ruling from the 4th Appellate District which
>>> is turning off Red Light Camera's everywhere and there is a question as
>>> to whether that ruling would also effect how Secure DNS Services are run
>>> and if so what would it do.
>>>
>>> The ruling is called California v Khaled and is getting significant
>>> traction here in the State of California in all courts.
>>>
>>> Todd
>>>
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Question - Can DNSSEC be operated in a manner which meets Khaled mandates?

[Masataka Ohta]

Ted Ts'o wrote:

> If the goal is to establish a
> binding between a DNS name and an IP address which is suitable to be
> considered evidence in either a civil or criminal court of law, that's
> a different question.
> 
> It's not clear to me that this latter goal is one that was considered
> one of high importantance when the Secure DNS design was first
> proposed ---

In "DNSSEC History, Status, Future" by Steve Crocker

http://www.internetdagarna.se/arkiv/2008/www.internetdagarna.se/images/stories/pdf/domannamn/Steve_Crocker_administrationofdnssec.pdf

it is stated on page 6 that:

Where Does DNSSEC Come In?
  DNSSEC secures the name to address mapping
Transport and Application security are just other layers.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Wallet theft in Brussels train station

[Michael Dillon]

> One moment of inattentiveness while putting my roller bag up in the over
> seating racks on the train from Brussels to Aachen (where I am for a
> pre-IETF meeting).  And they were middle-age men.

This is likely a common style of picking pockets. I ran across it in Simferopol,
Ukraine upon entering a bus to the coast, at the train station. In this case it
was rather obvious because the pair were loitering by the bus and when my
wife and I decided to enter, one of them went in the rear door and went forward
while the other followed me. I just cursed at them in Russian and they
eventually
gave up.

Thinking it over, even if you are very attentive at watching your surroundings,
when boarding transport your attention tends to be fully focused ahead of
you and you also expect people to be right behind. Since then, if
there is someone
behind me on an airplane or train, I put my luggage on the seat, then turn
180 degrees and leave the aisle until it is clear again. Then I go for the
overhead bins.

You may find this to be a useful protocol as well.

--Michael Dillon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: Re: Question - Can DNSSEC be operated in a manner which

[Martin Rex]

todd glassey wrote:
> 
> Martin - since SAP's business is legally enforceable commerce are you
> saying that there is no legal requirement for DNSSEC to return provable
> content and if so where is the liability for it?

If the delivery of your yellow press subscription switches from
your neighborhood newsboy to a security service company delivering
in an armoured van, does that make the *contents* of your yellow press
subscription any more trustworthy?

Nope, it doesn't.  It only makes the delivery more trustworthy,
but does not affect the contents at all.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC review of draft-baker-v6ops-greynet-04.tx

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-baker-v6ops-greynet-04.tx
Reviewer: Ben Campbell
Review Date: 2010-07-22
IETF LC End Date: 2010-08-06 (Wow, I'm early for a change!)
IESG Telechat date: unknown

Summary: This draft is ready for publication as an informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- Section 1, last paragraph, last sentence:

What's the antecedent for "them"? I think it's "analytic methods", or maybe 
"attacks", but I'm not sure.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of messages in the last 7 days.
 
script run at: Fri Jul 23 00:53:01 EDT 2010
 
Messages   |  Bytes| Who
+--++--+
+--++--+

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf