Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

for core protocols, and I guess it would work here, too. Fixing the protocol is desirable, but there's still a backup plan. Let's not pretend otherwise. 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-

Re: Most bogus news story of the week

* Stephane Bortzmeyer: > "Today, Internet is completely rotten", says Jacques Myard. "We have > to nationalize this network, as the Chinese did." FWIW, Germany has got an established legal framework for covert keyword-based screening on all international data

Re: Most bogus news story of the week

* Richard L. Barnes: > Is this disingenuous or has the ITU really not heard of netflow? I can understand if people are not too happy with best-effort accounting and billing. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100

Re: Stub DNSSec Resolution, Or Use DNSScurve

* Tony Finch: >> And why aren't stub resolvers being encouraged to do their own DNSSec >> validation? > > It's very slow if you don't have a cache. Note that most stubs actually have a cache these days, so I don't think this is a major architectural issue.

Re: DNSCurve vs. DNSSEC - FIGHT!

the expectation is that you learn the server names (and hence their keys) of child zones from parents, under DNSCurve's cryptographic protection. This is slightly different from plain DH. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 1

Re: DNSCurve vs. DNSSEC - FIGHT!

* Masataka Ohta: > Florian Weimer wrote: > >>>As DNSCurve protection is like DH, it is subject to MitM attacks, >>>which is no different from simple nonce. > >> I think the expectation is that you learn the server names (and hence >> their keys) of chi

Error in Security Considerations in an RFC

I've come across a RFC which basically says, "in order to do X safely, perform checks Y before you do X". It turns out that it's possible to evade those checks. What should I do about it? I've already contacted the author, and he says that no update to the RFC is planned. Should i just file an

Rationale for public, non-subscribable mailing lists

I've recently tried to subscribe to the SECDIR list. Apparently, this list is public (it's archived on the web), but one cannot subscribe to it. The question is: Why would anyone configure things this way? It's really, really odd. (It was suggested to me that I posted something to the SECDIR li

Re: Rationale for public, non-subscribable mailing lists

* Brian E. Carpenter: > Because IETF teams should operate in public view as much as possible, > and particularly teams whose main job is document review. But by > simple logic, only team *members* will actually be on the list. Okay, you're using Mailman to administrate team membership. Let me sa

Re: Rationale for public, non-subscribable mailing lists

* Arnt Gulbrandsen: > Florian Weimer writes: >> Okay, you're using Mailman to administrate team membership. Let me >> say that I think this is a bit bizarre, but it's some sort of >> technical reason. (Other organizations keep team rosters and >> mailingli

Re: Is this true?

* Brian E. Carpenter: > the basic model for IPv6 is not fundamentally different than IPv4; > why would the underlying security vulnerabilities be fundamentally > different? Lack of NAT and an expectation of end-to-end reachability seem quite fundamentally different from IPv4 as it is deployed to

Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?

erent: usage caps exceptions for content where the content hoster and the ISP have reached an ad-sharing deal. QoS rarely works in practice because no two organizations or departments can agree on a common set of parameters.) -- Florian Weimer BFK edv-consulting GmbH

Re: Wikipedia

* Marshall Eubanks: > The problem I have with this is not the content (presumably the > author of the I-D is vouching for any references they use), it's > that the content can change at any time. I think that's why you're supposed to add a retrieved date to your citat

Re: Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard

the terminology of the BSD sockets API). This is not always desirable or possible. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 __

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

* Stephane Bortzmeyer: > Second question, the document indeed standardizes many things which > are not in common use but does not point towards a rationale, so some > choices are puzzling. Why TXT records to point to an URL and not > NAPTR? Is this because of current usage in DNSxL? If so, this sh

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

* Mark Andrews: > In message <[EMAIL PROTECTED]>, Florian Weimer writes: >> * Stephane Bortzmeyer: >> >> > Second question, the document indeed standardizes many things which >> > are not in common use but does not point towards a rationale, so some >&g

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

* Mark Andrews: >> >> The lack of a macro capability also means that it's basically >> >> impossible to secure DNSBL zones with DNSSEC when they contain larger >> >> chunks of address space; see the example in section 2.1. >> > >> >How so? >> >> The expectation is that error messages generate

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

* Chris Lewis: > Florian Weimer wrote: > >> The expectation is that error messages generated from TXT records >> contain the actual IP addresses which triggered the DNSBL lookups. As >> a result, if you list a /16 (say), you need publish 65,536 different >> TXT re

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

* Mark Andrews: >> I didn't say it was a DNSSEC problem. I just wanted to note it's >> impossible to secure some existing DNSBL zones using DNSSEC without >> sacrificing some of the functionality which is mentioned in section >> 2.1 in the draft. > > I still don't believe your claim. I can

Re: sockets vs. fds

* Tony Finch: > On Fri, 5 Dec 2008, Dave CROCKER wrote: >> Melinda Shore wrote: >> > >> > Not to go too far afield, but I think there's consensus among us old >> > Unix folk that the mistake that CSRG made wasn't in the use of >> > addresses but in having "sockets" instead of using file descriptor

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

IPv6-related WGs. I don't know how far this effort has evolved. There does not seem to be a way to address the IPv4 part of the issue indepedently. So right now it seems that the IETF is structurally incapable of correcting this badly engineered specification. -- Florian Weimer

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

is correct. It is compliant with the rest of the protocol zoo, but the order of records, as seen by applications, is no longer undefined. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fa

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

ing, server loads change in ways the operator cannot influence (except by requesting addresses with certain bit patterns, but I don't think anybody wants vanity IP addresses). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +

Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems

o deal with the Rule 9 fallout is to put all your servers into a dedicated prefix, but I don't think this is a good idea in general.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Ka

Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems

good idea, why are most large web sites served this way? I suspect there is currently no better way to distribute initial client requests than to play DNS tricks. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-9620

Re: Status of the 16-bit AS Number space

* Steve Crocker: > I strongly advise against quick reallocation of returned AS numbers. > Returned AS numbers should stay out of service for a substantial > period of time. Why? It seems to be consensus among operators that it's fine to use other people's ASNs in the global routing table, so suc

Re: Status of the 16-bit AS Number space

* Bill Manning: >> The question is why there should be moratorium on returned ASNs. I can >> think of one reason that could be of dis-service to a new assignee, but >> all we have so far is handwaving from the proponents. >> ___ > > a thought experimen

Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end

* Joe Baptista: > DNSCurve encrypts all DNS packets. Ahem, this part of the protocol has not been specified so far. Encryption is not mentioned on the dnscurve.org pages, only key exchange, and even that is not fully disclosed. ___ Ietf mailing list Iet

Re: End to End Secure Protocols are bogus.

* Phillip Hallam-Baker: > Now I have serious reservations about the design of DNSSEC. The > current design would establish the root key holder as the perpetual > controller of the DNS. The browser PKI shows that root key material can change hands, so I don't see what's perpetual about it. It's n

Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end

* Phillip Hallam-Baker: > OK, how do you do that if the ICANN root is baked into your broadband > router? How about a light switch? Nowadays, there are software update protocols for broadband routers, too. > You can change the signing key, but distributing and embedding the > verification key is

Re: End to End Secure Protocols are bogus.

* Ralf Weber: >> Wrong. The majority of resolvers are maintained by Microsoft. >> Microsoft could ship the KSK for the root to customer machines in a >> security update. As it happens, in this case, the KSK wouldn't even >> be the penultimate key, showing that the debate over who holds the KSK >

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

R statements. Anyway, those who object to the ECC infection should strive to remove it from the base TLS spec. It doesn't make sense to rehash this discussion over and over again, for each draft produced by the WG which happens to be compatible with ECC algorithms and for which Certicom f

Re: why can't IETF emulate IEEE on this point?

* Paul Vixie: > in , we see: > > Letters of Assurance are requested from all parties > holding patents which may be applicable to any IEEE > standard. Basically they state that the patent owne

Re: why can't IETF emulate IEEE on this point?

* Paul Vixie: > very clear, very well done, but if anything it adds to my list of questions > rather than subtracting from that, since it begs the question, what is the > objective definition of "reasonable and nondiscriminatory"? Any terms that prevent courts from granting compulsory patent lice

Re: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]

* michael dillon: > Is TCP/UDP the right place which we should try to reinforce, or > should we instead try to move it back down to IP as version 6 > becomes more widely deployed? The prevailing assumption is that IPv6 end nodes will be globally addressable for practical purporses. I think this

Re: IPv6 NAT?

* Iljitsch van Beijnum: > On 14 feb 2008, at 21:49, Florian Weimer wrote: > >> The prevailing assumption is that IPv6 end nodes will be globally >> addressable for practical purporses. I think this is a very unlikely >> outcome. > > Are you saying that there will be

Re: IPv6 NAT?

> 2. that all end nodes will 'automagically' be able to be reached through > the IPv6 routing and routed protocols. > > Obviously #2 is sound But it's not what will happen on the Internet. Protocol development needs to take that into account. ___ Ietf

Re: IPv6 will never fly: ARIN continues to kill it

* Mark Andrews: > Except there really is no vendor lock anymore. It is > possible to automate the entire renumbering process. If > there are spots where it is not automated then they should > be found and fixed. It's not possible to automatically renumber firewall config

Re: IPv6 will never fly: ARIN continues to kill it

* Mark Andrews: >> It's not possible to automatically renumber firewall configurations in >> different administration domains (quite deliberately so), and you >> can't take your mail reputation with you (at least not completely). > > Actually it is. You just are not willing to do it. Our c

Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

[EMAIL PROTECTED] writes: > The general consensus as I read it was that the christey-wysopal draft was > generally considered a very good and reasonable document. There was quite a bit rejection, and some very profound criticism (the killer argument, IMHO, is that a large part of the industry doe

Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

Chris Wysopal <[EMAIL PROTECTED]> writes: > I was not aware of the paid prepublication access that some > coordinators provide at the time the draft was written. I don't know > if Steve knew this. This was an new concept at the time. I have heard > that CERT is willing to keep researcher submiss

RFC authoring tools

Are there any tools which can produce documents in standard RFC format from high-level markup? These feature are required: - source format is human-readable ASCII (with embedded markup) - high-level, non-visual markup - libre conversion software to RFC format - automatic generation of cross r

Re: RFC authoring tools

Frank Strauss <[EMAIL PROTECTED]> writes: > This document describes a DTD and its application for authoring > RFC-like documents. It also contains references to his open source > tool "xml2rfc" that allows to compile such XML documents to IETF > conformant text files and to HTML pages. > > I used

Re: RFC authoring tools

Frank Strauss <[EMAIL PROTECTED]> writes: > Florian> I've made a Debian package of it, and hope that it finds its > Florian> way into the archive some day. > > Cool. Wo finde ich denn derweil das Debian Package? :-) Oh, it's available at , but it's still pen

Re: Acronyms Et Al.

"David J. Aronson" <[EMAIL PROTECTED]> writes: > Anybody got an OED? The OED defines "initialism" as "The use of initials; a significative group of initial letters. Now spec. a group of initial letters used as an abbreviation for a name or expression, each letter or part being pronounced separat

Re: Acronyms Et Al.

"David J. Aronson" <[EMAIL PROTECTED]> writes: > > I doubt that this distinction is helpful in our field. Quite a > > few initialisms are brutally acronymed > > And nouns brutally verbed "acronymed" is blessed by the OED. 8-)

Re: Stupid DNS tricks

Adam Roach <[EMAIL PROTECTED]> writes: > Because this is probably a community of interest for the > topic of DNS, I thought it would be worthwhile mentioning > that Verisign has apparently unilaterally put in place > wildcard DNS records for *.com and *.net. All unregistered > domains in .com and

Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]

Zefram <[EMAIL PROTECTED]> writes: > 1. Via ICANN, instruct Verisign to remove the wildcard. By the way, what about .museum?

Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]

Paul Vixie <[EMAIL PROTECTED]> writes: >> By the way, what about .museum? > > .museum does not delegate all of its subdomains. > > not all tld's are delegation-only. I know. I have to admit that (as someone who grew up under .de) I would never have thought of the delegation-only approach. 8-)

Re: What exactly is an internet (service) provider?

* Hadmut Danisch: > at least here in Germany Internet providers tend to > do and not to do what they want. > > - Some cut off their clients every 24 hours (DSL) This happens on the sub-IP layer and hasn't got to do much with ISPs. > - Some block or slowdown particular tcp ports > to get rid

Re: What exactly is an internet (service) provider?

* Hadmut Danisch: > That's currently a consequence of the shortage of IP addresses. There's no shortage of IPv4 addresses. Today, it's not a problem to get IP addresses if you have determined that NAT is not an option. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the follo

Re: What exactly is an internet (service) provider?

> You missed the point. This is not about complaining that I don't get > enough for the money. This is that I don't know in advance what > I do get for my money. So far, I had no trouble getting the facts beforehand. If you can't reach anyone at that ISP for comment, you don't want to become its

Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

* Pekka Savola: > The justification is simple: any "magic" packets which all routers on > the path must somehow examine and process seems a very dubious concept > when we want to avoid DoS attacks etc. Any packet with IP options is more or less in that category right now, so it's a very long way

Re: Copying conditions

* Margaret Wasserman: > While I am most definitely not a lawyer, it is my understanding that > it is permissible to quote from copyrighted works as long as they are > properly referenced. I don't think that we should stop people from > quoting (and referencing) RFCs, but we should stop people

Re: Copying conditions

* Margaret Wasserman: >>The open source community definitely wants to be able to guarantee to >>its users the ability to take text or code from an IETF standard and >>use that text or code in derivatives of that standard. Parts of the >>open source community want to be able to claim that that sta

Re: Shuffle those deck chairs!

* Eric S. Raymond: > Florian Weimer <[EMAIL PROTECTED]>: >> Are you familiar with IETF IPR policies? Microsoft's Sender ID >> license was a perfectly acceptable RAND patent license. > > Yes, I am familiar with those policies. Sender-ID is a perfect > illustr

Re: Fw: Impending publication: draft-iab-dns-assumptions-02.txt

* Keith Moore: >> i think this document is just silly. and highly subjective. there is >> no way to edit it to correct its problems -- it should just quietly >> die. IAB should preserve its relevance and integrity by limiting its >> focus to objective technical matters (such as the excellent wor

Re: Fw: Impending publication: draft-iab-dns-assumptions-02.txt

* Harald Tveit Alvestrand: > --On 5. mars 2005 13:39 +0100 Florian Weimer <[EMAIL PROTECTED]> wrote: > >> By "special semantics" I mean special stub >> resolver or resolver which is triggered by the appearance of some >> magic labels or domain nam

Re: Fw: Impending publication: draft-iab-dns-assumptions-02.txt

* Harald Tveit Alvestrand: > I checked my private copies of draft-cheshire-dnsext-multicastdns-00 to > -04, and could not find either the number "192" nor the string "return" in > such a context. This was a joke. 8-) In section 3, the draft hijacks "local.". Not "_local." or "local.arpa.", b

Re: HTTP/1.1 Protocol: Help Needed

* Gaurav Vaish: >> "Authentication through forms" is not the way that HTTP authentication >> works. If you would be doing HTTP authentication* >> You do need cookies then or you can use a special 'session id' option in >> the tag. > > I understand that and know how the HTTP Authentication works. >

Re: Authentication/Session tracking question [was: HTTP/1.1 Protocol: Help Needed

* Gaurav Vaish: >Can we have a header called Auth-ID which may perform the task of a > session-ID. Instead of putting in form-data or part-of-URL (which > leads to a must-form-on-every-request) or as cookies (sometimes > disabled, for good reasons as mentioned in thread), we can have it as > a

draft-iab-dos-03.txt

| 2.6 DoS Attacks on Sites though DNS Typo, "though" instead of "through". Manipulating the DNS of a popular service can lead to clients sending requests to a different address, which can also constitute a massive distributed attack (see Blaster.E, for example). In a sense, this attack belongs

Re: Alternative formats for IDs

* william elan net: > BTW - PDF also still rather "fluid" format with multiple versions > and not always clear if PDF you create could be read by all readers > in the same way you intended. So if PDF is as format, then exact > version must be specified as well. I fear that PDF shares a very obnox

Re: The Emperor Has No Clothes: Is PANA actually useful?

* Bernard Aboba: >> My question is more why do they need EAP in situations where they are >> not running at the link layer than why do they want or not want PANA. > > The simple answer is that there are situations which IEEE 802.1X cannot > handle on wired networks. As specified, IEEE 802.1X is

Re: How to pay $47 for a copy of RFC 793

* Bob Braden: > Now, it has always been IETF's (and even before there was an IETF, > Jon Postel's) policy to allow people to sell RFCs. What astonishes > me is that clever people in the IEEE don't know RFCs are available > free online. I guess RFCs remain so counter-cultural that industrial > type

Re: How to pay $47 for a copy of RFC 793

* Steve Crocker: > A simpler and more pragmatic approach is to include a statement in > the boilerplate of every RFC that says, "RFCs are available free of > charge online from ..." > > The copyright rules would prohibit anyone from removing this > statement. If someone pays $47 for a copy and th

Re: [idn] Re: 7 bits forever!

"D. J. Bernstein" <[EMAIL PROTECTED]> writes: > Dan Kohn writes: >> a UTF8HEADERS ESMTP extension > > No! 8-bit support is not an option. 8-bit support is not something to be > negotiated. 8-bit support is _required_. I agree. 8BITMIME has largely failed (strictly speaking, announcing 8BITMIME

Status of draft-christey-wysopal-vuln-disclosure-00.txt

At some point, the authors of this IETF draft have officially withdrawn it, but this document is still being referenced a lot, sometimes in contexts which might lead inexperienced readers to believe that this draft is supported by the IETF. It's even expired. What's the status of the document, a

Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

Robert Elz <[EMAIL PROTECTED]> writes: > That wasn't done here, so the "officially withdrawn it" really can only be > interpreted as "the authors are no longer pushing this doc". The authors stopped pushing this document _only in the IETF context_. However, the document is usually referenced by

Uniqueness of WHOIS handles

Is there some method to guarantee the uniqueness of WHOIS handles? Can I register affixes somehwere? I'm currently creating a WHOIS-like database (which might be publicly accessible one day), and I'd like to avoid handle collisions with other WHOIS databases. (I asked a similar question on some I