Re: Last Call: draft-ietf-repute-query-http-09.txt (A Reputation Query Protocol) to Proposed Standard
On Thu, Aug 15, 2013 at 10:13 AM, SM s...@resistor.net wrote:
The draft-iet-repute-model reference is a down-ref.
I agree, the model document should be considered for PS instead.
A server receiving a query about an application it does not
recognize or explicitly support support (e.g., by virtue of
private agreements or experimental extensions) MUST return a
404 error code.
There is a typo: support support.
Fixed.
Are there other cases where a 404 is appropriate? I am asking the
question as there is a string of proposals built upon RFC 2616 which
attempt to use HTTP status codes to communicate errors for the layered
protocol.
I don't believe so. The only cases we can think of are those where the
supported application does or does not exist, and the service being queried
does or does not have data about the subject. Elsewhere we describe that
there's a specific mechanism to say in a valid reply that no data are
available, so that handles the second question. You only get to the second
question if the answer to the first is yes, which leaves the first answer
of no that needs handling specified.
In Section 3.2:
and SHOULD include an Expires field (see Section 14.21 of [HTTP])
indicating a duration for which the template is to be considered
valid by clients and not re-queried.
Why is this a RFC 2119 SHOULD? There is a SHOULD NOT following that
paragraph with a don't query for a day if there isn't an Expires field.
Wouldn't it be easier to have MUST include the Expires field?
An operator that calculates reputation values on demand would conceivably
give a new value for every query. If a client wants that up-to-the-moment
accuracy, then Expires is counterproductive. On the other hand, an
operator that calculates reputation values daily could indicate this by
setting an Expires field of either a day (86400) or the total time between
now and the next calculation.
The latter case is likely more prevalent, but it doesn't seem like saying
MUST and requiring a value of 0 for the former case is strictly the right
solution.
The template file might contain more than one template. Such a file
MUST have each template separated by a newline (ASCII 0x0D)
character.
As this is line oriented it may be better to have CRLF.
Why is that?
In Section 3.3:
A server SHOULD include support for providing service over HTTP
Is there a case where the service with work if the server does not support
HTTP?
A client could support HTTP for the template retrieval but only HTTPS for
the service itself, for all the usual privacy and security reasons.
In Section 5:
The reputation service itself will use HTTP or other transport
methods to issue queries and receive replies. Those protocols have
registered URI schemes and, as such, presumably have documented
security considerations.
This is odd. What other protocols are there to retrieve the URI template?
Any URI scheme is supported. Only HTTP/HTTPS are currently implemented at
the moment.
If I understood the draft, the Proposed Standard angle is:
http://{service}/{application}**/{subject}/{assertion}
with a application/reputon+json response. Why should that be a Proposed
Standard?
That's not the angle, it's one possible template.
Does it not qualify as a Proposed Standard? If not, why not? Will it fail
to interoperate?
-MSK
Re: Last Call: draft-ietf-repute-email-identifiers-08.txt (A Reputation Response Set for Email Identifiers) to Proposed Standard
On Thu, Aug 15, 2013 at 10:24 AM, SM s...@resistor.net wrote: draft-ietf-repute-model is a down-ref. I suggest referencing the updated SPF specification as that specification is said to fix some issues in RFC 4408. The downref was discussed on another thread. I left the reference to RFC4408 as is because I was unclear on the timing of the processing of this document versus RFC4408bis. I'm fine with making that change if Pete thinks it's the right choice at this point. Why is DKIM and SPF normatively referenced while SMTP is an informative reference? Yes, they should probably all be the same. Will fix. Section 5 states that the draft is primarily an IANA action and doesn't describe any protocols or protocol elements. Why is the intended status Proposed Standard? It may not need that status given some of the material that was originally here has been moved to the other WG documents. I'll defer to the chairs or the AD on that one. -MSK
Re: Last Call: draft-ietf-repute-media-type-10.txt (A Media Type for Reputation Interchange) to Proposed Standard
On Thu, Aug 15, 2013 at 10:40 AM, SM s...@resistor.net wrote: From Section 3.1: expires: A timestamp indicating a time beyond which the score reported is likely not to be valid. Expressed as the number of seconds since January 1, 1970 00:00 UTC. See Section 5 for discussion. And Section 5: 'A reputon can contain an expires field indicating a timestamp after which the client SHOULD NOT use the rating it contains, and SHOULD' The expires field uses HTTP-date. It is easier to code for one timestamp format instead of two (see Unix timestamp in Section 3.1). By that I assume you mean the Expires field in the HTTP exchange, and not this value. An HTTP exchange can contain multiple reputons. The expiration timestamp might be different for each. In Section 3.1: An application service provider might operate with an enhanced form of common services, which might in turn prompt development and reporting of specialized reputation information. I don't see anything actionable in the above. Taken out of context, of course not. The text that follows indicates that the default set of reputon attributes might not be sufficient for describing all of the information needed in a reputon for a given application space. It could be necessary to document additional attributes and their syntaxes and semantics for those applications. Those need to be done in separate documents that register those applications. Why was specification required chosen for the Reputation Applications Registry? As alluded to above, there can be quite a bit of information needed for an application to be defined beyond the defaults assumed when a name is registered. There didn't seem to be any need to require such definition to be in an IETF document, but it also seems as though more information than what's needed with just FCFS or DE or the other lesser rules is appropriate either. -MSK
Re: Last Call: draft-ietf-repute-model-07.txt (A Model for Reputation Reporting) to Informational RFC
On Thu, Aug 15, 2013 at 11:24 AM, SM s...@resistor.net wrote: The Privacy Considerations Section focuses on data in transit and collection of data only. Section 8.1 mentions protecting the data from unauthorized access and viewing. That would only be unauthorized viewing while the data is in transit. Sure, mentioning something about the stored aggregated data also makes sense in Section 8. I'll add something. I don't know whether people overlook this; the queries leak out information. Information which the user might consider as private is sent out without the person's knowledge. I suggest pushing that discussion to the specification which defines the identity (e.g. draft-ietf-repute-email- **identifiers-08). I don't think this point is specific to email identifiers. This is the right place to say it. As a general comment I would say that the issue is less about privacy and more about reputation. There is a saying: Tell me what you read and I will tell you who you are. Reputations can certainly be private things, both as an aggregate result and as the pieces of data that allowed that result to be reached. But I don't think that's a new point given the above. The new text will cover it. -MSK
Re: [spfbis] 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 Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: 2011/07/30 08:07:51 spf: 2, txt: 1, 200.00% 2011/08/10 21:28:41 spf: 4, txt: 121, 3.305785% 2011/08/14 21:30:11 spf: 1, txt: 45, 2.22% 2011/08/16 17:20:40 spf: 0, txt: 5, 0.00% 2011/08/17 00:53:42 spf: 1, txt: 1, 100.00% 2011/08/19 01:10:53 spf: 0, txt: 6, 0.00% 2011/08/21 03:09:09 spf: 27, txt: 45, 60.00% 2011/09/13 04:25:21 spf: 30, txt: 113, 26.548673% 2011/09/15 16:19:41 spf: 3, txt: 16, 18.75% 2011/09/15 17:16:35 spf: 0, txt: 3, 0.00% 2011/09/22 18:35:07 spf: 6, txt: 22, 27.272727% 2011/09/26 19:08:48 spf: 0, txt: 7, 0.00% 2011/09/30 01:02:42 spf: 1, txt: 7, 14.285714% 2011/10/10 03:53:19 spf: 42, txt: 157, 26.751592% 2011/10/20 00:39:06 spf: 2, txt: 14, 14.285714% 2011/10/31 19:08:55 spf: 5, txt: 141, 3.546099% 2011/11/02 20:37:05 spf: 0, txt: 16, 0.00% 2011/11/15 17:15:38 spf: 8, txt: 196, 4.081633% 2011/11/30 19:04:48 spf: 47, txt: 335, 14.029851% 2011/12/12 22:18:55 spf: 1, txt: 294, 0.340136% 2011/12/25 16:04:50 spf: 16, txt: 611, 2.618658% 2011/12/29 17:58:19 spf: 1, txt: 2, 50.00% 2012/01/12 01:15:17 spf: 2, txt: 52, 3.846154% 2012/01/18 22:24:14 spf: 0, txt: 60, 0.00% 2012/01/30 00:45:27 spf: 2, txt: 121, 1.652893% 2012/02/02 17:18:54 spf: 54, txt: 288, 18.75% 2012/02/10 23:59:02 spf: 0, txt: 102, 0.00% 2012/02/23 00:52:47 spf: 20, txt: 201, 9.950249% 2012/03/19 03:17:46 spf: 118, txt: 580, 20.344828% 2012/03/24 18:33:15 spf: 2, txt: 46, 4.347826% 2012/04/13 16:41:10 spf: 121, txt: 1743, 6.942054% 2012/05/19 18:20:14 spf: 54, txt: 631, 8.557845% 2012/06/07 13:52:26 spf: 82, txt: 961, 8.532778% 2012/07/05 02:48:39 spf: 26, txt: 339, 7.669617% 2012/07/05 18:24:30 spf: 0, txt: 4, 0.00% 2012/07/07 19:21:02 spf: 3, txt: 25, 12.00% 2012/07/17 14:48:32 spf: 3, txt: 156, 1.923077% 2012/08/07 18:19:36 spf: 7, txt: 269, 2.602230% 2012/08/19 04:38:08 spf: 23, txt: 198, 11.616162% 2012/08/31 21:23:20 spf: 27, txt: 190, 14.210526% 2012/10/21 07:45:13 spf: 185, txt: 1285, 14.396887% 2012/12/07 21:59:04 spf: 74, txt: 704, 10.511364% 2012/12/11 18:28:28 spf: 0, txt: 24, 0.00% 2012/12/31 07:51:05 spf: 52, txt: 436, 11.926606% 2013/01/08 00:30:31 spf: 10, txt: 119, 8.403361% 2013/02/02 01:30:47 spf: 22, txt: 341, 6.451613% 2013/02/16 06:44:53 spf: 20, txt: 143, 13.986014% 2013/02/28 01:58:33 spf: 11, txt: 153, 7.189542% 2013/03/05 02:38:51 spf: 5, txt: 75, 6.67% 2013/03/08 23:47:17 spf: 0, txt: 99, 0.00% 2013/03/09 02:21:46 spf: 1, txt: 1, 100.00% 2013/03/20 01:29:03 spf: 46, txt: 1232, 3.733766% 2013/03/24 06:22:59 spf: 15, txt: 212, 7.075472% 2013/03/26 06:03:50 spf: 0, txt: 11, 0.00% 2013/03/31 23:17:16 spf: 8, txt: 208, 3.846154% 2013/04/06 05:19:48 spf: 37, txt: 587, 6.303237% 2013/04/07 21:53:19 spf: 1, txt: 37, 2.702703% 2013/04/16 18:50:43 spf: 13, txt: 279, 4.659498% 2013/04/22 05:52:43 spf: 3, txt: 163, 1.840491% 2013/04/29 17:56:04 spf: 14, txt: 440, 3.181818% 2013/05/22 16:26:40 spf: 20, txt: 606, 3.300330% 2013/05/23 12:08:25 spf: 1, txt: 9, 11.11% 2013/05/23 12:30:12 spf: 0, txt: 1, 0.00% 2013/05/28 19:14:02 spf: 21, txt: 380, 5.526316% 2013/07/01 02:29:15 spf: 51, txt: 2246, 2.270703% 2013/07/01 15:02:05 spf: 2, txt: 16, 12.50% 2013/07/07 04:50:19 spf: 0, txt: 109, 0.00% 2013/07/24 01:09:39 spf: 36, txt: 1395, 2.580645% totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
RE: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Contr
Hi Adrian, Thanks very much. I can update the nits and editorial issues quickly, but I would like to discuss more with you for the following points to make things clear before I update the draft. = Please consider and note what updates to GMPLS management tools are needed. [Fatai]This has been mentioned in [Framework] document. Did you mean that we need add one sentence in some place of this document to refer to [Framework] document to mention management tools? Are there any changes to the Alarms that might arise? We have a document for that. [Fatai] No. RFC4783 is still applicable. Are there any changes to the way OAM is controlled? We have a document for that. [Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext]. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. [Fatai] Will do that. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? [Fatai] I am not sure. I asked the similar question (not on this draft) during Berlin meeting. The chairs answered that it could be driven by drafts. Best Regards Fatai -Original Message- From: ccamp-boun...@ietf.org [mailto:ccamp-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, August 21, 2013 2:51 AM To: ietf@ietf.org Cc: cc...@ietf.org Subject: Re: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard As sponsoring AD I have the following last call comments I hope you will take on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand OTN on first use in the main text. Please expand TS on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing subobject. --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. ___ CCAMP mailing list cc...@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
Re: TCPMUX (RFC 1078) status
On 20/08/13 17:01, Joe Touch wrote: However, see my other message - it's hard to recommend an approach when we don't understand the problem you're trying to solve. The scenario is simple. You want admin to open one port in the firewall when the project is started. Going through the corporate process at this point is bearable and makes sense. Afterwards, you want to be able to expose arbitrary services through that port without having to go through port-opening process over and over again. The services are actually different aspects of the same distributed application, say, data distribution service, management service, heartbeating service etc. so not requiring additional process for adding them makes sense. The real problem here IMO is how to distinguish between adding a completely new application -- which should require approval process -- and adding a new component within an existing distributed application -- which should be managed by devs themselves. Martin
Re: Last Call: draft-ietf-repute-query-http-09.txt (A Reputation Query Protocol) to Proposed Standard
At 23:53 20-08-2013, Murray S. Kucherawy wrote: I don't believe so. The only cases we can think of are those where the supported application does or does not exist, and the service being queried does or does not have data about the subject. Elsewhere we describe that there's a specific mechanism to say in a valid reply that no data are available, so that handles the second question. You only get to the second question if the answer to the first is yes, which leaves the first answer of no that needs handling specified. Ok. An operator that calculates reputation values on demand would conceivably give a new value for every query. If a client wants that up-to-the-moment accuracy, then Expires is counterproductive. On the other hand, an operator that calculates reputation values daily could indicate this by setting an Expires field of either a day (86400) or the total time between now and the next calculation. The latter case is likely more prevalent, but it doesn't seem like saying MUST and requiring a value of 0 for the former case is strictly the right solution. I see what you mean. The server-specified expiration (see RFC 2616) uses other headers as well. Why is that? The media type is text/plain. A client could support HTTP for the template retrieval but only HTTPS for the service itself, for all the usual privacy and security reasons. Ok. Any URI scheme is supported. Only HTTP/HTTPS are currently implemented at the moment. Ok. That's not the angle, it's one possible template. Does it not qualify as a Proposed Standard? If not, why not? Will it fail to interoperate? The quick answer is that I am not sure. I'll defer to you. Regards, -sm
Re: Last Call: draft-ietf-repute-query-http-09.txt (A Reputation Query Protocol) to Proposed Standard
On Wed, Aug 21, 2013 at 12:43 AM, SM s...@resistor.net wrote: Why is that? The media type is text/plain. Ah. I realize that CRLF is standard line termination for SMTP; is it automatically the expected line termination for all line-oriented protocols? I don't know about others. -MSK
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy (sm+ietf@elandsys.c My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. There are several questions: (a) Was there an error in RFC 4408? Yes. (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record rôle vis à vis SPF. (c) Why was there an error in RFC 4408? (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not desirable. There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Apparently. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm using my X-RAY VISION to obtain a rare glimpse of the INNER WORKINGS of this POTATO!! signature.asc Description: Digital signature
RE: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Contr
Hi Fatai, I think you nicely answered your own questions :-) I would suggest adding a small section including all of the statements you made in your email. (Well, no need to refer to Berlin and the CCAMP chairs :-) Cheers, Adrian From: Fatai Zhang [mailto:zhangfa...@huawei.com] Sent: 21 August 2013 08:40 To: adr...@olddog.co.uk; ietf@ietf.org Cc: cc...@ietf.org Subject: RE: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard Hi Adrian, Thanks very much. I can update the nits and editorial issues quickly, but I would like to discuss more with you for the following points to make things clear before I update the draft. = Please consider and note what updates to GMPLS management tools are needed. [Fatai]This has been mentioned in [Framework] document. Did you mean that we need add one sentence in some place of this document to refer to [Framework] document to mention management tools? Are there any changes to the Alarms that might arise? We have a document for that. [Fatai] No. RFC4783 is still applicable. Are there any changes to the way OAM is controlled? We have a document for that. [Fatai] No, it could be done through NMS or [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext]. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. [Fatai] Will do that. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? [Fatai] I am not sure. I asked the similar question (not on this draft) during Berlin meeting. The chairs answered that it could be driven by drafts. Best Regards Fatai -Original Message- From: ccamp-boun...@ietf.org [mailto:ccamp-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, August 21, 2013 2:51 AM To: ietf@ietf.org Cc: cc...@ietf.org Subject: Re: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control) to Proposed Standard As sponsoring AD I have the following last call comments I hope you will take on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand OTN on first use in the main text. Please expand TS on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing subobject. --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling. ___ CCAMP mailing list cc...@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
Re: [spfbis] 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 21 aug 2013, at 09:17, David Conrad d...@virtualized.org wrote: On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: : : : totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data: $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95 1105 $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18 2819 I.e. 2819 queries for TXT while there was 1105 for SPF resource record. Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF. Deprecating something that is in use that much just does not make any sense. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Patrik, First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: * To what extent has that happened? The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. And another thing. Randy, is it your position that WGs shouldn't create new TXT records due to transition issues? Eliot On 8/21/13 12:15 PM, Patrik Fältström wrote: On 21 aug 2013, at 09:17, David Conrad d...@virtualized.org wrote: On Aug 20, 2013, at 9:00 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: The WG had a hard time coming up with really good data about what validators look for, ... If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. Out of morbid curiosity, I just looked at the logs from my name server (which has both TXT and SPF RRs but which is very, very far from being busy) with a quick perl hack: : : : totals: spf: 1389, txt: 19435, 7.146900% (the numbers are queries since the name server last restarted/dumped stats) Will look for better data than my measly little name server. I have been looking at the queries to one of the nameservers that Frobbit runs (which is authoritative for quite a number of zones, although not GoDaddy), and a tcpdump for a while today gives the following data: $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, only got 95 1105 $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l reading from file dns.pcap, link-type EN10MB (Ethernet) tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, only got 18 2819 I.e. 2819 queries for TXT while there was 1105 for SPF resource record. Now, I have no idea whether all of those queries for TXT was only for the SPF usage of TXT of course, but this gives it was at least 28% of (TXT+SPF)-queries that was for SPF. Deprecating something that is in use that much just does not make any sense. Patrik
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
So your point is that their conclusions that nobody has the record installed is false? Eliot On 8/21/13 12:42 PM, Patrik Fältström wrote: On 21 aug 2013, at 12:26, Eliot Lear l...@cisco.com wrote: The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. These are logs on one of my authoritative servers, and the queries you see are the queries sent _TO_ the server. So of course I also have the responses I give to the one those queries. Patrik
Re: [spfbis] 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 Wednesday, August 21, 2013 12:00:56 Måns Nilsson wrote: Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy (sm+ietf@elandsys.c My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. There are several questions: (a) Was there an error in RFC 4408? Yes. (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record rôle vis à vis SPF. (c) Why was there an error in RFC 4408? (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not desirable. There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Scott K
Gen-ART LC review of draft-ietf-repute-model-07
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-repute-model-07 Reviewer: Roni Even Review Date:2013-8-20 IETF LC End Date: 2013-8-29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. Nits/editorial comments: Section 3 the end of 2nd paragraph mechansisms to mechanisms
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
I object to the removal of the SPF record. Name servers already have access controls down to the granuality of TYPE. If this draft proceeds as currently described it is forcing name server vendors to access controls at the sub TYPE granuality. With SPF lookup first I can specify the SPF policy using SPF and leave TXT free for other uses without having to worry about the records being misinterpeted. SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF. This is similar to not proceeding to A/ lookups on MX lookup failures. I would also suggest that there be a sunset date published for the use of TXT for SPF. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
No hat On Wed, Aug 21, 2013 at 12:26:51PM +0200, Eliot Lear wrote: However, in this case, it is not in dispute that queries are happening. Actually, that _was_ in question. Remember, part of the justification for ditching TYPE99 is not only that publishers don't use it, but also that if they did there'd be no benefit. The evidence the WG produced was that there were hardly any validators querying for SPF. The WG originally had somewhat stronger claims in the draft, and I objected because I felt our sample wasn't good enough. The data that Patrik and David have presented suggest that there might indeed be more to the story, but again there are some issues with the samples. There are two additional things that would help make sense of these numbers. First, the raw number of queries isn't very interesting, if mail transactions all turn out to be with the same parties. We can't count the same party asking for TYPE99 twice as two validators. Second, how many of these TYPE99 queries arrive within the same time frame (yes, I'm waving my hands)? If the TYPE99 queries are being issued at the same time as the TXT record, that's an indication that the query source actually has no preference, and just wants the answer that comes fastest. The evidence that the WG looked at suggested that really only Yahoo preferred TYPE99, and that they stopped preferring it. There was one large mail system (I can't recall who) that sent TYPE99 queries, but actually sent both SPF and TXT at the same time in an effort to get the quickest response possible. As Scott has noted elsewhere in this thread, the SPF processing is often a blocking operation for mail systems, so latency added by two lookups in that processing is a big deal (particularly for very large systems). * To what extent has that happened? I'm not the shepherd, but it is undeniable that most current-era shipping DNS servers support RRTYPE 99. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com
Re: [spfbis] 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 08/21/2013 03:44 PM, Andrew Sullivan wrote: Speaking as the SPFBIS co-chair… On Wed, Aug 21, 2013 at 04:55:33AM -0700, manning bill wrote: to see if the trend has changed (modulo PAFs observations that not all TXT == SPF). In the mean time, declare a suspension of last call to gauge if the presumption of failure of the SPF RR merits this drastic action. I think this would have been a fair request for the LC of RFC 6686, which was presenting data about the state of the world at the time. We had a heck of a time getting people to review that document, to provide data, or to analyse the data. I think it's unfair to the WG to have refused to pitch in, and now to tell the WG that it has to sit on its hands and then do some more work later, particularly because these two data sets are hardly representative ones. If we're going to undertake a large scale data gathering experiment, I'll be all for it as soon as we have some really large mail system operators involved. (We did have those in SPFBIS, please note.) Just wondering, could OARC's recent DITL data help? (perhaps if only to see whether another large-scale targeted effort is needed) I definitely see TYPE=99 queries on our servers, but I can't see the answers. Jelte
Re: [spfbis] 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 Tue 20/Aug/2013 07:27:12 +0200 David Conrad wrote: On Aug 19, 2013, at 10:14 PM, Randy Bush ra...@psg.com wrote: one lesson i might take from this is, if i want to deploy a new hack which needs an rrtype, not to use txt in the interim. Nor the same format, IMHO. My personal belief is that the rationale to migrate away from TXT remains valid and the appropriate course of action is to fix the migration strategy, not permanently encode what everyone agrees is a hack into a proposed standard. Normally, it's easier to have new births than to revive dead horses. The proposed standard is what currently works. By the time DKIM keys are transmitted in binary, SPF will have a better spec too.
Re: WG overview - MILE video
Kathleen, Great idea, great job! Congratulations. Best regards, as On 8/21/13 10:16 AM, Moriarty, Kathleen wrote: Hello, Sometime before Berlin, I had suggested the use of a video to provide an overview of current work within a working group to see if that might be a useful tool. It was suggested, on this list, I should do this for MILE and see how it works out. While in Berlin, with the help of the fabulous MeetEcho team, we made a brief video and t is now posted as a link within the MILE charter. I'd like to collect feedback to see how useful it is and some may be anecdotal from lurkers who now better understand the work or maybe we'll see an increase in participation. http://datatracker.ietf.org/wg/mile/charter/ Thank you, Kathleen
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 also agree with James and Lorenzo. Owen On Aug 20, 2013, at 4:58 PM, james woodyatt j...@apple.com wrote: On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote: [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt j...@apple.com core os networking ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: TCPMUX (RFC 1078) status
On 8/21/2013 12:50 AM, Martin Sustrik wrote: On 20/08/13 17:01, Joe Touch wrote: However, see my other message - it's hard to recommend an approach when we don't understand the problem you're trying to solve. The scenario is simple. You want admin to open one port in the firewall when the project is started. Going through the corporate process at this point is bearable and makes sense. Afterwards, you want to be able to expose arbitrary services through that port without having to go through port-opening process over and over again. There's nothing new about multiplexing services over a single port; it's a known problem with a few common solutions: - dispatch the connections inside your system based on in-band info - initiate connections inside a handler, and transfer them to spawned subprocesses - use initial connections to exchange inband info for other connections on dynamic ports (as done in FTP) They each have their challenges. The services are actually different aspects of the same distributed application, say, data distribution service, management service, heartbeating service etc. so not requiring additional process for adding them makes sense. Each distinct, independently-useable service may warrant a new port or could all be muxed together. Which of these you seek is up to you. That's a design decision. The real problem here IMO is how to distinguish between adding a completely new application -- which should require approval process -- and adding a new component within an existing distributed application -- which should be managed by devs themselves. IMO it's easy - any group of services you want others to be able to use independently could justify a new port, but you can always mux them all together if you want to avoid additional firewall configuration issues. I.e., this is your call. But it doesn't appear to have anything to do with the notion of a single port to access any *existing* service, which is what TCPMUX and its descendants does. Joe
Re: TCPMUX (RFC 1078) status
On 8/21/2013 12:50 AM, Martin Sustrik wrote: ... You want admin to open one port in the firewall when the project is started. Going through the corporate process at this point is bearable and makes sense. Afterwards, you want to be able to expose arbitrary services through that port without having to go through port-opening process over and over again. One additional point - if you really mean arbitrary, including existing services, I hope you understand that a network operator that shuts down ANY current services would conclude they must then block yours too. I.e., if I don't want FTP over the firewall (because it uses cleartext passwords), I definitely don't want TCPMUX (which allows FTP), or any other accesses arbitrary services port. So that seems like a non-starter, unless by arbitrary you mean extensions within your system - which is how all current ports already work. Joe
Re: TCPMUX (RFC 1078) status
On 21/08/13 17:12, Joe Touch wrote: The real problem here IMO is how to distinguish between adding a completely new application -- which should require approval process -- and adding a new component within an existing distributed application -- which should be managed by devs themselves. IMO it's easy - any group of services you want others to be able to use independently could justify a new port, but you can always mux them all together if you want to avoid additional firewall configuration issues. So what would you use for muxing, if TCPMUX is not a good idea? I.e., this is your call. But it doesn't appear to have anything to do with the notion of a single port to access any *existing* service, which is what TCPMUX and its descendants does. Martin
Re: [spfbis] 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 Aug 21, 2013, at 7:17 AM, Patrik Fältström p...@frobbit.se wrote: My conclusion is that a statement that nobody queries for it is false. I am curious if the folks who did the analysis of query rates know the answers to the following questions: 1. Per unit of mail delivered (as opposed to per domain), for what percentage of delivered mail for which SPF TXT records exist do SPF RRtype records _also_ exist? I wasn't clear on whether an attempt was made to come up with an answer to this question. 2. Per unit of mail received, for what percentage of received mail does the receiver currently issue SPF RRtype queries. The reason I ask these questions is that the rationale for the decision made by the working group was that the data supported it, and I think that was a good rationale, but only if the data _actually_ supports it. But I don't think that the data was analyzed on the basis of units of mail delivered, but rather on the basis of number of queries seen. The reason I think the distinction is important is that as several people have observed, there are some heavy hitters in this discussion—Yahoo and Google, for example. If the heavy hitters all already publish the SPF RRtype, that might make a difference. Actually, I just checked. Right now, none of them seem to publish SPF RRtype records. Yahoo doesn't even publish a TXT record containing SPF information. An argument could be made that if we really wanted to push the adoption of SPF RRtypes, getting Google, Yahoo and Hotmail to publish SPF RRtype records would actually make it worthwhile to query SPF first, because most queries probably go to those domains. I think the people who are pushing for a different outcome than the spfbis working group arrived at would do a lot to make their case if they could use their collective influence to get these three domain owners to publish SPF RRtype records. This is a really easy thing to do; if it can't be done, that's a pretty clear indication that the SPF RRtype is doomed.
Re: [spfbis] 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 Wednesday, August 21, 2013 09:39:28 Andrew Sullivan wrote: ... * To what extent has that happened? I'm not the shepherd, but it is undeniable that most current-era shipping DNS servers support RRTYPE 99. The operational issues I've encountered with actually trying to use RRTYPE99 in the wild weren't caused by a lack of support in current-era shipping DNS servers. Sometimes it's not even anything directly related to the DNS. I recall cases where it appeared that firewalls were the root of the problem (I don't recall details, sorry). Solving the DNS servers must support unknown RRTYPE/SPF type problem only gets you started. Scott K
Re: TCPMUX (RFC 1078) status
On 8/21/2013 8:31 AM, Martin Sustrik wrote: On 21/08/13 17:12, Joe Touch wrote: The real problem here IMO is how to distinguish between adding a completely new application -- which should require approval process -- and adding a new component within an existing distributed application -- which should be managed by devs themselves. IMO it's easy - any group of services you want others to be able to use independently could justify a new port, but you can always mux them all together if you want to avoid additional firewall configuration issues. So what would you use for muxing, if TCPMUX is not a good idea? You need to roll your own. The requirements of systems vary widely, as do the costs/benefits of different approaches. I listed a few before, but here's a more comprehensive list: - service per message demux based on message ID use IPC (interprocess comm) to handoff internal to your system - service per connection demux based on the first message in an association (TCP or UDP), and either continue to forward messages to a different process or handoff the connection - subservice on different ports determine what subservice you want to initiate, start it on an ephemeral port, and indicate the port number in-band (e.g., as with FTP and others) Given you want to keep things on a single port, the first two are probably more useful. Joe
Re: [spfbis] 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 Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote: I object to the removal of the SPF record. This is not a shock. You were in the rough when we discussed it in the WG too. Name servers already have access controls down to the granuality of TYPE. If this draft proceeds as currently described it is forcing name server vendors to access controls at the sub TYPE granuality. It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. With SPF lookup first I can specify the SPF policy using SPF and leave TXT free for other uses without having to worry about the records being misinterpeted. Unless you have some specific reason to be concerned about accidentally starting an unrelated TXT record with v=spf1 , I can't imagine you don't have more important things to worry about. This being a problem is a great theory, but it just doesn't happen in practice. SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF. This is similar to not proceeding to A/ lookups on MX lookup failures. Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain that has an actual SPF record due to various operational issues. SERVFAIL on type SPF doesn't reliably tell you anything about what a type TXT lookup would produce. So it's similar, but only superficially so. I would also suggest that there be a sunset date published for the use of TXT for SPF. Do you also suggest creation of an Internet police force to enforce this? What would be be mandatory minimum sentence? Scott K
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Eliot Lear wrote: Patrik, First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: * To what extent has that happened? The easy part was supposed to be people actually using the SPF record, once it was out there. And so your data doesn't indicate what sort of answers you're getting. Eliot, we will add SPF type support in our implementation once the infrastructure is ready. For us, as a windows shop, namely Microsoft DNS servers. So the better question I believe would be: If the DNS servers begin to support RFC 3597, would you add or enable SPF type99 support? Would you support new RR types based on this support presumption? Of course, the existing base would be low or marginal simply because for optimization and lower overhead reasons, it was not added or disabled in existing packages. But I believe the interest was and still is there to support in general new RR types once the infrastructure is ready, especially in the DNS community. The question to ask is if it is reasonable to believe DNS servers will be improved to support this industry desire or need. If not, then its reasonable to remove SPF type in RFC 4408bis, and for that matter, forget about all future new RR type proposals. TXT will be the fast entry record of choice. All recent mail related DNS protocols have been TXT, including the new DMARC and I don't see that changing (the same folks are producing them). -- HLS
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
At 04:55 21-08-2013, manning bill wrote: regarding adoption it would be interesting to take a second snapshot from each of these servers in about six months to see if the trend has changed (modulo PAFs observations that not all TXT == SPF). In the mean time, declare a suspension of last call to gauge if the presumption of failure of the SPF RR merits this drastic action. The IETF chartered the SPFBIS WG to deliver: (i) A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. (ii) A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. There is a message from the Responsible Area Director ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00331.html ) and the SPFBIS Chairs ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html ) about (i). The SPFBIS WG was asked to make a good-faith effort and that is what the working group did. The editor of RFC 6686 did a good job. The IESG approved the publication of the draft. The working group worked on its second deliverable (ii) after that. There wasn't any concern about the TXT RR as the matter was considered as resolved in RFC 6686. I asked DNSEXT about the SPF RRTYPE in the (IANA) DNS Parameters registry ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html ). It generated long threads on several IETF mailing lists. It was unusual to have that amount of comments after the end of a WGLC. Suspending the Last Call for six months is a drastic action. I would ask the Responsible Area Director to consider that if the SPFBIS WG did not make a good-faith effort or if there is an issue with the process that was followed. My opinion is that the SPFBIS WG made a good-faith effort. There are at least three Area Directors reading the SPFBIS mailing list. They did not flag any process-related issue. At 07:03 21-08-2013, Jelte Jansen wrote: Just wondering, could OARC's recent DITL data help? (perhaps if only to see whether another large-scale targeted effort is needed) Yes. Someone also has to do the work. Regards, S. Moonesamy (as document shepherd)
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Patrik, On 8/21/2013 7:17 AM, Patrik Fältström wrote: My conclusion is that a statement that nobody queries for it is false. Assuming that your conclusion is based on pragmatics and not mathematical purity -- that is, that it is concerned with significant operational effort, rather than a stray implementation here or there, which counts as noise in any legitimate statistical analysis -- what is the basis for your conclusion? In other words, please explain how your objection is based on real-world utility rather than something more abstract and detached from practical operations. From your posting to the dnsext working group: On 8/20/2013 11:58 AM, Patrik Fältström wrote: In general I do believe, for example when looking at IPv6 and DNSSEC and similar technologies, that the lifetime of RFC 4408 is too short to deprecate any of the proposed records that are in use, specifically as RFC 4408 explicitly do allow use of both. On its face, this sort of thinking means that, in practical terms, nothing can ever be deprecated. It also requires a rather willful ignorance of the essential community operations differences between SPF and IPv6 and DNSSec. There is massive effort to increase use of the latter. There is massive apathy about the former. That is, the metric of essentially no adoption or use is matched by no vector of change. So if you really insist on pursuing your objection, please find some arguments that are anchored in relevant, real-world analytic legitimacy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] there is no transitiion, was Last Call: draft-ietf-spfbis-4408bis-19.txt
Actually, I just checked. Right now, none of them seem to publish SPF RRtype records. Yahoo doesn't even publish a TXT record containing SPF information. An argument could be made that if we really wanted to push the adoption of SPF RRtypes, getting Google, Yahoo and Hotmail to publish SPF RRtype records would actually make it worthwhile to query SPF first, because most queries probably go to those domains. This would require some reason why it is worth them spending time and money to do something that has no operational benefit whatsoever. If they start publishing type 99, something will break, because when you change something in large systems, something always breaks. Some mail systems somewhere with bugs in type 99 handling that they never noticed will start making mail fail. For doing that, will anyone's mail work better? No. Will their DNS work better? No. As I have mentioned a couple of times already, even though Yahoo doesn't publish SPF (I believe due to political issues related to the history of Domainkeys and DKIM), they do check SPF. They used to check both TXT and type 99, and stopped checking type 99. What argumment is there to spend money to revisit and reverse that decision? Arguments about DNS purity, and hypothetical arguments about other TXT records that will never exist are unlikely to be persusasive. R's, John
Re: TCPMUX (RFC 1078) status
On 8/15/2013 6:23 PM, Wesley Eddy wrote: I totally agree. In fact, in the update to the TCP roadmap [1], we added TCPMUX to the section on Historic and Undeployed Extensions, though it definitely bears further discussion than is currently in the roadmap. I think we should add a reference to your portnames doc to explain why this should be Historic plus check a bit more to see if the code that's out there is really being used or whether it's just hanging out like a vestigal limb in the various inetd packages. Wes, Indeed, TCPMUX is quite historic... it represents a Road Not Taken. My memory is a bit hazy after 30+ years, but I think there was a serious discussion around 1979 of using strings instead of contact port numbers for opening TCP connections. Here is the hazy part... I *think* that Chaosnet used strings, and two well known MIT Daves introduced a proposal to adopt this mechanism for TCP. (Also, maybe XNS used strings? Not sure about that...) The internet working group ultimately rejected the idea, I think when Jon Postel argued that contact ports provided greater conceptual economy. Maybe I got this wrong, but in any case I hope that someone else who was in the room then will correct me. Jack? Vint? Dave? Danny? Bob Braden
Re: [spfbis] 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 21 aug 2013, at 19:31, Dave Crocker d...@dcrocker.net wrote: Assuming that your conclusion is based on pragmatics and not mathematical purity -- that is, that it is concerned with significant operational effort, rather than a stray implementation here or there, which counts as noise in any legitimate statistical analysis -- what is the basis for your conclusion? As I did show, the numbers comes directly from tcpdump on my auth DNS server, where I checked how many do query for TXT and SPF(*). I do not understand the question. What else do you want? As a few others have said, 4408 do have an error that makes it impossible to use RFC 4408 for migration from TXT to SPF which was the original intent. I do not understand how the conclusion, given the number of SPF queries that is made, on how to fix the problem with RFC 4408 is to deprecate the SPF RRtype. And to your question on deprecation, yes, to me one do need much more arguments to deprecate something. Specifically when originally the intent was to migrate to what is now to be deprecated. And this is why I am objecting to 4408bis to be published as an RFC. If you had an RFC without issues that really did talk about a migration strategy (including having examples using SPF records and not TXT which one should migrate from) and still people did not migrate, then we would have a different discussion. But we are not there. A proper migration strategy to SPF has not been published. Patrik (*) I have now removed TXT version of the SPF record for frobbit.se to see whether the number of queries for SPF RRType go up or not.
Re: [spfbis] there is no transitiion, was Last Call: draft-ietf-spfbis-4408bis-19.txt
On Aug 21, 2013, at 10:44 AM, John Levine jo...@taugh.com wrote: This would require some reason why it is worth them spending time and money to do something that has no operational benefit whatsoever. Sorry, I wasn't trying to make an argument for you to refute. I'm saying that if the people who want to change the outcome of the spfbis consensus are serious, this would be a good way to show that they have community support for their position.
Re: [spfbis] 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 8/21/2013 11:13 AM, Patrik Fältström wrote: But we are not there. A proper migration strategy to SPF has not been published. Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] 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 Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: I'm not going to copy the spfbis WG list on this, because this is part of the IETF last call. No hat. On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker d...@dcrocker.net wrote: From earlier exchanges about this concern, the assertion that I recall is that 7 years is not long enough, to determine whether a feature will be adopted. What is the premise for seven years being not long enough? And what does constitute long enough? And upon what is that last answer based? I have two observations about this. First, EDNS0, which is of significantly greater benefit to DNS operators than the mere addition of an RRTYPE, took well over 10 years to get widespread adoption. Second, we all know where IPv6 adoption stands today, and that has certainly been around longer than 7 years. So I think it _is_ fair to say that adoption of features in core infrastructure takes a very long time, and if one wants to add such features one has to be prepared to wait. But, second, I think all of that is irrelevant anyway. The plain fact is that, once 4408 offered more than one way to publish a record, the easiest publication approach was going to prevail. That's the approach that uses a TXT record. For the record I think SPF RRtype retirement is not in the good-idea category, but nor is it in the bad-idea category, it falls in the we need-to-do-something-that-works. Most of the recent arguments against SPF type have come down to the following (as far as I can tell): a) I can not add SPF RRtype via my provisioning system into my DNS servers b) My firewall doesl not let SPF Records through c) My DNS library does not return SPF records through or does not understand it, thus the application can not receive it. d) Looking up SPF is a waste of time as they do not get through, thus we only look up TXT So what I have taken from this is that the DNS infrastructure is agnostic to RRtype=99 but the edges have problems. As to the arguments 7 years is not long enough to reach conclusion and force the changes through the infrastructure and to the edges. The need for SPF has been blunted by the DUAL SPF/TXT strategy and thus we are basically in the place where the path of lowest-resistence has taken us. What I want the IESG to add a note to the document is that says something like the following: The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, the retirement is consequence of the dual quick-deploy strategy. The IETF will continue to advocate application specific RRtypes applications/firewalls/libraries SHOULD support that approach. Olafur
Re: [spfbis] 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 21 aug 2013, at 20:29, Dave Crocker d...@dcrocker.net wrote: On 8/21/2013 11:13 AM, Patrik Fältström wrote: But we are not there. A proper migration strategy to SPF has not been published. Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. Dave, I do not appreciate the tone of your message. I explain as part of a last call of a message to the IETF mailing list why I object to publication of an I-D as an RFC. If the IESG comes to the conclusion that the document should be published fine. If they say it should not. Fine. That is the IETF process. I should have staid on the DNS mailing list as I said originally, where I promised people I should not discuss SPF anymore on the main IETF list because I knew the pushback from you and a few others would be exactly like this. I was convinced to give my view on SPF to the IETF list so that it was known correctly to the last call process. A process I have always trusted and believed it. And still trust and still believe in. This is my last posting in this thread. Patrik
Re: Gen-ART LC review of draft-ietf-repute-model-07
As per a suggestion in another thread: Would you also say that this draft is ready for publication as a Proposed Standard? This is more architectural overview than protocol per-se, but I do think it is necessary to the understanding of the other protocol documents (hence it is a normative reference), and I think it can progress with the rest. (I haven't seen an objection to doing so in the other Last Call thread, so unless there is a good reason not to, I'm inclined to re-initiate the Last Call for Proposed Standard instead.) pr On 8/21/13 8:27 AM, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-repute-model-07 Reviewer: Roni Even Review Date:2013--8--20 IETF LC End Date: 2013-8--29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. Nits/editorial comments: Section 3 the end of 2^nd paragraph mechansisms to mechanisms -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [spfbis] 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 Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: On Aug 19, 2013, at 5:41 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: I'm not going to copy the spfbis WG list on this, because this is part of the IETF last call. No hat. On Mon, Aug 19, 2013 at 02:04:10PM -0700, Murray S. Kucherawy wrote: On Mon, Aug 19, 2013 at 1:59 PM, Dave Crocker d...@dcrocker.net wrote: From earlier exchanges about this concern, the assertion that I recall is that 7 years is not long enough, to determine whether a feature will be adopted. What is the premise for seven years being not long enough? And what does constitute long enough? And upon what is that last answer based? I have two observations about this. First, EDNS0, which is of significantly greater benefit to DNS operators than the mere addition of an RRTYPE, took well over 10 years to get widespread adoption. Second, we all know where IPv6 adoption stands today, and that has certainly been around longer than 7 years. So I think it _is_ fair to say that adoption of features in core infrastructure takes a very long time, and if one wants to add such features one has to be prepared to wait. But, second, I think all of that is irrelevant anyway. The plain fact is that, once 4408 offered more than one way to publish a record, the easiest publication approach was going to prevail. That's the approach that uses a TXT record. For the record I think SPF RRtype retirement is not in the good-idea category, but nor is it in the bad-idea category, it falls in the we need-to-do-something-that-works. Most of the recent arguments against SPF type have come down to the following (as far as I can tell): a) I can not add SPF RRtype via my provisioning system into my DNS servers b) My firewall doesl not let SPF Records through c) My DNS library does not return SPF records through or does not understand it, thus the application can not receive it. d) Looking up SPF is a waste of time as they do not get through, thus we only look up TXT So what I have taken from this is that the DNS infrastructure is agnostic to RRtype=99 but the edges have problems. As to the arguments 7 years is not long enough to reach conclusion and force the changes through the infrastructure and to the edges. The need for SPF has been blunted by the DUAL SPF/TXT strategy and thus we are basically in the place where the path of lowest-resistence has taken us. What I want the IESG to add a note to the document is that says something like the following: The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, the retirement is consequence of the dual quick-deploy strategy. The IETF will continue to advocate application specific RRtypes applications/firewalls/libraries SHOULD support that approach. I'm a bit unsure that continue is the right word. DKIM moved to the TXT with underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone ever suggest they should. DMARC, which has had a BoF and for which a WG is being considered will do the same (there's no variant of proposed charter text floating around that would allow them to consider otherwise). I agree with that the notion of a statement that SPF is what it is for a variety of reasons and shouldn't be considered as a precedent for the future might be a reasonable thing to add. I don't think the IETF has been very consistent about what one ought to do instead. Scott K
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. The sarcasm is not reasonable. Please stop. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: WG Review: Secure Telephone Identity Revisited (stir)
The following mostly are points that I raised within the group's mailing list discussion, during charter development. In my view, they have not yet been adequately resolved: On 8/21/2013 10:52 AM, The IESG wrote: Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. ... The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. use a particular telephone number for an incoming call has no obvious and unambiguous technical meaning. In fact, it seems to imply the meaning of authorization to call a particular number. However of course that's not the intended meaning. Since this is the only text in this paragraph that says what the working group will /do/ it should make its statement with clarity and technical substance. That is, the charter needs to use a precise term for specifying the specific role of the number of interest. In earlier drafts, caller id was used. The next sentence uses source telephone number. Perhaps that is acceptable. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized As a matter of form, I'll note the SIP's community's use of identity is what is called identifier in the identity community. ... As its priority mechanism work item, the working group will specify a SIP Reference to work priority is only meaningful in the face of a list of tasks that will be considered simultaneously and what it means to give priority to one over another. Based on the lengthy mailing list discussion of in-band vs. out-of-band, it appears that the current charter is actually intended to support simultaneous work on alternative mechanisms, rather than pursuing them sequentially. This should be made explicit. If the requirement is to work on them sequentially, then state that. If the intent is to work on both approaches simultaneously, then say that. ... In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. in-band and the out-of-band mechanisms should share as much in common as possible This is the essential text that mandates working on both approaches simultaneously and makes the earliet assertion about priority moot. (Note how far down in the charter this is buried, yet how fundamental a requirement is establishes.) ... Input to working group discussions shall include: That's a lengthy list of documents. Why has it left out other documents discussed during charter development and clearly of continuing interest to the effort, namely: A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] 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 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: WG Review: Secure Telephone Identity Revisited (stir)
On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker d...@dcrocker.net wrote: The following mostly are points that I raised within the group's mailing list discussion, during charter development. In my view, they have not yet been adequately resolved: On 8/21/2013 10:52 AM, The IESG wrote: Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. ... The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. use a particular telephone number for an incoming call has no obvious and it'd actually be kind of nice if the focus was NOT on the (us) 10-digit number, but instead on the 'identity' making the call. There's a real chance to move beyond the '10-digit number' and to some stronger, wider, richer sense of 'identity'... we should take that opportunity and run with it. unambiguous technical meaning. In fact, it seems to imply the meaning of authorization to call a particular number. However of course that's not the intended meaning. Since this is the only text in this paragraph that says what the working group will /do/ it should make its statement with clarity and technical substance. That is, the charter needs to use a precise term for specifying the specific role of the number of interest. In earlier drafts, caller id was used. s/number/identity/ The next sentence uses source telephone number. Perhaps that is acceptable. no... focus on 'telephone number' is broken. Hell, it's not even what's used in the phone system anyway... not really. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized As a matter of form, I'll note the SIP's community's use of identity is what is called identifier in the identity community. ... As its priority mechanism work item, the working group will specify a SIP Reference to work priority is only meaningful in the face of a list of tasks that will be considered simultaneously and what it means to give priority to one over another. Based on the lengthy mailing list discussion of in-band vs. out-of-band, it appears that the current charter is actually intended to support simultaneous work on alternative mechanisms, rather than pursuing them sequentially. This should be made explicit. If the requirement is to work on them sequentially, then state that. If the intent is to work on both approaches simultaneously, then say that. ... In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. in-band and the out-of-band mechanisms should share as much in common as possible This is the essential text that mandates working on both approaches simultaneously and makes the earliet assertion about priority moot. (Note how far down in the charter this is buried, yet how fundamental a requirement is establishes.) ... Input to working group discussions shall include: That's a lengthy list of documents. Why has it left out other documents discussed during charter development and clearly of continuing interest to the effort, namely: A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: WG Review: Secure Telephone Identity Revisited (stir)
+ iesg -iesg-secretary On Wed, Aug 21, 2013 at 3:18 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker d...@dcrocker.net wrote: The following mostly are points that I raised within the group's mailing list discussion, during charter development. In my view, they have not yet been adequately resolved: On 8/21/2013 10:52 AM, The IESG wrote: Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. ... The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. use a particular telephone number for an incoming call has no obvious and it'd actually be kind of nice if the focus was NOT on the (us) 10-digit number, but instead on the 'identity' making the call. There's a real chance to move beyond the '10-digit number' and to some stronger, wider, richer sense of 'identity'... we should take that opportunity and run with it. unambiguous technical meaning. In fact, it seems to imply the meaning of authorization to call a particular number. However of course that's not the intended meaning. Since this is the only text in this paragraph that says what the working group will /do/ it should make its statement with clarity and technical substance. That is, the charter needs to use a precise term for specifying the specific role of the number of interest. In earlier drafts, caller id was used. s/number/identity/ The next sentence uses source telephone number. Perhaps that is acceptable. no... focus on 'telephone number' is broken. Hell, it's not even what's used in the phone system anyway... not really. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized As a matter of form, I'll note the SIP's community's use of identity is what is called identifier in the identity community. ... As its priority mechanism work item, the working group will specify a SIP Reference to work priority is only meaningful in the face of a list of tasks that will be considered simultaneously and what it means to give priority to one over another. Based on the lengthy mailing list discussion of in-band vs. out-of-band, it appears that the current charter is actually intended to support simultaneous work on alternative mechanisms, rather than pursuing them sequentially. This should be made explicit. If the requirement is to work on them sequentially, then state that. If the intent is to work on both approaches simultaneously, then say that. ... In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. in-band and the out-of-band mechanisms should share as much in common as possible This is the essential text that mandates working on both approaches simultaneously and makes the earliet assertion about priority moot. (Note how far down in the charter this is buried, yet how fundamental a requirement is establishes.) ... Input to working group discussions shall include: That's a lengthy list of documents. Why has it left out other documents discussed during charter development and clearly of continuing interest to the effort, namely: A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: WG Review: Secure Telephone Identity Revisited (stir)
On Aug 21, 2013, at 3:18 PM, Christopher Morrow morrowc.li...@gmail.com wrote: use a particular telephone number for an incoming call has no obvious and it'd actually be kind of nice if the focus was NOT on the (us) 10-digit number, but instead on the 'identity' making the call. There's a real chance to move beyond the '10-digit number' and to some stronger, wider, richer sense of 'identity'... we should take that opportunity and run with it. To be clear, the focus is not on a 10-digit number nor numbers for any specific country-code. It's for the global E.164 number space. With regard to other 'identities', if you mean non-telephone-number-based SIP user@domain type names, the IETF has a PS RFC for that: RFC 4474. Its adoption rate requires double floating-point precision to detect it not being 0%. ;) This proposed-WG is due to real-world issues in deployments using telephone numbers, so that's been our focus scope to fix. As it happens, both of the proposed STIR solutions so far have in fact addressed more than just telephone numbers, including the user@domain type. I've been told so long as we get it for free so-to-speak, we can address them as well in our deliverables - we just need to focus on telephone numbers since that's the problem that needs fixin'. no... focus on 'telephone number' is broken. Hell, it's not even what's used in the phone system anyway... not really. Ummm... ok, what is it you think is used in the phone system really? Or what better word/term would you use to label what's used in the phone system? -hadriel
Re: WG Review: Secure Telephone Identity Revisited (stir)
I noticed in a few places the suggestion to replace telephone number with 'identity'. I think that this is a particularly bad enhancement given how widely the term identity is understood by most people. In RFC 6973 we defined the term (which is inline with many of the identity management efforts) as: $ Identity: Any subset of an individual's attributes, including names, that identifies the individual within a given context. Individuals usually have multiple identities for use in different contexts. I don't think that this is what the work is about. Let's keep the charter text concise and enhance it later once work gets done. Ciao Hannes On 08/21/2013 09:25 PM, Christopher Morrow wrote: + iesg -iesg-secretary On Wed, Aug 21, 2013 at 3:18 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Aug 21, 2013 at 3:07 PM, Dave Crocker d...@dcrocker.net wrote: The following mostly are points that I raised within the group's mailing list discussion, during charter development. In my view, they have not yet been adequately resolved: On 8/21/2013 10:52 AM, The IESG wrote: Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. ... The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. use a particular telephone number for an incoming call has no obvious and it'd actually be kind of nice if the focus was NOT on the (us) 10-digit number, but instead on the 'identity' making the call. There's a real chance to move beyond the '10-digit number' and to some stronger, wider, richer sense of 'identity'... we should take that opportunity and run with it. unambiguous technical meaning. In fact, it seems to imply the meaning of authorization to call a particular number. However of course that's not the intended meaning. Since this is the only text in this paragraph that says what the working group will /do/ it should make its statement with clarity and technical substance. That is, the charter needs to use a precise term for specifying the specific role of the number of interest. In earlier drafts, caller id was used. s/number/identity/ The next sentence uses source telephone number. Perhaps that is acceptable. no... focus on 'telephone number' is broken. Hell, it's not even what's used in the phone system anyway... not really. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized As a matter of form, I'll note the SIP's community's use of identity is what is called identifier in the identity community. ... As its priority mechanism work item, the working group will specify a SIP Reference to work priority is only meaningful in the face of a list of tasks that will be considered simultaneously and what it means to give priority to one over another. Based on the lengthy mailing list discussion of in-band vs. out-of-band, it appears that the current charter is actually intended to support simultaneous work on alternative mechanisms, rather than pursuing them sequentially. This should be made explicit. If the requirement is to work on them sequentially, then state that. If the intent is to work on both approaches simultaneously, then say that. ... In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. in-band and the out-of-band mechanisms should share as much in common as possible This is the essential text that mandates working on both approaches simultaneously and makes the earliet assertion about priority moot. (Note how far down in the charter this is buried, yet how fundamental a requirement is establishes.) ... Input to working group discussions shall include: That's a lengthy list of documents. Why has it left out other documents discussed during charter development and clearly of continuing interest to the effort, namely: A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER) draft-kaplan-stir-cider-00 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Rude responses (Was: 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 8/21/13 2:17 PM, Dave Crocker wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. It is certainly not helpful to me as the consensus caller. And it is rude. Since you've made this a formal process point, I'll ask you to substantiate it carefully and also formally. The implication of your assessment is that IETF participants must not comment on the utility of comments by others. That's not what I said, and in fact if you look at the line immediately following what you quoted, you will see that I said: It's perfectly reasonable to say, This would constitute a new requirement and I don't think there is a good justification to pursue that line. It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, the only purpose it seems to serve is to bully others into not participating in the conversation. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources. In fact an important problem with the alternate wording, such as you offered, is that it implies a possible utility in the thread that does not exist. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, especially if the tactic used to end the discussion was sarcasm to chase people away from the discussion. You are looking at only the little picture. The consensus might end up on the rough side, but having the conversation has utility in and of itself. I find your edge much more disruptive to the conversation, making it much more adversarial than explanatory, and damaging the consensus that might be built. I think that lowers the utility of the output tremendously. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Well, almost. 4408 sort of blunders about like the elephant in a china shop wrt. query method and depreciation. (As I have been sternly lectured off-list that I do not understand the SPF payload and therefore am in no position to discuss the DNS usage, I'd like to assert that the payload syntax matters marginally, if at all, for the discussion about which DNS records to use and how.) Specifically, 4408 section 3.1.1 should be updated to: * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if SPF is impossible to publish. * If it is possible to use SPF as a result of having modern provisioning systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, they MUST agree wrt content. * The notion of a sunset date as introduced by Mark Andrews, is interesting. Section 4.1.1 in 4408 should be altered to direct implementations to FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for TXT, thus creating an incentive to improve performance by serving SPF rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The preference for SPF vs TXT that is present in 4408 is to be kept unaltered. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!! signature.asc Description: Digital signature
Re: Last call of draft-ietf-spfbis-4408bis-19
Hi Patrik, At 11:58 20-08-2013, Patrik Fältström wrote: As the bottle is opened, I hereby state my objection to Section 3.1 of draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree (as stated below) that the section of RFC 4408 that specify how to use both SPF and TXT resource record types include an error as it does not lead to interoperability. As the intention with use of both TXT and SPF originally was to migrate from TXT to SPF I instead of what is outlined in the draft suggest that a proper migration strategy is laid out (look up mandatory to implement SPF and fall back to TXT). This instead of deprecation of the SPF record. In general I do believe, for example when looking at IPv6 and DNSSEC and similar technologies, that the lifetime of RFC 4408 is too short to deprecate any of the proposed records that are in use, specifically as RFC 4408 explicitly do allow use of both. draft-ietf-spfbis-4408bis-19 is not the usual Proposed Standard effort. The SPFBIS WG was tasked to move RFC 4408 to Proposed Standard with restrictions. One of the restrictions is not to review the design. I hope that explains why draft-ietf-spfbis-4408bis-19 is what it is. I suggested to the working group to review the issue of the migration strategy (see http://www.ietf.org/mail-archive/web/spfbis/current/msg03934.html ). From Section 3.1.1 of RFC 4408: It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. There isn't similar text in draft-ietf-spfbis-4408bis-19. Hector Santos commented that: we will add SPF type support in our implementation once the infrastructure is ready. For us, as a windows shop, namely Microsoft DNS servers. I read http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records My conclusion is that there is a DNS server that cannot handle the new RR Type. The question is how to address the objection about the migration strategy. Regards, S. Moonesamy (as document shepherd)
Re: [spfbis] 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 Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote: Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Well, almost. 4408 sort of blunders about like the elephant in a china shop wrt. query method and depreciation. (As I have been sternly lectured off-list that I do not understand the SPF payload and therefore am in no position to discuss the DNS usage, I'd like to assert that the payload syntax matters marginally, if at all, for the discussion about which DNS records to use and how.) Specifically, 4408 section 3.1.1 should be updated to: * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if SPF is impossible to publish. This is the point where you abandon the installed base. Particularly given the charter, I think this is an inappropriate approach. * If it is possible to use SPF as a result of having modern provisioning systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, they MUST agree wrt content. draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was approved by the IESG. Since at the time of IESG approval, the RRTYPE for SPF hadn't been allocated yet, they - by necessity - approved a paper design. Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were able to experiment with running code and determine that this MUST was operationally extremely problematic, so it was removed as part of the AUTH 48 review. * The notion of a sunset date as introduced by Mark Andrews, is interesting. Section 4.1.1 in 4408 should be altered to direct implementations to FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for TXT, thus creating an incentive to improve performance by serving SPF rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The performance implications are more generally constraining on the receive side in high volume mail systems. Adding a second set of sequential DNS queries is a non-starter. It's much more efficient to go straight to TXT where 99%+ of the time I'll get a correct answer [there are a minute number of domains that publish SPF only, but virtually all type SPF publishers also publish TXT]. I think you're putting the performance implications on the wrong end of the conversation. Let's say we get to this magical sunset date, whose behavior do you think it will influence if they are finding the TXT queries still useful (if they aren't, they won't do it and you don't need the sunset date)? The preference for SPF vs TXT that is present in 4408 is to be kept unaltered. Here's a related conundrum that I haven't seen operationally (due to limited RRTYPE SPF deployment, but I have seen similarly for real in the fallback to v=spf1 records in the SenderID RFCs). It's an example of why you can't ignore the payload. One of the widely used features of SPF is the include mechanism. It allows a sender to authorize the hosts of a third party to send mail on its behalf. It also allows SPF records to be chained together to publish more information while staying in the standard UDP packet limit. Here's an example for the latter from Microsoft's current SPF record: v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ... A key aspect of include is that the targe domain MUST have an SPF record. If it doesn't, it's a permerror - permanent error. Let's imagine for a moment that example.com has this record published in RRTYPE SPF: v=spf1 a include:example.org -all Then let's consider example.org and imagine that, like most SPF participants today, they have their record published in RRTYPE TXT only: v=spf1 a -all A receiver, as you suggest, checks RRTYPE SPF when they get mail from example.com. Their SPF verifier processes the include mechanism and determines it needs to do a lookup for example.org's SPF record. They query RRTYPE SPF and they get ANSWER: 0 in return. Should this verifier: 1. Return a permerror because the target domain of an include doesn't exist? 2. Press on and query RRTYPE TXT, get an SPF record back, and finish the transaction without error? RFC 4408 doesn't help us here because it's treatment of the TXT/SPF coexistence model is not complete. I have said before that I don't think an effective transition model exists nor can it be created. I think Olafur Gudmundsson's suggestion that 4408bis document this use of TXT as an architectural wart and move on is a good one. I think this is a
Re: Rude responses (Was: 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 8/21/2013 12:46 PM, Pete Resnick wrote: It is not your complaint about the imposition of new requirements that is problematic, or your point that it is not useful to continue that line of discussion. Talk about the utility of a comment all that you want. It is the sarcasm and the rudeness that I am saying is unreasonable. Especially coming from a senior member of the community, OK. No sarcasm in IETF postings. Good luck with that. More seriously... You might have noticed that there have been a variety of folk making unrealistic or misguided suggestions and that they have been receiving entirely muted and exploratory -- albeit negative -- responses. The implication that I think you've missed here is the obligation that should hold for a 'senior' participant who is lodging concerns. The current thread is being tenaciously pursued by another senior member and former AD and the line of objections and requirements being put forward are studiously ignoring the considerable efforts of the working group and the considerable practical field history. As such, they represent their own form of disrespect. The alternative phrasing you suggest makes sense for average, random, problematic criticism. But as I indicated in the previous note, the phrasing suffers from implying a degree of legitimacy that is not warranted for this thread, from another 'senior' participant. I realize you don't agree with that view, but I'll again note that I'm not aware of any formal rule that my posting violated and certainly not any pattern of IETF practice. (Of course I can read the Code of Conduct to the contrary, but having done that, I felt that each of its relevant points had a counter in this case.) I, too, preferred a far more constructive tone to the thread, and attempted to contribute that initially. But persistent unreasonableness, when it can't be attributed to ignorance, warrants an explicit note. So I gave it. Taking this thread seriously, even to the extent of treating it with a cautiously respectful tone, encourages a persistent silliness in the IETF that is strategically destructive, because it communicates our tolerance for having experienced participants waste people's time and effort. the only purpose it seems to serve is to bully others into not participating in the conversation. You think I could bully Patrik? Good luck with that, too. If you think that the conversation has gone on too long, you're perfectly within rights to ask the manager of the thread (in this case, myself or the chairs), in public if you like, to make a call and say that the issue is closed. But again, the tactics displayed above are not professional and not reasonable rhetorical mode. The thread itself does not have a professional premise, Pete. The record needs to reflect at least one comment to that effect. I don't recall that being a proscribed behavior, since it has nothing to do with personalities. So, please explain this in a way that does not sound like Procrustean political correctness. I am not sure what the first sentence means. And I'm sorry that you believe that my stance on this is Procrustean. But the fact is that rude comments of this sort do not contribute to consensus-building in the least. The thread has its own responsibility to attempt consensus building. It wasn't doing that. In fact, in its way, it has represented a classic, continuing of bullying against DNS pragmatics. For the record, I entirely acknowledge that my note has an edge to it and yes, of course alternate wording was possible. However the thread is attempting to reverse extensive and careful working group effort and to ignore widely deployed and essential operational realities, including published research data. I appreciate your input that you believe that some or all of the objectors are ignoring operational realities. I didn't say that. This current exchange is about a specific thread. It is now your turn to be more careful in what you assert. Perhaps they are. But the fact is that Last Call is a time for the community to take a last look at WG output. If senior members of the community (among which there are several in this thread) are suspicious of the output, it *is* important to make sure that their concerns are addressed. Only after determining that their concerns are reasonable. Maybe they simply don't have all of the information. But maybe the WG has missed something essential in all that careful work. Both have historically happened many times. Again, you are missing the point that we'd already done through quite a bit of that, with no apparent effect. It is far more distracting and destabilizing for the IETF to come out of a Last Call with experienced members of the community suspicious that a bad result has occurred, As an abstraction, your point is of course entirely valid. But your premise is that a reasonable discussion is possible and that
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is forcing
name server vendors to access controls at the sub TYPE granuality.
It's primarily an issue for applications. To the DNS, it's exactly what it
is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.
Unless you have some specific reason to be concerned about accidentally
starting an unrelated TXT record with v=spf1 , I can't imagine you don't
have more important things to worry about. This being a problem is a great
theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
This is similar to not proceeding to A/ lookups on MX lookup
failures.
Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain
that has an actual SPF record due to various operational issues. SERVFAIL on
type SPF doesn't reliably tell you anything about what a type TXT lookup
would
produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
I would also suggest that there be a sunset date published for the
use of TXT for SPF.
Do you also suggest creation of an Internet police force to enforce this?
What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
Scott K
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
In this conversation between Pete and Dave, there's one point that's come up which has come up often enough that I want to call it out separately for comment: the only purpose it seems to serve is to bully others into not participating in the conversation. You think I could bully Patrik? Good luck with that, too. Let's take this out of the context of the discussion at hand, and be more general -- because, as I said, I'm reacting not to the statement as it stands, but to how often I've seen it made (twice within the last few weeks alone). The form is this: Point: You behaved badly toward [person X]. Counterpoint: Well, [person X] has been around, he can handle it. Often, there's a further response that agrees that, indeed, [person X] can take it, so all is OK. No. All is not OK. What this argument leaves out is consideration of everyone *else* who's reading this exchange and putting themselves in the shoes of [person X]. Many of them are looking at what to expect from engaging in IETF discussions, many of them are not old-timers with thick skins and an understanding of IETF rhetoric, and many of them will be put off of participating because they see how we treat those who do participate. Again, remember: I'm not talking about this particular discussion, so let's not fixate on whether or not being abrupt, sarcastic, abusive, offensive, profane, or whatever... is appropriate for this conversation. The general point is that the new people whom we want to draw in as productive participants will be watching how we treat each other and deciding whether they want to wade into that pool. Barry
Re: Rude responses (Was: 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 08/21/2013 11:13 PM, Barry Leiba wrote: The general point is that the new people whom we want to draw in as productive participants will be watching how we treat each other and deciding whether they want to wade into that pool. Yes, that is a factor that merits attention. But not the only nor an always-overriding one. For example brevity matters, technical correctness wins, humour is important and can be cruel. I can't myself think of a good justification for sarcasm, (well, maybe [1]:-) but I can understand that sometimes people make mistakes. And sometimes the same people make the same mistakes many times. We're not here to make them better though. Calling 'em on it is a good way to handle it I think. Generalising to the point where we are all expected to be politically correct clones would not. (Yes, I'm exaggerating what you're saying there:-) S. [1] https://en.wikipedia.org/wiki/List_of_Father_Ted_characters and search for sarcastic:-)
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 04:52:59PM -0400 Quoting Scott Kitterman (scott@kitterma On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote: Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Well, almost. 4408 sort of blunders about like the elephant in a china shop wrt. query method and depreciation. (As I have been sternly lectured off-list that I do not understand the SPF payload and therefore am in no position to discuss the DNS usage, I'd like to assert that the payload syntax matters marginally, if at all, for the discussion about which DNS records to use and how.) Specifically, 4408 section 3.1.1 should be updated to: * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if SPF is impossible to publish. This is the point where you abandon the installed base. Particularly given the charter, I think this is an inappropriate approach. As I'm thinking about migration here, let's be generous. Allow publication of TXT too, even if SPF is possible, but then not alone. * If it is possible to use SPF as a result of having modern provisioning systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, they MUST agree wrt content. draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was approved by the IESG. Since at the time of IESG approval, the RRTYPE for SPF hadn't been allocated yet, they - by necessity - approved a paper design. Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were able to experiment with running code and determine that this MUST was operationally extremely problematic, so it was removed as part of the AUTH 48 review. Hence my comment about perhaps flying. * The notion of a sunset date as introduced by Mark Andrews, is interesting. Section 4.1.1 in 4408 should be altered to direct implementations to FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for TXT, thus creating an incentive to improve performance by serving SPF rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The performance implications are more generally constraining on the receive side in high volume mail systems. Adding a second set of sequential DNS queries is a non-starter. Why? There is caching. DNS queries are cheap. The problem of overloading TXT is IMNSHO so bad that it is worth the cost of additional queries; especially if we can collaborate on text to stimulate migration by constructing and specifying algorithms that are faster when using SPF rrtype only. It's much more efficient to go straight to TXT where (ITYM TODAY it is much more efficient and that might change) 99%+ of the time I'll get a correct answer [there are a minute number of domains that publish SPF only, but virtually all type SPF publishers also publish TXT]. I think you're putting the performance implications on the wrong end of the conversation. Let's say we get to this magical sunset date, whose behavior do you think it will influence if they are finding the TXT queries still useful (if they aren't, they won't do it and you don't need the sunset date)? The preference for SPF vs TXT that is present in 4408 is to be kept unaltered. Here's a related conundrum that I haven't seen operationally (due to limited RRTYPE SPF deployment, but I have seen similarly for real in the fallback to v=spf1 records in the SenderID RFCs). It's an example of why you can't ignore the payload. One of the widely used features of SPF is the include mechanism. It allows a sender to authorize the hosts of a third party to send mail on its behalf. It also allows SPF records to be chained together to publish more information while staying in the standard UDP packet limit. Here's an example for the latter from Microsoft's current SPF record: v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ... A key aspect of include is that the targe domain MUST have an SPF record. If it doesn't, it's a permerror - permanent error. Let's imagine for a moment that example.com has this record published in RRTYPE SPF: v=spf1 a include:example.org -all Then let's consider example.org and imagine that, like most SPF participants today, they have their record
Re: Rude responses (Was: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Hello, Lars Eggert mentioned [1] the following: cool off, take the intensity out of the discussion, and try to provide data/facts for your different standpoints, so the rest of us who are sitting on the sidelines watching the fireworks can form an opinion. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records makes that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. Scott K
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Mark Andrews ma...@isc.org wrote:
In message 7917527.VmCQD3a6Q3@scott-latitude-e6320, Scott Kitterman
writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in
the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is
forcing
name server vendors to access controls at the sub TYPE granuality.
It's primarily an issue for applications. To the DNS, it's exactly
what it
is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
This can be solved other ways. See my repky to your later message.
With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.
Unless you have some specific reason to be concerned about
accidentally
starting an unrelated TXT record with v=spf1 , I can't imagine you
don't
have more important things to worry about. This being a problem is
a great
theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for
SPF.
This is similar to not proceeding to A/ lookups on MX lookup
failures.
Except that it's quite common for a SERVFAIL on TYPESPF to occur for
a domain
that has an actual SPF record due to various operational issues.
SERVFAIL on
type SPF doesn't reliably tell you anything about what a type TXT
lookup would
produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
I prefer to design things for reliability rather than ignore interoperability
problems.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
Or some firewall in a box in between. Blame is not so easy to determine.
I would also suggest that there be a sunset date published for the
use of TXT for SPF.
Do you also suggest creation of an Internet police force to enforce
this?
What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
Is there an example of this kind of approach working?
Scott K
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Eliot, At 03:26 21-08-2013, Eliot Lear wrote: First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic, even so. The *hard* part about this was supposed to be implementation of the record in the application software. Can the shepherd answer this question: To what extent has that happened? There is a thread about libspf2 querying for RRTYPE 99 first ( https://lists.exim.org/lurker/message/20110812.094310.3a53c0f6.gl.html#exim-users ). I'll also mention http://support.godaddy.com/groups/domains-management-and-services/forum/topic/spf-type-99/ and http://features.cpanel.net/responses/ability-to-create-spf-type-99-records Here are a few messages on the SPFBIS mailing list about RRTYPE 99: http://www.ietf.org/mail-archive/web/spfbis/current/msg00555.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03778.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03781.html The SPFBIS WG Chair asked a question about what to conclude given the SPFBIS Charter ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03779.html ). Regards, S. Moonesamy (as document shepherd)
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott Kitterman writes: Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records mak es that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. No, it is NOT solved. You have to trust *everyone* with the ability to update TXT not to remove / alter that record. You can't give someone you don't trust the ability to update TXT. With a published SPF record and SPF lookup first stopping on success or lookup failure (SERVFAIL) you can give update control of TXT to someone you don't trust enough to not remove / alter the SPF TXT record. You keep telling us the TXT is just another record in the DNS. Well the DNS is managed at the granuality of the TYPE. 4408bis is forcing sub-type management to be developed and deployed to maintain the status quo. TXT is no longer just another record in the DNS with 4408bis as it currently stands. And to Google your motto is Do No Evil. Publishing a TXT SPF record without publish a SPF SPF record is Evil as it encourages other to do the same. Mark Scott K -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Scott Kitterman wrote: On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: What I want the IESG to add a note to the document is that says something like the following: The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, the retirement is consequence of the dual quick-deploy strategy. The IETF will continue to advocate application specific RRtypes applications/firewalls/libraries SHOULD support that approach. I'm a bit unsure that continue is the right word. DKIM moved to the TXT with underscore approach and, IIRC, never considered a new RRTYPE, nor did anyone ever suggest they should. DMARC, which has had a BoF and for which a WG is being considered will do the same (there's no variant of proposed charter text floating around that would allow them to consider otherwise). Consider that those specifications were written by the same author and group of folks. In no special meaning in any way, they all have had the same engineering mindset when it came the DKIM, VBR, ADSP and now even yet another DMARC proposed protocol. Same engineers, same engineering synergism. Thats not a negative commentary. This is desirable in an integrated world, but it can also locked down certain views as it has this case. DKIM learned from the SPF success with TXT. I specifically recall the WG decision discussion and it made practical sense. It allowed for an immediate entry point and fast proof of concept industry wide by using a TXT-based protocol, not only for DKIM but also for its original companion protocol ADSP (formerly SSP). Overall, I had sense a growing change in TXT-based protocol acceptability with many folks who otherwise were against it and this was quite apparent to me being highly considerate and cognizant of the technical design issue. It was for this reason I asked the question in the DNSEXT list and IETF before LC about where the industry stood in regards to TXT based solutions. I always had several ideas of my own for TXT-based DNS proposals such as DSAP (DKIM Signature Authorization Protocol) and a few others and if the IETF/DNS community was going to changed its belief and now endorse the TXT ideas, I didn't want to propose anything that would be controversial such as a new RR type, although that would most likely appease the DNS folks. I agree with that the notion of a statement that SPF is what it is for a variety of reasons and shouldn't be considered as a precedent for the future might be a reasonable thing to add. I don't think the IETF has been very consistent about what one ought to do instead. I don't agree with the SPF exception. If you believe in the future infrastructure to support new RR types, then there is no sensible reason to remove the SPF type and migration path from an updated RFC-4408BIS document. I don't see any harm in keeping the migration path IFF there is confidence a supportive infrastructure will be available in the future. -- HLS
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Scott, On Aug 21, 2013, at 4:07 PM, Scott Kitterman sc...@kitterman.com wrote: You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. Wouldn't this cause an extra lookup that you were arguing was prohibitive for large scale mail providers? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
NB: I have read the rest of the thread; but this is what deserves a reply: Dave Crocker d...@dcrocker.net wrote: On 8/21/2013 11:58 AM, Pete Resnick wrote: AD hat squarely on my head. (There may have been a miscommunication here -- what particular AD function Pete was speaking in; but to me, at least, it becomes clear in context.) On 8/21/13 1:29 PM, Dave Crocker wrote: Oh. Now I understand. You are trying to impose new requirements on the original work, many years after the IETF approved it. Thanks. Very helpful. That's not an appropriate response. Dave has every right to disagree on that; but I quite agree with Pete. It is decidedly not helpful, not productive, and tends towards escalating a discussion which has no need of escalation. It is certainly not helpful to me as the consensus caller. Dave has no right to disagree with this. We pay Pete the big bucks to call consensus on difficult issues like this. We need to understand it will be hard sometimes. I'm sure Dave has read Pete's draft on the meaning of consensus. I'm less sure he remembered it as he responded here. If this is the sort of response given to somewhat-valid questions raised about the draft being proposed, Pete will eventually have to say there _is_ no consensus. :^( And it is rude. Pete's opinion. (I happen to share it.) Consensus process works _much_ better if we respect the opinions of others -- even when we know they're wrong. Since you've made this a formal process point, Pete has _not_ done this. I'll ask you to substantiate it carefully and also formally... I see no reason Pete has any obligation to do so. If he chooses to, I ask him to not do it on this list. (Please don't feed the troll comes to mind.) A bit of edge is warranted for such wasteful, distracting and destabilizing consumption of IETF resources... Dave's opinion. (I happen to not share it.) Consensus process _also_ works better if we respect Dave's opinion here. I suggest we all remember that we don't have to change others' opinions here (were such a thing possible). We have only to bring them to the point where they agree they can live with the result. -- John Leslie j...@jlc.net
Re: [spfbis] 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 Thursday, August 22, 2013 09:31:03 Mark Andrews wrote: In message 0c3746c3-dac1-471f-bd07-8faf20481...@email.android.com, Scott Kitterman writes: Mark Andrews ma...@isc.org wrote: In message 20130821214832.1c92538c0...@drugs.dv.isc.org, Mark Andrews writes: It's primarily an issue for applications. To the DNS, it's exactly what it is, a TXT record. I can hand update of A and records to the machine. I can hand update of MX records to the mail adminstrator. I can hand update of SPF records to the mail adminstrator. I can hand update of TXT records to ?? No one because it has multiple uses. This is true whether SPF exists or not. SPF use of RRTYPE TXT for SPF records mak es that neither better nor worse. You could publish: example.com IN TXT v=spf1 redirect=_spf.example.com _spf.example. com IN TXT v=spf1 [actual content here] Then delegate _spf.example.com to the mail administrator. Problem solved. No, it is NOT solved. You have to trust *everyone* with the ability to update TXT not to remove / alter that record. You can't give someone you don't trust the ability to update TXT. With a published SPF record and SPF lookup first stopping on success or lookup failure (SERVFAIL) you can give update control of TXT to someone you don't trust enough to not remove / alter the SPF TXT record. You keep telling us the TXT is just another record in the DNS. Well the DNS is managed at the granuality of the TYPE. 4408bis is forcing sub-type management to be developed and deployed to maintain the status quo. TXT is no longer just another record in the DNS with 4408bis as it currently stands. And to Google your motto is Do No Evil. Publishing a TXT SPF record without publish a SPF SPF record is Evil as it encourages other to do the same. Your goal seems to be pretty much the opposite of the task the working group was given. You say so even more clearly here: http://www.ietf.org/mail-archive/web/spfbis/current/msg03948.html Unless you come with something new, I think I'm done. Scott K
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi John, At 20:02 21-08-2013, John Leslie wrote: If this is the sort of response given to somewhat-valid questions raised about the draft being proposed, Pete will eventually have to say there _is_ no consensus. :^( An Area Director may say that. :-( Regards, S. Moonesamy
Re: [spfbis] 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 Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote: ... SPF is a flagship case for the use a TXT record and continue to IPO fast and sloppy crowd. It needs correcting. Badly. Which IPO was that? BTW, in 2003 the choice was use TXT or nothing. So it was a crowd that wanted to accomplish something and did it the only way it was possible. Considering use of TXT wasn't an important factor in the DKIM last call, I conclude that this isn't really about using TXT. Scott K
Last Call: draft-boucadair-rfc6153-update-01.txt (Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery' draft-boucadair-rfc6153-update-01.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-18. 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 updates RFC 6153 by correcting IANA allocations made for DHCPv4 and DHCPv6 options for Access Network Discovery and Selection Function (ANDSF) Discovery. This document assigns a code for DHCPv6 option for ANDSF and withdraws an already assigned DHCPv4 option code. The file can be obtained via http://datatracker.ietf.org/doc/draft-boucadair-rfc6153-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-boucadair-rfc6153-update/ballot/ No IPR declarations have been submitted directly on this I-D.
JOSE WG Virtual Interim Meetings: September 4, September 16, September 30
The JOSE WG will have three upcoming interim virtual meetings: Wednesday, September 4th Monday, September 16th Monday, September 30th All of these meetings will occur at: 2300 UTC time slot (4 pm PDT, 7 pm EDT) The goal of these meetings will be to address issues in the issue tracker. Detailed agendas and webex instructions will follow on the jose mailing list. http://www.ietf.org/mail-archive/web/jose/current/maillist.html
