Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Mark Andrews wrote: Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. I'm afraid DNSSEC people have been arguing against SCTP saying DNSSEC is good enough. Worse, though I have been warning for these 15 years that cached glue may be used only for glue with same refferal, a broken concept of bailiwick was introduced only to enable so called Kaminsky attack. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Protection of DNSSEC at the registy level is equivalent to protection against lifting tiles. Not practical at all. Locking the doors and windows stops most attacks however. Then, let's lock the doors and windows first, before working on DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelinesfor Considering Operations and Management of NewProtocols and ProtocolExtensions) to BCP
- Original Message - From: Adrian Farrel adr...@olddog.co.uk To: ietf@ietf.org Cc: ops...@ietf.org Sent: Thursday, June 04, 2009 11:58 AM In the discussion of IETF consensus of this document and its position as a BCP or otherwise, can I throw into the melting pot draft-ietf-pce-manageability-requirements-06.txt Yes, a clear concise set of steps to follow when writing an I-D. The other comment I would make on the I-D under Last Call is on the first sentence of the abstract, to whit, New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. True, but not, I think, addressed by this document. There is plenty in this I-D for the I-D editor but little for the protocol designer. The latter might benefit from advice on how to structure elements of the PDUs and the interchange of PDUs; it may be difficult to know whether or not a network is functioning if there is no keepalive. (A comparable discussion surfaced recently on apps-discuss over the best way to encode lengths). I appreciate that this I-D does not set out to give such advice but think that someone reading the abstract might expect it to. Tom Petch This particular I-D was developed within the PCE working group to apply only in that working group. It covers similar topics, but is more focused on ensuring that the protocols that are developed in PCE are manageable. The I-D has rough WG consensus (or did at the time I stopped being chair a few months ago), but is not mandatory to implement within the WG. It is my opinion that those PCE I-Ds that have taken the draft on board have produced better solutions that will be more successfully implemented and deployed. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNSSEC was never designed for transport end to end security
So quit trying to be a dead horse that is not even there. If you are so interested in transport layer security, then by all means, encourage, promote, and develop solutions. STCP is one such measure. IPSEC is another. there are many choices. transport level security (integrity, authenticity) are orthoginal to application level security (DNSSEC, SSH, HTTPS, etc) DNSSEC was never designed to provide or assure end to end security as seen at the transport layer. It couldn't, since its not a transport protocol. or is there some subtle nuance that I am missing in your arguement that is being overshadowed by your strident insistance that DNSSEC is not secure end to end. I agree with you that it is not, and I say so what... thats not what it was designed for. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNSSEC is NOT secure end to end
Bill Manning wrote: If you are so interested in transport layer security, then by all means, encourage, promote, and develop solutions. The discussion of the paper of David Clark about public key is not on a transport but on an administrative layer. The paper says: However, there is a key role for a third party, which is to issue a Public Key Certificate and manage the stock of such certificates; such parties are called certificate authorities. and the issuance and management of certificates, which is the key, involves no transportation of the certificates and is not transport but local (local to zone) administrative issues. Or, if you insist the paper discusses on transport layer security of public key cryptography, please feel free to quote the relevant part of the paper. I mention transport security merely because it is still required with DNSSEC, because administrative security of DNSSEC is cryptographically weak. So, let's throw away DNSSEC and the broken-from-the-beginning idea of bailiwick. Let's move on to lock the doors and windows. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote: In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. That is a serious charge. I've seen no evidence that DNSSEC represents a revenue opportunity for registries. On the contrary, so far as I've seen, most registries are introducing it without any fee, even though it represents a substantial additional operational cost. (Indeed, some of us were at times under the impression that the practical inability to charge anything in order to offset this additional cost was one of the biggest barriers to DNSSEC deployment.) What registries are you thinking of that are charging extra for DNSSEC delegations (i.e. for accepting a DS record)? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Shane Kerr wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. What do you mean the parent? Do you mean master zone file of the parent or some caching server expected by a client to have parent data? What I do not understand about this comment is how transport security can help in that case. Can you please explain? Explanation depends on your definition of the parent. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14
Ben, Thanks for your review. With respect to the HTTP issue you raise, is your claim that the HTTP binding prevents the use of Digest or Basic based on this sentence from Section 6.3? HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. If so, then I think that's a misinterpretation that calls for a clarification. The authors should feel free to correct me, but I think that HTTP-level errors (e.g., the need for authentication, or even a LIS not listening at a given path) can still generate other HTTP response codes (e.g., 401 or 404). It's just that if the only thing that's gone wrong is at the HELD layer -- if it's the positioning that failed, not the communications -- then you have to use a 200. Assuming that all the above is accurate, proposed text: HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. (Other response codes may still be generated at the HTTP layer, if the problem is with the HTTP part of the message, not the HELD part. For instance, if the request needs to be authenticated with Basic or Digest authentication, the server may issue a 401 Unauthorized response as a challenge, or if the indicated path is not valid, then the server may issue a 404 Not Found.) Cheers, --Richard Ben Campbell wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a feature that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. -- section 9.3, 5th paragraph: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location. It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? -- same paragraph: ... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a mitigating mention. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14
On Jun 5, 2009, at 8:43 AM, Richard Barnes wrote: Ben, Thanks for your review. With respect to the HTTP issue you raise, is your claim that the HTTP binding prevents the use of Digest or Basic based on this sentence from Section 6.3? HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. No, I based it on the last sentence, second paragraph in section 8: The LIS MUST NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617]. It doesn't explicitly forbid the use of digest authn, but if it can't depend on client support, then it can't really base any decision on it. If so, then I think that's a misinterpretation that calls for a clarification. The authors should feel free to correct me, but I think that HTTP-level errors (e.g., the need for authentication, or even a LIS not listening at a given path) can still generate other HTTP response codes (e.g., 401 or 404). It's just that if the only thing that's gone wrong is at the HELD layer -- if it's the positioning that failed, not the communications -- then you have to use a 200. Assuming that all the above is accurate, proposed text: HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. (Other response codes may still be generated at the HTTP layer, if the problem is with the HTTP part of the message, not the HELD part. For instance, if the request needs to be authenticated with Basic or Digest authentication, the server may issue a 401 Unauthorized response as a challenge, or if the indicated path is not valid, then the server may issue a 404 Not Found.) Cheers, --Richard Ben Campbell wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a feature that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. -- section 9.3, 5th paragraph: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location. It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? -- same paragraph: ... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a mitigating mention. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
On Fri, Jun 5, 2009 at 8:32 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: So, let's throw away DNSSEC and the broken-from-the-beginning idea of bailiwick. Let's move on to lock the doors and windows. Words of wisdom. I however propose we do not throw it away. I propose it be allowed to wither on the vine until DNSSEC life signs show it as being dead. Then the IETF can then do it's job and give it the proper burial it deserves. I propose all developers simply secure the DNS. A transparent solution tha is available NOW - is DNSCurve. Will ensure the end to end transport of DNS UDP packets is secure. And that basically fixes once and for all the insecurity we have in the UDP transport. DNSCurve encrypts all DNS packets. DNSSEC does not. DNSCurve cryptographically authenticates all DNS responses, eliminating forged DNS packets. DNSSEC does not. DNSCurve very quickly recognizes and discards forged packets, so attackers have much more trouble preventing DNS data from getting through. DNSSEC does not. so I ask you - who wins the cookie in this race? regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote: Yes, security of DNSSEC is totally hop by hop. I am nervous of adding to this debate (and should it really be on ASRG?) However, I think there is some difference in the way people are using some terms. My understanding of the terms hop-by-hop and end-to-end is this: A data item traverses a number of nodes within a network. (E.g. a UDP datagram moving through an inter-network, or a Email message from its submitting UA via a sequence of MTAs to the recipient's UA). End-to-end security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. Hop-by-hop security means that you do rely on the trustworthiness of the intermediate nodes and channels. (E.g. CRC provides no defence against deliberate tampering, TLS for email is only as trustworthy as the least trusted intermediate MTA). PKI establishes a chain of trust between the signing certificate (i.e. the certificate containing the public key corresponding to the private key used to generate the signature) and your trust anchors (which you choose). This is not really hop-by-hop as data is not hopping. Like a real chain, it is only as strong as its weakest link. However, the chain operates in a different 'space' from that used to transfer the data being protected. As far as I understand, the key thing which DNSSEC gives you is data origin authentication (although that by itself without data integrity would be useless). The DNS attacks which were the start of the discussion are all based on the attacker sending false data to the system under attack. Having an effective means for determining from whom data comes is necessary to overcome this kind of attack. best regards David Wilson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard
Group, Here are a few stupid/nit questions, 1) What do you do with host naming collisions? 2) Is a blank string blank equal to a string? 3) Is the hostname case sensitive? 4) Since the hostnames are human readable, would a backspace within the name make logical sense? 5) Don't some system implement x chars per tab, then how do we show a consistent hostname? 6) If bell is included, does the system need to create a sound each time the name is displayed? 7) If the router is localized to a different country, wouldn't a logical hostname representation be able to support multi-character and multi-byte foreign languages? 8) Underline support? Thus, IMO, someone needs to re-write part of this to equal http(s) URL type representation? or only alphanumeric chars And specify some sort of left/right printing justification and a way to deal with non printable chars.. Mitchell Erblich === On Jun 2, 2009, at 2:37 PM, The IESG wrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Dynamic Hostname Exchange Mechanism for OSPF ' draft-ietf-ospf-dynamic-hostname-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17203rfc_flag=0 ___ OSPF mailing list o...@ietf.org https://www.ietf.org/mailman/listinfo/ospf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNSSEC is NOT secure end to end
Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the attack by a trusted party, there are still huge differences between DNSSEC and transport-hop-by-transport-hop security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Ohta-san, On Fri, 2009-06-05 at 21:32 +0900, Masataka Ohta wrote: I mention transport security merely because it is still required with DNSSEC, because administrative security of DNSSEC is cryptographically weak. I think we all understand that it is possible to inject bad data into the DNS at the parent. What I do not understand about this comment is how transport security can help in that case. Can you please explain? Thanks, -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Ohta-san, On Fri, 2009-06-05 at 22:15 +0900, Masataka Ohta wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. What do you mean the parent? Do you mean master zone file of the parent or some caching server expected by a client to have parent data? I the parent in the same sense as in RFC 1034 - the delegating level. So, for EXAMPLE.COM this would be COM. What I do not understand about this comment is how transport security can help in that case. Can you please explain? Explanation depends on your definition of the parent. -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Suite B Certificate and Certificate Revocation List (CRL) Profile '
draft-solinas-suiteb-cert-profile-03.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-07-01. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-03.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18056rfc_flag=0
Lydia and Jim,
Here are some comments.
#1 Non-repudiation bit
During the development of other profiles where the NR bit wasn't set,
sometime after the profile gets developed I've usually gotten questions
like so you're not setting N-R can I use it for non-repudiation
services? To answer this question, I sometimes put text in that said
yes you can (below). Maybe we should add something like this maybe in
the security considerations?
Note that setting keyCertSign, cRLSign, and digitialSignature also means
that the certificate could be used by applications that require
non-repudiation services for certificate, CRL, and content signing,
respectively.
#2 Section 3.1 (add dashes)
r/SHA256/SHA-256
r/SHA384/SHA-384
#3 Section 3.2 (add a new line):
OLD:
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
NEW:
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
#4 Section 4.2 (add reference to 5480 and ECDSA-Sig-Value)
I sometimes think it's easier to understand that we've defined an ASN.1
structure for the r/s combo:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
It's in RFC 3279 and in RFC 5480. Don't point to X9.62 they did some
odd things to this structure. Maybe the 2nd para in 4.2 could be
changed as follows:
OLD:
The ECDSA signatureValue in an X.509 certificate is encoded as a BIT
STRING value of a DER encoded SEQUENCE of the two INTEGERS. For
example, in a signature using P-256 and hex notation:
NEW:
The ECDSA signatureValue in an X.509 certificate is encoded as a BIT
STRING value of a DER encoded SEQUENCE of the two INTEGERS. As per
[RFC5480], the structure, included for convenience, is as follows:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
For example, in a signature using P-256 and hex notation:
#5 Question: 4.2 Conversion Routine
Aren't the conversion routines in SEC1 and ANSI X9.62 the same? 5480
pointed to SEC1 because it was more readily available (online and free
versus online and not free for ANSI). Curious why you chose to point to
3279 and not 5480? 2.3.5 of 3279 points to 4.3.3 and 4.3.6 of ANSI
X9.62. 2.2 of 5480 points to 2.3.1 and 2.3.2 of SEC1G. If we don't
point to 3279 here and the next one, you could delete it as a reference.
#6 Section 4.2 5th para: r/RFC3279/RFC5480 (the same routine is in 5480
section 2.2)
#7 Section 4.5.2: r/[5280]/[RFC5280]
Cheers,
spt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: DNS Additional Section Processing Globally Wrong
At 02:06 04/06/2009, Sabahattin Gucukoglu wrote: On 4 Jun 2009, at 04:06, Mark Andrews wrote: In message aaab52ef-ad0a-4d3c-9b28-b864f342d...@sabahattin-gucukoglu.com , Sabahattin Gucukoglu writes: The problem is this: the authoritative servers for a domain can easily never be consulted for DNS data if the resource being looked up happens to be available at the parent zone. That is, bigbox.example.net's address and the RR's TTL can never be as specified by the zone master unless he or she has control over the parent zone's delegation to example.net if bigbox.example.net happens to be serving for example.net. (Registries give you address control, of course, but often they fix on large TTLs.) As far as I can tell, every public recursive server I can reach, dnscache and BIND9, and one Microsoft cache and one of whatever OpenDNS uses, all do the wrong thing (TM) and never look up true data from authoritative name servers. They hang on to additional section data from the delegating name server and pass this on as truth, the whole truth, and nothing but the truth to everybody who asks. Except they don't. What you may be seeing is parent servers returning glue as answers and that being accepted. Glue data, additional and non-authoritative by design, intent and specification, aren't what I want caches to keep. The data I spent my lunch hour putting into my zone file is. :-) As a matter of fact, it never occurred to me to wonder at this misbehaviour - it clearly wasn't that much of a big deal when I was running things myself - but the 2008 cache-poison attacks found me surprised that this is how it is. In particular, they only worked because the cache was happy to keep additional data for hosts that were pertinent to the query, but in which it had no business caching. If it had instead chased up the referal, the attacker would at least have had to run a nameserver to answer the Is it really you? query. Cheers, Sabahattin Strictly speaking the Additional Section processing is correct. The Missing step is that recursive resolvers have optimized away the safety step of fetching authorative delegation information. File bug reports, send mail to namedroppers insisting that Forgery resilience effort mandate fetch authorative behavior, even if that will break some important stuff as implementors of fake DNS servers do not return NS sets when asked (actually they have started to). Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2009-10: Second Call for Volunteers
Hi all, As noted last week, the IETF nominating committee process for 2009-10 is underway. The list of people and posts whose terms end with the March 2010 IETF meeting, and thus the positions for which the nominating committee is responsible, are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/1936/ The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of the nomcom can be found in RFC 3777. We've had a very good response to the initial call for volunteers, with the following individuals currently in the pool: Marc Blanchet, Viagnie John Drake, Boeing Satellite Systems Stephen Hanna, Juniper Networks Lixia Zhang, UCLA Sean Turner, IECA, Inc. Wassim Haddad, Ericsson David H. Crocker, Brandenburg InternetWorking David Meyer, Cisco/University of Oregon Kurt Zeilenga, Isode Limited Spencer Dawkins, Huawei Technologies (USA) Yi Zhao, Huawei USA Glen Zorn, Network Zen Christian Schmidt, Nokia Siemens Networks Jouni Korhonen, Nokia Siemens Networks Enrico Marocco, Telecom Italia Ingemar Johansson, Ericsson AB Christer Holmberg, LM Ericsson Theo Zourzouvillys, VoIP.co.uk Scott Brim, Cisco Bernie Hoeneisen, Swisscom Stephen Farrell, Trinity College Dublin/NewBay Software Simon Perreault, Viagnie Teemu Savolainen, Nokia Suresh Krishnan, Ericsson David Sinicrope, Ericsson Stephen Kent, BBN Technologies Richard Barnes, BBN Technologies Pete Resnick, Qualcomm Incorporated Feng Hu, Huawei Salvatore Loreto, Ericsson Jan Melen, Ericsson Mehmet Ersue, Nokia Siemens Networks Yakov Rekhter, Juniper Networks Conny Jorgen Larsson, Ericsson AB Joe Abley, ICANN Shane Kerr, ISC If you have volunteered and are not on the above list or have not heard from me otherwise, please contact me ASAP. However, we still need more volunteers - the more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. And, while you have until July 3rd to volunteer, volunteering early really improves the efficiency of the administrative process and ensures that we can quickly make the selection after the deadline. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-70, IETF-71, IETF-72, IETF-73 and IETF-74. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The primary activity for this nomcom will begin just prior to IETF-75 in Stockholm and should be completed in early January 2010. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, folks should consider that during the IETF meetings, folks that do not attend would be expected to remotely participate during the day in the timezones of the meeting locations - Stockholm the end of July and Hiroshima in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before 5:00 pm CDT July 3, 2009 as follows: To: mary.bar...@nortel.com Subject: Nomcom 2009-10 Volunteer Please include the following information in the body: Your Full Name // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // Please include all variations of names you might have used Current Primary Affiliation // as entered in the in the IETF Registration Form Preferred email address all email addresses used to Register for the past 5 IETF meetings Telephone number // May be used for confirmation if selected Please expect an email response from me within 1-2 days. If you don't receive a response, please re-send your email with the tag Duplicate: added to the subject line. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next couple weeks. Thank you, Mary H. Barnes mary.bar...@nortel.com nomcom-ch...@ietf.org ___ Ietf mailing list Ietf@ietf.org
RE: DNSSEC is NOT secure end to end
On Wed, 3 Jun 2009, Christian Huitema wrote: Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. How do you handle key changes? How do you determine if the key change is performed by the domain holder or an attacker? There is no reason for such a leap of faith caching. In fact, with SSHFP records, we can also nail down that leap of faith for ssh finally :) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: [secdir] secdir review of draft-dusseault-impl-reports-02
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes updates to existing processes for implementation and interoperability reports, and provides recommendations about the level of detail required. The document is about IETF standards process, is well written, and introduces no new security concerns. David Harrington dbharring...@comcast.net ietf...@comcast.net dharring...@huawei.com ___ secdir mailing list sec...@ietf.org https://www.ietf.org/mailman/listinfo/secdir ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote: Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the attack by a trusted party, there are still huge differences between DNSSEC and transport-hop-by- transport-hop security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. Private ad-hoc caching of keys would make DNS fairly fragile. While the trust anchor issue for DNSSEC looms, DNS will remain prone to inadvertently cached unsigned content. Benefits obtained by using DNS over SCTP would be significant protection from out-of-path poisoning, whether information is signed or not. Once DNSSEC is fully implemented and trust anchor issues are resolved, information contained within DNS would not depend upon transport protections. When that might happen remains unknown. However, once DNSSEC becomes widely adopted, the Internet may need protection from UDP/EDNS0 source spoofing. For this, SCTP would offer protection from source spoofing that DNSSEC does not prevent. EDNS0 should also have min/max limits imposed, where packets of a greater size should be handled by SCTP. The brute force strategy that allows DNS over UDP to cope with source spoofing and misuse, also makes DNSSEC over UDP a greater risk. UDP does not lend itself to being moderated or flow controlled, as some suggest. Although TCP permits flow control, TCP is much more vulnerable to resource exhaustion, creating significant costs when defending TCP services compared to those using UDP or SCTP. Reliability, performance and DDoS immunity makes SCTP an attractive solution over TCP. SCTP should perform well as a transport for either DNS or DNSSEC. SCTP would also provide improved security and performance for HTTP as well. :^) -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mipshop-mos-dns-discovery (Locating IEEE 802.21 Mobility Servers using DNS) to Proposed Standard
At 06:39 05-06-2009, The IESG wrote: The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Locating IEEE 802.21 Mobility Servers using DNS ' draft-ietf-mipshop-mos-dns-discovery-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the In Section 2.2: If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _MIHIS for the MIH Information Service, _MIHES for the MIH Event Service and _MIHCS for the MIH Command Service. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. The document discourages the use of the regexp field. I cannot tell why the author went to such lengths to define a DDDS application when it would have been easier to use SRV queries for the transport protocols. In Section 2.3: If TARGET is a numeric IP address, the MN uses that IP address and the already chosen transport to contact the server providing the desired service. According to RFC 2782, the target in SVR RR is a the domain name of the target host. In Section 7, the Author's email address is listed as gabor(dot)bajko(at)nokia(dot)com. Could the author please publish a valid email address instead of obfuscating the email address like that? It makes it easier for readers who have questions or comments to contact the author. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Stockholm IETF Code Sprint
A wiki has been set up for the Stockholm code strint: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF75Sprint The wiki includes a sign-up page. Please add your name to the table if you are planning to participate. Thanks, Russ IETF Chair wrote: Stockholm IETF Code Sprint When: July 25, 2009, begining at 9:30 AM Where: IETF Hotel in Stockholm What: A bunch of hackers get together to work on code for the IETF web site. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Chris Newman will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Stockholm. You will hear more from them shortly. Many of the results of the last code sprint are being used every day. Please support the tools development effort, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-solinas-suiteb-cert-profile (Suite B Certificate and Certificate Revocation List (CRL) Profile) to Informational RFC
At 12:39 PM -0400 6/5/09, Sean Turner wrote: #1 Non-repudiation bit During the development of other profiles where the NR bit wasn't set, sometime after the profile gets developed I've usually gotten questions like so you're not setting N-R can I use it for non-repudiation services? To answer this question, I sometimes put text in that said yes you can (below). Maybe we should add something like this maybe in the security considerations? Note that setting keyCertSign, cRLSign, and digitialSignature also means that the certificate could be used by applications that require non-repudiation services for certificate, CRL, and content signing, respectively. I disagree that this needs to be added, and I certainly don't think this qualifies as a security consideration. The draft already says (three times...) that the nonRepudiation bit MAY be set. #5 Question: 4.2 Conversion Routine Aren't the conversion routines in SEC1 and ANSI X9.62 the same? 5480 pointed to SEC1 because it was more readily available (online and free versus online and not free for ANSI). Curious why you chose to point to 3279 and not 5480? 2.3.5 of 3279 points to 4.3.3 and 4.3.6 of ANSI X9.62. 2.2 of 5480 points to 2.3.1 and 2.3.2 of SEC1G. If we don't point to 3279 here and the next one, you could delete it as a reference. That's a good question. It is good for us to point to free and easily-retrieved documents when possible. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC Editor's Bidders Conference Update
All; The Bidders Conference was held on 3 June and lasted almost 4 hours. ISI made excellent presentations. The transcript of the Conference, including handouts and screen shots can be found under Bidders Conference at: http://iaoc.ietf.org/rfced-procurement.html NOTE: The period for questions to be submitted to rpellet...@isoc.org has been extended from 5 June to 9 June. The official responses may be posted on 15 June, instead of 12 June, which remains the goal. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers) to BCP
Pekka: - 'Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers' draft-dawkins-nomcom-dont-wait-03.txt as a BCP I have two issues with this. 1) This places a new responsibility at the feet of IETF secretariat. That's a new actor (not even a person but a role) in the process. This is not good. Better would be that the process allowed some already responsible party (be it ISOC president, former NomCom chair, IETF chair, IAB chair, or all of the above) the _option_ to allow IETF secretariat to perform this announcement. (More about the option issue below) 2) As proposed, the IETF secretariat's role is exclusive. In the future no one else would have the authority to publish the solicitation. I don't think this is good. The role should be optional, if _responsible_ party(ies) chooses to take that path, or at most inclusive of other parties' authority. The IETF Executive Director, who is part of the Secretariat, already has a role in NomCom. The IETF Executive Director provides the requirements for the open positions. Would you be more comfortable if the Executive Director were named as the responsible party? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Shane Kerr wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. I the parent in the same sense as in RFC 1034 - the delegating level. So, for EXAMPLE.COM this would be COM. If you mean COM zone, it is not necessary to inject any data into the zone. You, instead, can inject a forged certificate into some cache used by your victim. It will be extremely easy if people are deceived that DNSSEC were so secure that no proteciton on cache were necessary. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: However, I think there is some difference in the way people are using some terms. According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. End-to-end security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. According to the terminology of David Clark, certificate authorities are intermediate nodes. If you have different terminology, use it outside of the Internet community but not within. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mipshop-mos-dns-discovery (Locating IEEE 802.21 Mobility Servers using DNS) to Proposed Standard
The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Locating IEEE 802.21 Mobility Servers using DNS ' draft-ietf-mipshop-mos-dns-discovery-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dns-discovery-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17213rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2009-10: Second Call for Volunteers
Hi all, As noted last week, the IETF nominating committee process for 2009-10 is underway. The list of people and posts whose terms end with the March 2010 IETF meeting, and thus the positions for which the nominating committee is responsible, are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/1936/ The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of the nomcom can be found in RFC 3777. We've had a very good response to the initial call for volunteers, with the following individuals currently in the pool: Marc Blanchet, Viag�nie John Drake, Boeing Satellite Systems Stephen Hanna, Juniper Networks Lixia Zhang, UCLA Sean Turner, IECA, Inc. Wassim Haddad, Ericsson David H. Crocker, Brandenburg InternetWorking David Meyer, Cisco/University of Oregon Kurt Zeilenga, Isode Limited Spencer Dawkins, Huawei Technologies (USA) Yi Zhao, Huawei USA Glen Zorn, Network Zen Christian Schmidt, Nokia Siemens Networks Jouni Korhonen, Nokia Siemens Networks Enrico Marocco, Telecom Italia Ingemar Johansson, Ericsson AB Christer Holmberg, LM Ericsson Theo Zourzouvillys, VoIP.co.uk Scott Brim, Cisco Bernie Hoeneisen, Swisscom Stephen Farrell, Trinity College Dublin/NewBay Software Simon Perreault, Viag�nie Teemu Savolainen, Nokia Suresh Krishnan, Ericsson David Sinicrope, Ericsson Stephen Kent, BBN Technologies Richard Barnes, BBN Technologies Pete Resnick, Qualcomm Incorporated Feng Hu, Huawei Salvatore Loreto, Ericsson Jan Melen, Ericsson Mehmet Ersue, Nokia Siemens Networks Yakov Rekhter, Juniper Networks Conny Jorgen Larsson, Ericsson AB Joe Abley, ICANN Shane Kerr, ISC If you have volunteered and are not on the above list or have not heard from me otherwise, please contact me ASAP. However, we still need more volunteers - the more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. And, while you have until July 3rd to volunteer, volunteering early really improves the efficiency of the administrative process and ensures that we can quickly make the selection after the deadline. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-70, IETF-71, IETF-72, IETF-73 and IETF-74. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The primary activity for this nomcom will begin just prior to IETF-75 in Stockholm and should be completed in early January 2010. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, folks should consider that during the IETF meetings, folks that do not attend would be expected to remotely participate during the day in the timezones of the meeting locations - Stockholm the end of July and Hiroshima in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before 5:00 pm CDT July 3, 2009 as follows: To: mary.bar...@nortel.com Subject: Nomcom 2009-10 Volunteer Please include the following information in the body: Your Full Name // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // Please include all variations of names you might have used Current Primary Affiliation // as entered in the in the IETF Registration Form Preferred email address all email addresses used to Register for the past 5 IETF meetings Telephone number // May be used for confirmation if selected Please expect an email response from me within 1-2 days. If you don't receive a response, please re-send your email with the tag Duplicate: added to the subject line. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next couple weeks. Thank you, Mary H. Barnes mary.bar...@nortel.com nomcom-ch...@ietf.org ___ IETF-Announce mailing list IETF-Announce@ietf.org
Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard
The IESG has approved the following document: - 'Carrying Location Objects in RADIUS and Diameter ' draft-ietf-geopriv-radius-lo-24.txt as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-24.txt Technical Summary This document specifies RADIUS attributes for conveying access network location information, in both civic and geospatial location formats, along with access network ownership. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed throughout, for various scenarios of location information function within AAA. WG Summary The WG reached solid consensus to advance this document after a number of iterations. The WG had initial hesitation about taking on the work, because the RFC 4119 pidf_lo object could not be used within RADIUS attribute size constraints. The WG concerns were met with an eventual functional compromise, providing a mandated attribute with the pidf_lo policy markers, and opaque attributes pointing to the geopriv location formats developed for DHCP which had constraints similar to RADIUS. This document is a Critical Requirement for 3GPP. Both the GSM Association and the ITU have specified Operator Namespace Tokens for use in this protocol. (The document has customers). Document Quality The protocol was reviewed in depth by both the GEOPRIV and RADEXT Working Groups. RADEXT's formal issues list was cleared. GEOPRIV and RADEXT had some overlapping issues, especially location information design, and scenario evaluation. The conclusion that location- aware AAA systems need to be able to implement the formats and processing found in the GEOPRIV documents was very useful, because it meant that GEOPRIV did not have to intercept or anticipate any enhancements of the RADIUS data model. The document is especially careful in projecting GEOPRIV's paranoia towards exposing location information. Section 8.3 contains a detailed review against the previously defined requirements related to this, and the Security Considerations details the use of security services RADIUS provides as the using protocol to meet requirements. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Stockholm IETF Code Sprint
A wiki has been set up for the Stockholm code strint: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF75Sprint The wiki includes a sign-up page. Please add your name to the table if you are planning to participate. Thanks, Russ IETF Chair wrote: Stockholm IETF Code Sprint When: July 25, 2009, begining at 9:30 AM Where: IETF Hotel in Stockholm What: A bunch of hackers get together to work on code for the IETF web site. Some people may be porting of existing functionality to the new framework; some people may be adding exciting new functionality. All code will become part of the open source IETF tools. Who: Hopefully you can help Chris Newman will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Stockholm. You will hear more from them shortly. Many of the results of the last code sprint are being used every day. Please support the tools development effort, Russ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-smime-new-asn1 (New ASN.1 Modules for CMS and S/MIME) to Informational RFC
The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'New ASN.1 Modules for CMS and S/MIME ' draft-ietf-smime-new-asn1-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-new-asn1-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16823rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Nominating Committee Process: Open Disclosure of Willing Nominees ' draft-dawkins-nomcom-openlist-04.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18213rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
