RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Joel, Please see inline. Cheers, Med -Message d'origine- De : joel jaeggli [mailto:joe...@bogus.com] Envoyé : mardi 10 septembre 2013 06:42 À : Lorenzo Colitti; BOUCADAIR Mohamed IMT/OLN Cc : v6...@ietf.org WG; IETF Discussion; BINET David IMT/OLN Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile- 04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On 9/9/13 4:24 AM, Lorenzo Colitti wrote: On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: The document explicitly says This document is not a standard. since version -00. __ __ What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. So this is a problem, and part of the reason I had enough concern about this document to not take it forward. being genereous the consensus on this document is pretty rough. if the outcome doesn't include the consent of implementors it's not very good advice. [Med] Joel, the intent of the document is clear: the goals and scope are unchanged since the individual submission. You can read the following in the introduction: This document specifies an IPv6 profile for mobile devices listing specifications produced by various Standards Developing Organizations (in particular 3GPP and IETF). The objectives of this effort are: 1. List in one single document a comprehensive list of IPv6 features for a mobile device, including both IPv6-only and dual-stack mobile deployment contexts. These features cover various network types such as GPRS (General Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11 network. 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. 3. Vendors to be aware of a set of features to allow for IPv6 connectivity and IPv4 service continuity (over an IPv6-only transport). Operators will use this profile (or some part of it (context-based: ipv6-only, DS, CPE model, etc.)) for further discussion with their vendors. We are not changing that process. This document is a contribution to have non broken IPv6 implementations. For instance, our device partners will see in our 500 pages device requirements document (OGDR) pointers to this profile document. So adding the text suggested by Lorenzo is fine by me. This is the change added to my local copy: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers from vendors who are happy with the content of the document ... but in the meantime I have two reviewers from the same company: one of them suggested to make some edits to enhance the document while the other reviewer have some concerns. The concerns of the second reviewer were addressed and changes were added to my local copy. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformance with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. If not all vendors, then what about some vendors? Is it a goal of this document to have consensus from some implementors? Or is consensus from implementors a non-goal?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.com wrote: * NEW:* * * NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the** ** previous section only for precision. * * That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead. How about changing is not required in order to claim conformance with IETF standards for IPv6 to is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6?
Re: not really pgp signing in van
On 10 Sep 2013, at 3:53, John R Levine jo...@taugh.com wrote: Typical S/MIME keys are issued by CAs that verify them by sending you mail with a link. While it is easy to imagine ways that could be subverted, in practice I've never seen it. The most obvious way that it can be subverted is that the CA issues you a key pair and gives a copy of the private key to one or more others who would like either to be able to pretend to be you, or to intercept communication that you have encrypted. I would argue that this is substantially less trustworthy than a PGP key! Like I said, it's easy to imagine ways it could be subverted. If you believe all CAs are crooks, you presumably don't use SSL or TLS either, right? There's using it, and then there's trusting it to be good enough to protect what it's applied to protect. I'm reasonably certain attackers that can subvert TLS through undisclosed implementation vulnerabilities and/or compromised CA's aren't interested in my credit card number, and even if they are, the law limits my liability if I'm a victim of fraud -- it's priced in to the payment system. I'd estimate my risk is 1e-4 or so of a few hours of phone calls and paperwork, my reward is I can order stuff from Amazon, which is a pretty good tradeoff. For situations where I'd actually want to encrypt email, the math is different. If we think that PGP is so great, how about writing native PGP support for Thunderbird and Evolution, and contribute them to the open source codebase? More important for making sure message privacy is there in the future: if we think that PGP is so great, let's work on native PGP support for MUAs/messaging apps for Android and iOS devices. We're not going to be in a situation much longer where the majority of the planet is using PCs for messaging, if, indeed, we still are. Cheers, Brian signature.asc Description: Message signed with OpenPGP using GPGMail
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re, I have considered that Lorenzo. is not required to deploy IPv6 would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 08:49 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: NEW: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead. How about changing is not required in order to claim conformance with IETF standards for IPv6 to is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.com wrote: I have considered that Lorenzo. “is not required to deploy IPv6” would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers Are reviews still appropriate? I think there are a lot of things left to say about this document beyond the high-order points we're discussing at the moment. If I write them down, will they be considered or will the answer be that it's too late to accept feedback because the document is already in last call?
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, I really don't see how you can have a phone that make a phone that works perfectly well on an IPv6-only if you don't support IPv6/IPv4v6 PDP context, you don't have a means to make work broken applications when IPv6-only is enabled, if the phone does not follow the procedure for requesting the PDP context, how you can be compatible with DNSSEC, etc. If what you mean by perfect is a degraded level of service, then you are right. I update the text to reflect this: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This document uses the normative keywords defined in the previous section only for precision. Is this better? Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 09:21 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: I have considered that Lorenzo. is not required to deploy IPv6 would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT.
Re: pgp signing in van
Original Message - From: Richard Barnes r...@ipv.sx To: Peter Saint-Andre stpe...@stpeter.im Cc: ietf@ietf.org Sent: Monday, September 09, 2013 6:14 PM It also makes it obvious to everyone that Peter is using PGP. Which serves a pedagogical function, I guess. :) It also means I can readily view his e-mails, which may or may not be a good thing. With multipart/signed; micalg=pgp-sha1, on my MUA, the body of the e-mail displays as a blank page and I have to undertake several contortions in order to view the text, which I usually do not bother with, relying on a later reply which is not multipart/signed which includes the text in question which then displays as usual. Could be worse (or better); with multipart/signed; protocol=application/pkcs7-signature; I get an invitation to Continue which doesn't, probably because I won't allow my MUA to process html except as plain text (for reasons of security, of course; html has far too many attack vectors to allow it to be processed in e-mail) Tom Petch On Mon, Sep 9, 2013 at 1:12 PM, Peter Saint-Andre stpe...@stpeter.imwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/13 11:02 AM, Cyrus Daboo wrote: Hi Peter, --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre stpe...@stpeter.im wrote: But until the MUAs across the board support it out of the box, I believe most people don't know about it or know what it means. So that's an opportunity to educate people. For instance, perhaps the Internet Society might be interested in taking on that task. Is there a reason you choose to use inline signing with PGP rather than multipart/signed? Is that a technical reason (e.g., poor interoperability)? Ignorance or misconfiguration in my use of Thunderbird, it seems. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLgF/AAoJEOoGpJErxa2pnG8P/RpJj1SDr1plL3myoumgi4iS 0RLDNqq+2J+aiuDOccVJZYRITWFo3HmP3XD+nuDXiVxVUl+vuDhWHhWzQxtV04DS AUTN5mgY7Z5z2wfECFzC2MmqEG9tVD7i/gTij8cHTHyFuMvF27X32nTe/gxpo0eu 5cOhbzt2YWyF0nZff8cbQ+7o6d8RtaqE6G+jJVS4qUWeqEhYoFjjIGWieHZaNmw2 U/CQfYnAbpph/D38QDP/Tw8UJkNLXlukrbKPKtd+8Z/KAxGYkldabD01Frdkt5ZF k2PosNHHpy9Ob61SH8N/vrAO/NF4c6VYEoAk8yqCgYLLNH3BSc3fSUoGjF47VU8f PMKW/Hz9cG/1P5VhVTHNPx50b5Auuglo36pLIvlJjYzT8cZCpaCElhn4dScKLMLt //E+/EdTs6gnayBgbok31NXPWr4ORMlaff8jSinVK08COIGyCyul+9vo2/vs4WdI XZ8ToqmXUg/0d0KfRozqCQwKDHHqdkYIfTt8/rLDheXUDTTuvKWxmmLLxXs6CXMU kMQ99IaRraoAVWaEiUhIdLH3Ewj7ibFsqx9UruvUX5irqDO9SbjlJC7b41iHgUIG HBJiH3w947+mHLIXFJ2G9dBcv+CuOYVATqScu0jSDbsWE6xsqS1miNofyr1+al49 wcogO/B8kXm7cSHJjce5 =cGPH -END PGP SIGNATURE-
Re: thoughts on pervasive monitoring
It is a shame that this opportunity was not taken to highlight the need for authentication. Having a totally secure channel with perfect encryption is of little value if the other end of the channel is a hostile power. RFC3365, which you cite, gets in right (of course!). It lists three requirements and top of the list - Authentication service. It may of course be that the author was only putting the requirements in alphabetic order but whatever the reason, the emphasis is appropriate. Tom Petch - Original Message - From: IETF Chair ch...@ietf.org To: ietf@ietf.org; ietf-annou...@ietf.org Sent: Sunday, September 08, 2013 10:53 PM Here are some thoughts on reports related to wide-spread monitoring and potential impacts on Internet standards, from me and Stephen Farrell: http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Comments appreciated, as always. Jari Stephen
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.com wrote: I really don’t see how you can have a phone that “make a phone that works perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP context You don't need to support IPV4V6 if all you need to do is work on an IPv6-only network. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. you don’t have a means to make work broken applications when IPv6-only is enabled Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This is not about IPv6-only mode. That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. But someone taking this document as a guide to what needs to be implemented to deploy IPv6 would consider them to be incomplete or broken implementations. Such a person might look at the 34 requirements and just give up, when in fact such an implementation is perfectly capable of doing IPv6 today.
Re: thoughts on pervasive monitoring
On 09/10/2013 09:12 AM, t.p. wrote: It is a shame that this opportunity was not taken to highlight the need for authentication. Having a totally secure channel with perfect encryption is of little value if the other end of the channel is a hostile power. True. But if strong authentication at Internet scale is so hard that people fall back to cleartext then that's worse. Strong authentication can also in some cases expose identifiers where you wouldn't otherwise need to, which is not the best thing from a privacy perspective. So for at least some of what's recently reported, it seems to me that there is value in exploring whether opportunistic encryption is worthwhile, maybe for cases where we don't yet have strong authentication schemes that are privacy friendly and that are deployable at Internet scale. But yes, we also need to worry about strong authentication and making that easier/better. I'd be happy to see folks working on this from both approaches - making strong authentication easier/better but also taking the approach of seeing whether and when opportunistic encryption adds value. I would not be happy if we dive into either one while ignoring the other. S. RFC3365, which you cite, gets in right (of course!). It lists three requirements and top of the list - Authentication service. It may of course be that the author was only putting the requirements in alphabetic order but whatever the reason, the emphasis is appropriate. Tom Petch - Original Message - From: IETF Chair ch...@ietf.org To: ietf@ietf.org; ietf-annou...@ietf.org Sent: Sunday, September 08, 2013 10:53 PM Here are some thoughts on reports related to wide-spread monitoring and potential impacts on Internet standards, from me and Stephen Farrell: http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Comments appreciated, as always. Jari Stephen
Re: Conclusions of Last Call for draft-ietf-spfbis-4408bis
On 7 sep 2013, at 15:31, Pete Resnick presn...@qti.qualcomm.com wrote: 5c. Things may have changed since 6686. We should do more data collection. - There's no reason to believe that the small amounts of recently presented data are representative. - Nobody presented any basis to doubt the folks working in the industry. - There has been ample opportunity (and motivation) for folks outside of the WG to do more data collection; none has been presented. - It is an unreasonable burden to place on the WG at this point. FWIW, we at Netnod that run i-root have been looking at the queries we get to the root name server of ours. We have been looking at the data collected during the DITL collection which is 30-48 hour collections of data that happens once a year. What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries. We did look at 2011, 2012 and 2013. The result is the following: Date MXTXT SPF %TXT/MX %SPF/MX %SPF/TXT 2011-06-07 148528658 7484035 784386 5.0%0.5%10.5% 2012-04-17 90779132 4839143 536467 5.3%0.6%11.1% 2013-05-28 114353838 11554391 1595777 10.1%1.4%13.8% What we see is that the percentage of TXT queries per MX query has gone up from 5% to 10.1% and SPF queries went up from 0.5% to 1.4%. The percentage of SPF queries compared to TXT went up from 10.5% to 13.8%. Regards, Patrik Fältström
Re: not really pgp signing in van
Subject: Re: not really pgp signing in van Date: Tue, Sep 10, 2013 at 01:07:19AM - Quoting John Levine (jo...@taugh.com): The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot better than they support PGP. There's typically a one key command or a button to turn signing and encryption on and off, and they all automagically import the certs from on incoming mail. advocacy type=MUA That is why you should start using mutt. Mutt fetches the PGP key that signed a received message from key servers if it is not present in the local keyring, and verifies it. /advocacy As a result, I've got all the IETFers that sign messages saved in my key ring. Automatically. Subsequent signed messages from that same sender will either validate or be very clearly flagged as fakes. This is exactly the same security level that all SSH fans know and love, ie. wide open for MITM and impostors. It is -- however -- upgradeable to really useful by verifying and signing the sending keys. As has been stated before, MIME multipart signatures and their structured data are definitely capable of maintaining the integrity of the message one is replying to. Frequently, though, this either means that replying properly will trash the message or deteriorate into top-posting. Top-posting, while normally a flogging offense in my book, has the advantage of preserving the replied-to text slightly better. The conversation structure is OTOH trashed[0] The one thing that comes out of this message, then, is that this is a end-node problem that is probably best solved in MUA implementations. A possible method could be to design a diff multipart -- that is a list of edits (i'm thinking of something like diff -e that makes a diff as an ed script that can be applied to the original message.) applied to the replied-to message. This multipart is then signed and transmitted, and the receiving MUA then performs validation of the replied-to text part, the diff part, and if they validate, will merge them, creating a clear presentation of which lines are original and which ones are edited. For reference, the original message of course is included and the MUA should have a display option to show the original unaltered. There are several problems with the above idea, for instance the notion of ever-growing emails as all posters simply shove the history downwards to push their stellar insights on top of the pile, but today, that is mainly a display problem. Since I'm suggesting a fairly aggressive presentation system with preserved history, I think that is tolerable. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I feel like a wet parking meter on Darvon! [0] A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: Digital signature
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mardi 10 septembre 2013 11:27 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: I really don't see how you can have a phone that make a phone that works perfectly well on an IPv6-only if you don't support IPv6/IPv4v6 PDP context You don't need to support IPV4V6 if all you need to do is work on an IPv6-only network. [Med] UEs that will provided with IPv6-only or DS is up to the provider. Note also that the requirement is worded to let the decision to each provider. The document explicitly says: This allows each operator to select their own strategy regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP- Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends on the cellular network configuration. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff [Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features. , without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. [Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That's not fair. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. [Med] This document is not a standard. This document does not ambition to have the same level as RFC1122. you don't have a means to make work broken applications when IPv6-only is enabled Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). [Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode. The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. [Med] Are you saying this is a MUST? if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? [Med] How many device support IPv6 today? We can play that game endlessly... NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This is not about IPv6-only mode. [Med] What is wrong in that text? Can we focus on the exact text change? That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. [Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones...while this is not true. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. [Med] I'm sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode.
Re: Conclusions of Last Call for draft-ietf-spfbis-4408bis
Hi Patrik, On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström p...@frobbit.se wrote: What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries. I'm not sure that's a valid conclusion. Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX. The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data. -MSK
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 8:12 PM, mohamed.boucad...@orange.com wrote: *[Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features.* Sorry - what I meant is: most of the text in the document says that devices MUST support this, SHOULD support that, SHOULD support the other, but not much time saying why. ** *[Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That’s not fair.* Isn't it? For example, look at RFC1122 and compare it to this document. Compare the percentage of text used to state requirements and the percentage of text used for rationale. If anything, an informational document should have fewer requirements and more rationale than a standard, not the other way around. Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). *[Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode.* Then change the requirement to say vendor applications must not be IPv4-only. At least it's a reasonable request (though one that's unlikely to happen before IPv6 is widely deployed). All apps is not a reasonable request. * * The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. ** *[Med] Are you saying this is a MUST?* I don't think this document should be a bunch of MUST this, SHOULD that, MUST the other. As regards 464xlat, I think that shipping an IPv6-only phone without 464xlat or something equivalent equals shipping a phone that's not useful, and that doesn't happen in the real world. So if you want to ship IPv6-only, you need something like 464xlat. Does it follow that a phone MUST implement 464xlat? No, it does not. ** *[Med] How many device support IPv6 today? We can play that game endlessly...* Not really, because upwards of 30 million mobile devices are using IPv6 every day on Verizon Wireless alone. See: http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13462152832-2.pdf http://www.worldipv6launch.org/measurements/ Those phones do not meet the requirements of this draft. They violate at least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs. According to the text in -05, that means they cannot connect to an IPv6-only or dual-stack wireless network including 3GPP cellular network and IEEE 802.11 network). I know that text won't be there in the next version, but the point I'm trying to make is that the document made it all the way to IETF last call while claiming that largest deployment of IPv6 in a mobile network was not possible. I don't want that to be the message coming out of this document. NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). ** This is not about IPv6-only mode. *[Med] What is wrong in that text? Can we focus on the exact text change?* The operators proposing this profile believe that the support of a subset of the features included in this protocol may lead to degraded level of service. * * Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. ** *[Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones…while this is not true.* Per the document, if you implement IPv6 tethering you MUST implement a full RFC 6204 router in the device (req#28). * * ** I don't consider these to be degraded service, I consider them to be a lot better than what we have today. *[Med] I’m sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode. * I stand by my opinion that IPv6 tethering without a full RFC6204 implementation and that 464xlat without a local DNS64 implementation are not degraded.
Re: Conclusions of Last Call for draft-ietf-spfbis-4408bis
On 10 sep 2013, at 13:39, Murray S. Kucherawy superu...@gmail.com wrote: On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström p...@frobbit.se wrote: What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries. I'm not sure that's a valid conclusion. Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX. The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data. True. View my explanation just like it was, how we did our calculations. Conclusions can anyone draw from the data. The problem is that if one look at just queries to a root server like this, there is lots of what I would call junk. When looking at TLDs, we saw about 162 million different TLDs each 24h in the QNAME. We saw this time also for example queries for SPF and other RR Types where the QNAME was an IPv4 address (for example 10.2.3.4.). So, we found _some_ algorithm was needed instead of just counting queries, and we did count the way I just explained. Patrik
Re: pgp signing in van
On Sep 10, 2013, at 4:41 AM, t.p. daedu...@btconnect.com wrote: for reasons of security, of course; html has far too many attack vectors to allow it to be processed in e-mail If that's true, why is it safe for you to use HTML in a web browser? Is it because you feel that the HTTP trust model is safer? Are you trying to avoid attacks via spam? If the former, you are probably mistaken. If the latter, it seems to me that PGP-signed messages would help with this, and that you ought to switch to a non-broken MUA. Your assumption about HTML email is particularly worrisome because it is similar to an assumption people frequently make that NATs and firewalls keep them safe because unsolicited incoming connections are dropped. This is of course not true, because it's not that difficult to get you to make an outgoing connection to an address that leads to an attack against your browser. It's certainly easier to attack you by sending you spam, and prohibiting HTML in email does protect you from attacks via HTML flaws by spammers. But you pay a pretty heavy price for that protection, and it's one that most email users would not consider paying, so by doing this you are essentially deciding not to eat our dogfood. If we IETFers do this sort of thing habitually, we wind up living in a security context that most users do not live in, and wind up designing protocols that really don't address the needs of most users. This is Very Bad.
the evil of html was Re: pgp signing in van
- Original Message - From: Ted Lemon ted.le...@nominum.com To: t.p. daedu...@btconnect.com Cc: Richard Barnes r...@ipv.sx; Peter Saint-Andre stpe...@stpeter.im; ietf@ietf.org Sent: Tuesday, September 10, 2013 2:03 PM On Sep 10, 2013, at 4:41 AM, t.p. daedu...@btconnect.com wrote: for reasons of security, of course; html has far too many attack vectors to allow it to be processed in e-mail If that's true, why is it safe for you to use HTML in a web browser? Is it because you feel that the HTTP trust model is safer? Are you trying to avoid attacks via spam? If the former, you are probably mistaken. If the latter, it seems to me that PGP-signed messages would help with this, and that you ought to switch to a non-broken MUA. tp Ted A URI in a plain text e-mail means what it says; a URI in a ... / in html can display a perfectly innocent name while linking me to an evil website, a much used tactic. (If my MUA promised never to follow a link, then I would let it process html). With a web browser, at least I am myself choosing to click on the link, I can easily view the underlying html if I am doubtful (possible, but not so easy with an MUA), I can see the address in the browser address bar and kill it if it goes where I do not want it to. It is the user interface of the MUA to the html that is inadequate, browsers do it better. But increasingly, I find web sites becoming evil, perhaps when I am following a link from an e-mail posted to an IETF list to access background information and then find https links being set up from my browser to sites that I do not wish to have any truck with (e.g. twitter, facebook), presumably in order to take clandestinely details of me in order to build up a profile of me for some nefarious purpose. So increasingly, I do not trust html in web sites either. Tom Petch /tp Your assumption about HTML email is particularly worrisome because it is similar to an assumption people frequently make that NATs and firewalls keep them safe because unsolicited incoming connections are dropped. This is of course not true, because it's not that difficult to get you to make an outgoing connection to an address that leads to an attack against your browser. It's certainly easier to attack you by sending you spam, and prohibiting HTML in email does protect you from attacks via HTML flaws by spammers. But you pay a pretty heavy price for that protection, and it's one that most email users would not consider paying, so by doing this you are essentially deciding not to eat our dogfood. If we IETFers do this sort of thing habitually, we wind up living in a security context that most users do not live in, and wind up designing protocols that really don't address the needs of most users. This is Very Bad.
Re: Practical issues deploying DNSSEC into the home.
Hi Jim, On 2013-09-10, at 11:55, Jim Gettys j...@freedesktop.org wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. Dave and I wrote up a proposal for this, which may be of interest. If you find this document, let me know and we can work to rejuvenate it (it withered on the I-D vine). http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). I think as a starting point, you could safely assume that any local domain you host for the purpose of home users could be unsigned. Users behind the home gateway are trusting the cache on the home gateway anyway; serving signed, authoritative local data doesn't seem like it would add much benefot over serving the same data unsigned. Joe
Re: not really pgp signing in van
On Mon, Sep 9, 2013 at 9:41 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 9, 2013, at 9:26 PM, John R Levine jo...@taugh.com wrote: Um, didn't this start out as a discussion about how we should try to get people using crypto, rather than demanding perfection that will never happen? Yes. Typical S/MIME keys are issued by CAs that verify them by sending you mail with a link. While it is easy to imagine ways that could be subverted, in practice I've never seen it. The most obvious way that it can be subverted is that the CA issues you a key pair and gives a copy of the private key to one or more others who would like either to be able to pretend to be you, or to intercept communication that you have encrypted. I would argue that this is substantially less trustworthy than a PGP key! The CA NEVER ever gives the user the key in any of the systems I have worked on. VeriSign did offer a key recovery system for enterprise use with central key generation but the keypair is generated on the enterprise side and never passed to the CA. Of course you can _do_ S/MIME with a non-shared key, but not for free, and not without privacy implications. (I'm just assuming that an individual can get an S/MIME Cert on a self-generated public key—I haven't actually found a CA who offers that service.) Comodo offers that exact service today. https://secure.comodo.com/products/!SecureEmailCertificate_Signup Now this product still has the usual problems of S/MIME and PGP in that there is no infrastructure that allows a receiver to easily acquire the certificate (except by bulk query on the CA LDAP server) and there is no way to know what the sending policy should be. The key pair is generated in the browser using the Javascript mechanism (as far as I know, I have not checked but my understanding is that this is how it works). Just applied for a cert for Safari on ph...@hallambaker.com. Worked fine. But the process of getting the certificate into my email client is far from simple. Apple mail certainly has the capability to do S/MIME but the controls to enable it are buried deep. Same issue. I can send signed mail to a buttload more people with S/MIME than I can with PGP, because I have their keys in my MUA. Hypothetically, one of them might be bogus. Realistically, they aren't. Very nearly that same degree of assurance can be obtained with PGP; the difference is that we don't have a ready system for making it happen. I don't see the value of this argument. We have to fix key distribution. We have to make the CA actions transparent. That means a redesign of that whole part of the technology. If we are looking forward to new email systems then we can combine PGP Web of Trust with S/MIME message formats. E.g., if my MUA grabs a copy of your key from a URL where you've published it, and validates email from you for a while, it could develop a degree of confidence in your key without requiring an external CA, and without that CA having a copy of your private key. Or it could just do ssh-style leap-of-faith authentication of the key the first time it sees it; a fake key would be quickly detected unless your attacker controls your home MTA or the attacked identity's home MTA. Eliminate the CA and you eliminate the parties with the incentive to sell the solution. Whatever scheme is picked to complete secure email there is going to be a problem finding end users certs and end user policies. And there may be a market for solving that problem just like there is a market for blocking spam. -- Website: http://hallambaker.com/
Re: Practical issues deploying DNSSEC into the home.
On Tue, 10 Sep 2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. One solution is tlsdate which uses the installed bundled CA (or comes with its own) and runs TLS against a bunch of well known large sites (using insecure DNS) and sets the time based on the TLS handshakes. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of the enemy of the good is the perfect, but certainly I'm now much more paranoid than I once was. Be aware openwrt has a history (with openswan) to blindly change /dev/random references into /dev/urandom. You are most likely better of giving the device a webgui and using the clients javascript to generate randomness. (yes I know, I just said to use javascript for private keys) But I'm still thinking of a scheme involving insecure ntp lookups for pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow down the current time. Of course, all of that is vulnerable to replay attacks. Also, I believe the rasberry pi's, having the same problem, have a hwclock service that saves a timestamp on shutdown to the filesystem and loads it on boot. That solves the issue for quick reboots. Another method is the last access time of the filesystem. But I'm not sure if that's a linux/ext4+ only feature, or whether the filesystems in embedded devices have a similar value stored somewhere. Paul
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On 9/9/13 1:06 PM, Owen DeLong wrote: I have to agree with Lorenzo here again. This document seems to me to be: 1.Out of scope for the IETF. AD here... let's put this one to bed. there are existance proof(s) of previous work in this area and others that covers similar ground. I don't believe that this is out of scope for the WG or the IETF, Neither did the previous AD. So... Focus on the contents. 2.So watered down in its language as to use many words to say nearly nothing. 3.Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. Why is there such a push to do this? Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med *De :* Lorenzo Colitti [mailto:lore...@google.com http://google.com/] *Envoyé :* lundi 9 septembre 2013 13:24 *À :* BOUCADAIR Mohamed IMT/OLN *Cc :* Dave Cridland; v6...@ietf.org mailto:v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion *Objet :* Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com mailto:mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. */[Med] I made this change:/* */ /* */OLD:/* */ /* This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). */ /* */New:/* */ /* This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). */ /* 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? */[Med] I used the same wording as in RFC6092. The change is as follows:/* */ /* */OLD:/* */ /* This document is not a standard. It uses the normative keywords only for precision. */ /* */NEW:/* */ /* NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. */ /* ___ v6ops mailing list v6...@ietf.org mailto:v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: Practical issues deploying DNSSEC into the home.
Paul Wouters p...@cypherpunks.ca wrote: /dev/random references into /dev/urandom. You are most likely better of giving the device a webgui and using the clients javascript to generate randomness. (yes I know, I just said to use javascript for private keys) I agree --- generate the certificates in the web UI. I don't think that this needs the private key to be created in javascript, just for a .js function to collect some entropy and push it into /dev/random. But I'm still thinking of a scheme involving insecure ntp lookups for pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow down the current time. Of course, all of that is vulnerable to replay attacks. I think that the best bet is to just turn off the time part of the DNSSEC validation until the time is considered sane. That limits the replay attack that can be done to replaying previous values for pool.ntp.org. The IP addreses returned might no longer be NTP clocks, and this could be annoying for those IPs involved, if there was some kind of widespread denial of service attack. Note that the NTP transaction is not protected at all by the DNSSEC, so if the attacker is on-path and can do this replay attack, they can also just attack the NTP transaction. Also, I believe the rasberry pi's, having the same problem, have a hwclock service that saves a timestamp on shutdown to the filesystem and loads it on boot. That solves the issue for quick reboots. That also prevents going backwards in time, which is good. Storing it in config eeprom may be better than flash. Another method is the last access time of the filesystem. But I'm not sure if that's a linux/ext4+ only feature, or whether the filesystems in embedded devices have a similar value stored somewhere. In general, they want to avoid any writes to the flash, so updating that value is a not desireable. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp6bbR419buV.pgp Description: PGP signature
Re: not really pgp signing in van
On Sep 10, 2013, at 12:32 PM, Phillip Hallam-Baker hal...@gmail.com wrote: The CA NEVER ever gives the user the key in any of the systems I have worked on. This appears to be untrue. Comodo offers that exact service today. https://secure.comodo.com/products/!SecureEmailCertificate_Signup The Comodo service generates the key pair for you. This means that they have your private key. We would hope that they would behave responsibly, but we don't have the assurance we would have if we generated the key pair and sent them only the public half. Eliminate the CA and you eliminate the parties with the incentive to sell the solution. Who cares? You can't get people to buy what they don't want. Whatever scheme is picked to complete secure email there is going to be a problem finding end users certs and end user policies. And there may be a market for solving that problem just like there is a market for blocking spam. There is a market for it, but right now it's very small, because nobody but people whose activities _require_ a secure channel are interested in the product.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
From: Owen DeLong o...@delong.com To: Vízdal Aleš ales.viz...@t-mobile.cz Cc: v6...@ietf.org WG v6...@ietf.org; IETF Discussion ietf@ietf.org; Dave Cridland d...@cridland.net Sent: Tuesday, 10 September 2013 7:04 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt(InternetProtocol Version 6 (IPv6) Profile for 3GPP MobileDevices) toInformational RFC snip Why is there such a push to do this? [av] Because the Operators are currently missing such a document, so they went to the IETF to work on one. As written in the document the number of well behaving IPv6 capable mobile devices is not very high at the moment. This initiative is intended to help the developers. Is there any reason a cellphone shouldn't just meet the standard requirements like any other router? I agree with this view. I don't think there is anything that special about portable computers that that can make phone calls (mobile multihomed hosts*). It seems to me the only thing special here is that one of the links the MMHH has is a 3G/4G etc. one, and the operators of those networks have certain views on how those networks should operate. That would seem to me to give them the ability to select what parameters are chosen for IPv6 operation over their networks e.g., stateful DHCPv6 only, prefix lifetimes of 2/1 hours etc., but to extend that to listing IPv6 protocol implementation requirements across the whole MMHH seems excessive and unnecessary. Surely the existing IPv6 node requirements RFC is enough for that? Regards, Mark. *The Rapid Rise of the Mobile Multihomed Host, and what it might mean to the network http://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf
Re: Practical issues deploying DNSSEC into the home.
Paul Wouters p...@cypherpunks.ca wrote: One solution is tlsdate which uses the installed bundled CA (or comes with its own) and runs TLS against a bunch of well known large sites (using insecure DNS) and sets the time based on the TLS handshakes. I believe tlsdate currently only gets the time from one server. It would be nice if it could determine the time based on agreement of a quorum of diverse servers, so that no single source of time needs to be trusted. (I have talked about this with Jacob Appelbaum but I haven't had time to do anything about it.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: not really pgp signing in van
On Tue, Sep 10, 2013 at 1:18 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 10, 2013, at 12:32 PM, Phillip Hallam-Baker hal...@gmail.com wrote: The CA NEVER ever gives the user the key in any of the systems I have worked on. This appears to be untrue. Comodo offers that exact service today. https://secure.comodo.com/products/!SecureEmailCertificate_Signup The Comodo service generates the key pair for you. This means that they have your private key. We would hope that they would behave responsibly, but we don't have the assurance we would have if we generated the key pair and sent them only the public half. You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. The service could send you an ActiveX keygen control with a backdoor but I am not on Windows right now. I generated the keypair on Chrome and I have all runtime objects turned off. The CA returns the signed certificate to you, but that is the public key part. -- Website: http://hallambaker.com/
Re: not really pgp signing in van
On Tue, Sep 10, 2013 at 05:47:55PM -0400, John R Levine wrote: I think we're entering the tinfoil zone here. Comodo is one of the largest CAs around, with their entire income depending on people paying them to sign web and code certs because they are seen as trustworthy. You might want to watch first half of Moxie Marlinspike's presentation at Black Hat 2011, SSL And The Future Of Authenticity. It's not entirely clear to me that his proposed solution is the correct one, but his problem statement of why CA's can't be trusted to do a good job can be found here: http://www.youtube.com/watch?v=Z7Wl2FW2TcA How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? Watch the video; note that removing Comodo from the list of acceptable CA's is really not practical, so there really is no incentive for them to do a good job. - Ted
Re: Practical issues deploying DNSSEC into the home.
On 11/09/2013 09:59, Olafur Gudmundsson wrote: ... My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. Hopefully you also flush the DNS cache as soon as NTP runs. Even so, paranoia suggests that a dodgy IP address might still be cached in some app. Brian
Re: not really pgp signing in van
perhaps you remember the Comodo CA fraud problem? http://arstechnica.com/security/2011/03/how-the-comodo-certificate-fraud-calls-ca-trust-into-question/ /bill On 10September2013Tuesday, at 14:47, John R Levine wrote: You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair. I think we're entering the tinfoil zone here. Comodo is one of the largest CAs around, with their entire income depending on people paying them to sign web and code certs because they are seen as trustworthy. How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly.
Re: not really pgp signing in van
On 10 September 2013 11:36, Ted Lemon ted.le...@nominum.com wrote: So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair. It's actually far worse than that when you consider the inherent mutability of JavaScript. The WebCrypto API should go a long way to addressing your concerns though.
Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote: As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management. TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better. Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use. In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed. A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec. Dear Phillip, It seems many of the larger providers are unwilling to process SPF macros due to inherent risks and inefficiency. Rather than accessing data using the DNS resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to utilize an additional domain, IP address, and email address input parameters merged with results generated from a series of proscribed DNS transactions. The macro feature was envisioned as leveraging these additional inputs to influence query construction. It seems lack of support by large providers has ensured scant few macros are published. in the beginning, there were several wanting a macro language to managing DNS processing with little idea where this would be headed. At the time there was already a dedicated binary resource record able to fully satisfied the information now obtained and used from SPF. Policy aspects of SPF are largely ignored due to exceptions often required. An SRV resource record resolving the location of a service could include an APL RR with CIDR information of all outbound IP addresses. This would offer load balancing and system priorities, while mapping outbound address space within two DNS transactions instead of the 111 recursive transactions expected by SPF. If one were starting over, DANE TLS or DTLS is a better solution that should be even easier to administer since it avoids a need to trust IP addresses and NATs. As with PKI, there are too many actors influencing routing's integrity. Regards, Douglas Otis
Re: not really pgp signing in van
On Tue, Sep 10, 2013 at 6:06 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 10, 2013, at 5:47 PM, John R Levine jo...@taugh.com wrote: How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? I don't know. What happens if they are served with an NSL? Well I do not have access to the operational side of Comodo so I do not have direct knowledge. However I have no need of the money so if I had knowledge of an NSL that I found unconscionable then I would stop working for them. I certainly don't think they'd *choose* to do anything like this, but what if it's that or jail? Remember, we know of at least one case of a business owner being threatened with jail because he closed his business rather than do precisely what we are discussing. I don't think an NSL can require me to work for a company and since I am a foreign national I am not obliged to live in the country. Low level government functionaries rarely attempt goon tactics on people who are relatives of cabinet ministers and have personal friends on both front benches in parliament. Remember too that the NSL doesn't even have to be served to the CEO—it could as easily be served to a geek on staff. It's horrible to contemplate that such a thing might happen, but based on what we know at this point, it's not unreasonable to include this in our risk model. It is _definitely_ not in the tin foil hat zone anymore. Could be but I have been working through what we know versus what would be required and I really can't see how a group of people who would let Snowden loose on their innermost secrets would be able to keep a conspiracy that required CAs or Gmail staff or the like to participate on the scale required. All they would need to achieve the results as we know them from PRISM is the knowledge of where the fiber optic cables run and a large back hoe. -- Website: http://hallambaker.com/
Re: Practical issues deploying DNSSEC into the home.
Hi Jim, At 08:55 10-09-2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. That problem has been bothering me for a while. There can be a leap of faith at startup to get the correct time. DNSSEC can be done after that. Regards, -sm
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. 2. So watered down in its language as to use many words to say nearly nothing. 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. Why is there such a push to do this? Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:24 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document is not a standard. It uses the normative keywords only for precision. NEW: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: Practical issues deploying DNSSEC into the home.
I faced this problem in Omnibroker. One answer is that DNS is an infrastructure for resolving Internet labels to Internet resources including IP addresses. It is thus the only Internet infrastructure where infrastructure providers may reasonably be expected to maintain long term IP addresses by nature of their function. So in omnibroker, the idea is that it is a protocol to replace the communication between a client and a recursive resolver. This allows the addition of security features that are essential in the client-resolver loop that the DNS protocol does not provide and it is pointless to attempt to add. For example, mutual authentication. If the DNS resolver is going to do recursive resolution and DNSSEC validation then it had better validate the clients from which it accepts queries or it will get DoS attacked very quickly. To support the mutual auth between the omnibroker client and service I establish a context that consists of a set of services which each specify an IP address, port and shared secret. This means that it is very easy to support an authenticated 'time check' protocol. For cryptographic purposes we don't particularly care about the clocks being synchronized to better than a minute.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Sep 9, 2013, at 13:36 , Vízdal Aleš ales.viz...@t-mobile.cz wrote: Please see inline. Ales From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, September 09, 2013 10:07 PM To: mohamed.boucad...@orange.com Cc: v6...@ietf.org WG; Dave Cridland; IETF Discussion Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. [av] Strongly disagree. The IETF as the IPv6 owner is the right place to define what qualifies a device to be IPv6 compliant. (a mobile one in this case) This is intended as informational, not a standards track document, so it does not do that. 2. So watered down in its language as to use many words to say nearly nothing. [av] Hints on how the text shall be changed are always welcome. If you don't leave it watered down, it becomes a standards track document. There appears to be even greater resistance to that, so I don't see such a document as being likely to achieve any greater degree of consensus. 3. Claims to be informational, but with so many caveats about the nature of that information that it's hard to imagine what meaningful information an independent reader could glean from the document. [av] The reader will learn what must/should/may be implemented in a mobile device to support IPv6. Except that this document is clearly marked as informational and not standards track and there fore the application of must/should/may to it is seemingly rather absurd. Finally, given the spirited debate that has extended into this last call (which I honestly wonder how this ever saw last call over the sustained objections) definitely does not appear to have even rough consensus, nor does it appear to have running code. [av] Med has posted an answer on this one earlier in the thread. I was not entirely satisfied with his answer. Why is there such a push to do this? [av] Because the Operators are currently missing such a document, so they went to the IETF to work on one. As written in the document the number of well behaving IPv6 capable mobile devices is not very high at the moment. This initiative is intended to help the developers. Is there any reason a cellphone shouldn't just meet the standard requirements like any other router? Owen Owen On Sep 9, 2013, at 05:16 , mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : lundi 9 septembre 2013 13:24 À : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6...@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document is
Re: not really pgp signing in van
On Tue, Sep 10, 2013 at 2:36 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker hal...@gmail.com wrote: You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair. I didn't say it was pretty. But it is subject to exactly the same potential compromise a proprietary PGP is. The problem is not merely that the CA might obtain the private key. A compromised key generation mechanism could leak bits of the seed in the modulus. The problem is lack of transparency in key generation and that is common to all email security programs right now. -- Website: http://hallambaker.com/
Re: Practical issues deploying DNSSEC into the home.
On 2013-09-10, at 12:58, Michael Richardson mcr+i...@sandelman.ca wrote: But I'm still thinking of a scheme involving insecure ntp lookups for pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow down the current time. Of course, all of that is vulnerable to replay attacks. I think that the best bet is to just turn off the time part of the DNSSEC validation until the time is considered sane. That's what we propose, in essence, in draft-jabley-dnsop-validator-bootstrap: 3. Summary of Approach A validator that has no valid trust anchor initialises itself as follows. 3.1. Initial State A validator in its initial state is capable of sending and receiving DNS queries and responses, but is not capable of validating signatures received in responses. A validator must confirm that its local clock is sufficiently accurate before trust anchors can be established, and before processing of DNSSEC signatures can proceed. Discussion of timing considerations can be found in Section 4. 3.2. Trust Anchor Retrieval Once the local clock has been synchronised, a validator may proceed to gather candidate trust anchors for consideration. Discussion of trust anchor retrieval can be found in Section 5. 3.3. Trust Anchor Selection Once a set of candidate trust anchors has been obtained, a validator attempts to find one trust anchor in the set which is appropriate for use. This process involves verification of cryptographic signatures, and is discussed in Section 6. 3.4. Full Operation The validator now has an accurate trust anchor for the root zone, and is capable of validating signatures on responses from the DNS. We specify clock sync before trust anchor retrieval because trust anchors are published in a bundle with date ranges within which they should be considered suitable for use. Clock sync before validation makes sense for reasons already mentioned. Joe
Re: Practical issues deploying DNSSEC into the home.
Jim: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. NTP can be used to get time from an IP address. I understand all of the reasons why a DNS name is preferred, but this a bootstrapping problem. RFC 5906 offers a way for NTP responses to be authenticated. So, if the IP address points to a NTP server that will give back a signed response, then the solution seems pretty straightforward. Of course, the vendor will need to make sure that one or more NTP servers are available, and make sure that the public keys are in place to validate the signed NTP responses. Over time these could change, but that could be handled by firmware updates. Many installation procedures include fetching the latest firmware, but DNS and routing need to be working for that to work in this bootstrap environment. Hopefully the firmware is authenticated too. RFC 4108 offers one approach to solving that problem. Russ
Re: pgp signing in van
On Mon, 9 Sep 2013, Fernando Gont wrote: It might be worth thinking about why ssh and ssl work so well, and PGP/GPG don't. Just a quick guess: SSL works automagically, PGP doesn't. So even if the user doesn't care, SSL is there. PGP, OTOH, usually requires explicit installation of a plug in and weird stuff (for mere mortals) such as generating keys, etc. Related (does not take away the full pain): http://tools.ietf.org/html/draft-wouters-dane-openpgp-00 Paul
Practical issues deploying DNSSEC into the home.
Ted T'so referred to a conversation we had last week. Let me give the background. Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki). Of course, we both want things other than just bufferbloat, as you can see by looking at that page (and you want to run in place of what you run today, given how broken and dated home router firmware from manufacturers generally is). Everything possible gets pushed upstream into OpenWrt as quickly as possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways. I was frustrated by Homenet's early belief's (on no data) that lots of things weren't feasible due to code/data footprint; both Dave and I knew better from previous work on embedded hardware. As example, Dave put a current version of bind 9 into the build (thereby proving that having a full function name service in your home router was completely feasible; that has aided discussions in the working group) since. We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of the enemy of the good is the perfect, but certainly I'm now much more paranoid than I once was. See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj Jim
Re: not really pgp signing in van
On Sep 10, 2013, at 2:19 PM, Phillip Hallam-Baker hal...@gmail.com wrote: You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair.
Re: Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Brian E Carpenter wrote: On 11/09/2013 09:59, Olafur Gudmundsson wrote: ... My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. Hopefully you also flush the DNS cache as soon as NTP runs. Even so, paranoia suggests that a dodgy IP address might still be cached in some app. I think you can avoid that issue by having the device not pass traffic until the DNSSEC validation is enabled. Only the device needs the special permissive handling for this to work.
Re: not really pgp signing in van
On Sep 10, 2013, at 5:47 PM, John R Levine jo...@taugh.com wrote: How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? I don't know. What happens if they are served with an NSL? I certainly don't think they'd *choose* to do anything like this, but what if it's that or jail? Remember, we know of at least one case of a business owner being threatened with jail because he closed his business rather than do precisely what we are discussing. Remember too that the NSL doesn't even have to be served to the CEO—it could as easily be served to a geek on staff. It's horrible to contemplate that such a thing might happen, but based on what we know at this point, it's not unreasonable to include this in our risk model. It is _definitely_ not in the tin foil hat zone anymore.
Re: not really pgp signing in van
On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker hal...@gmail.com wrote: Could be but I have been working through what we know versus what would be required and I really can't see how a group of people who would let Snowden loose on their innermost secrets would be able to keep a conspiracy that required CAs or Gmail staff or the like to participate on the scale required. You don't need a conspiracy. You just need to threaten the right person with jail. And yes, apparently they think they can throw you in jail for quitting your job, if they asked you to do something for them and you quit to avoid doing it. I am fairly sure that this law is unconstitutional; if you are independently wealthy and think you can avoid having your assets frozen, I encourage you to arrange to get served with an NSL and then challenge it in court. Nevertheless, your optimism about this problem is not an optimism that I share, and apparently I am not alone in my pessimism. You can certainly argue that the IETF need not address this threat model, but I don't agree with you, and your assurances that it's all perfectly okay are not swaying me... :)
Re: Practical issues deploying DNSSEC into the home.
On 2013-09-10, at 16:52, Russ Housley hous...@vigilsec.com wrote: NTP can be used to get time from an IP address. I understand all of the reasons why a DNS name is preferred, but this a bootstrapping problem. Retrieval of root zone KSK trust anchors requires a DNS name, however (and you can't assume that the active KSK when the router left the factory is the same as the active KSK when the router was taken out of the box). Joe
Re: not really pgp signing in van
You go to a Web page that has the HTML or Javascript control for generating a keypair. But the keypair is generated on the end user's computer. So I run Javascript provided by Comodo to generate the key pair. This means that my security depends on my willingness and ability to read possibly obfuscated Javascript to make sure that it only uploads the public half of the key pair. I think we're entering the tinfoil zone here. Comodo is one of the largest CAs around, with their entire income depending on people paying them to sign web and code certs because they are seen as trustworthy. How likely is it that they would risk their reputation and hence their entire business by screwing around with free promo S/MIME certs? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. smime.p7s Description: S/MIME Cryptographic Signature
Re: Practical issues deploying DNSSEC into the home.
[cc'ed to a more approriate IETF wg] On Sep 10, 2013, at 11:55 AM, Jim Gettys j...@freedesktop.org wrote: Ted T'so referred to a conversation we had last week. Let me give the background. Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki). Of course, we both want things other than just bufferbloat, as you can see by looking at that page (and you want to run in place of what you run today, given how broken and dated home router firmware from manufacturers generally is). Everything possible gets pushed upstream into OpenWrt as quickly as possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways. I was frustrated by Homenet's early belief's (on no data) that lots of things weren't feasible due to code/data footprint; both Dave and I knew better from previous work on embedded hardware. As example, Dave put a current version of bind 9 into the build (thereby proving that having a full function name service in your home router was completely feasible; that has aided discussions in the working group) since. We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of the enemy of the good is the perfect, but certainly I'm now much more paranoid than I once was. See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj Jim My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. see: https://www.dnssec-deployment.org/index.php/2012/03/a-validating-recursive-resolver-on-a-70-home-router/ We also discovered that some cheap devices like this will do NTP at startup and never again that combined with long up-time and bad clocks caused the Validators to start rejecting signatures due to the time on the signatures. The big issue is that validator implementors assume that it runs on good hardware with good links, thus it is safe to enable DNSSEC out of the gate. We need either have resolvers come up in recursive mode and tool like dnsec-trigger or our scripts change the behavior to validator after that has been deemed safe, or build the checking into the validators. The same can be said of devices that have been installed from media or have been turned off for a long time (say month or more), in these cases starting up in validating mode only only turns the device into a brick. Olafur
Last Call: draft-ietf-tsvwg-byte-pkt-congest-11.txt (Byte and Packet Congestion Notification) to Best Current Practice
The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Byte and Packet Congestion Notification' draft-ietf-tsvwg-byte-pkt-congest-11.txt as Best Current Practice 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 2013-09-24. 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. Abstract This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including random early detection (RED), BLUE, pre- congestion notification (PCN) and newer schemes such as CoDel and PIE. We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'ALTO Server Discovery' to Proposed Standard (draft-ietf-alto-server-discovery-10.txt)
The IESG has approved the following document: - 'ALTO Server Discovery' (draft-ietf-alto-server-discovery-10.txt) as Proposed Standard This document is the product of the Application-Layer Traffic Optimization Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ Technical Summary The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. Working Group Summary The draft was discussed extensively in the WG meetings as well as on the mailing list. This particular document was the result of a merge of a draft discussing first-party discovery and another draft discussing third party discovery. However, as the merged draft proceeded through the WG, it became clear that unifying first- and third-party discovery in a single draft is problematic. Therefore, the first- and third-party server discovery are now separate drafts, with the third-party server discovery appearing in its own draft. This implies that the draft under consideration (draft-ietf-alto-server-discovery) is focused on first-party ALTO server discovery. During the Atlanta IETF meeting (IETF 85, November 2012) it was pointed out that there is some work on using HTTPS GET mechanism to discover the location of a given type of service (draft-jones-simple-web-discovery), and perhaps draft-ietf-alto-server-discovery could use the mechanism mentioned in draft-jones-... instead of requiring a U-NAPTR lookup as is currently done. Discussion on the mailing list on this seem to weigh in favour of not using draft-jones-... since it is in its formative stages and there is nothing technically wrong with the specifications currently contained in draft-ietf-alto-server-discovery. At things stand right now, the WG is proceeding with draft-ietf-alto-server-discovery in its current state; proponents of the mechanism mentioned in draft-jones-... will describe in a draft on how they forsee using it in the general problem of ALTO server discovery. Subsequent to this, the WG can decide on next steps, i.e., whether to update the RFC that results from draft-ietf-alto-server-discovery or whether to publish a new and alternate first-party ALTO server discovery mechanism. Document quality: There are no known implementations of the mechanism specified in draft-ietf-alto-server-discovery, however, since this is a crucial aspect before ALTO services can be consumed, the WG believes that implementations will be forthcoming once the mechanism is stable (as it appears now to be). The document itself is well-written and reasonably precise. There is no need for a MIB doctor, or a media type expert. The document has been shared with a DNS expert who weighed in appropriately on Section 3 of the document. More specifically, Olafur Gudmundsson provided an expert review on November 16, 2011 addressing shortcomings in the -00 version of this draft. The authors addressed the comments from Olaf in -03 of the draft, and those changes have since been maintained as the draft progressed. Personnel Vijay K. Gurbani is the document shepherd and Spencer Dawkins is the responsible AD.
Last Call: draft-ietf-insipid-session-id-reqts-08.txt (Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks) to Informational RFC
The IESG has received a request from the INtermediary-safe SIP session ID WG (insipid) to consider the following document: - 'Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks' draft-ietf-insipid-session-id-reqts-08.txt as 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 2013-09-24. 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. Abstract This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1882/ http://datatracker.ietf.org/ipr/1883/ http://datatracker.ietf.org/ipr/1925/
Last Call: draft-ietf-mmusic-duplication-grouping-03.txt (Duplication Grouping Semantics in the Session Description Protocol) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Duplication Grouping Semantics in the Session Description Protocol' draft-ietf-mmusic-duplication-grouping-03.txt as 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 2013-09-24. 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. Abstract Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ballot/ No IPR declarations have been submitted directly on this I-D.
MPTCP WG Virtual Interim Meeting, 3 October 2013
The MPTCP WG will hold a virtual interim meeting on Thursday, 3rd October at 1500 GMT*. Agenda and WebEx information will be posted on the mailing list: http://www.ietf.org/mail-archive/web/multipathtcp/current/maillist.html * Time zone converter: http://www.worldtimeserver.com/convert_time_in_UTC.aspx
RFC 6987 on OSPF Stub Router Advertisement
A new Request for Comments is now available in online RFC libraries. RFC 6987 Title: OSPF Stub Router Advertisement Author: A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson Status: Informational Stream: IETF Date: September 2013 Mailbox:aret...@cisco.com, lhngu...@cisco.com, alex.zi...@gmail.com, russ.wh...@vce.com, dmcpher...@verisign.com Pages: 7 Characters: 10890 Obsoletes: RFC 3137 I-D Tag:draft-ietf-ospf-rfc3137bis-04.txt URL:http://www.rfc-editor.org/rfc/rfc6987.txt This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document obsoletes RFC 3137. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: draft-ietf-mmusic-delayed-duplication-02.txt (Delayed Duplication Attribute in the Session Description Protocol) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Delayed Duplication Attribute in the Session Description Protocol' draft-ietf-mmusic-delayed-duplication-02.txt as 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 2013-09-24. 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. Abstract A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/ballot/ No IPR declarations have been submitted directly on this I-D.
