Re: Fisking vs Top-Posting
On 22 Sep 2010, at 19:48, Tony Finch wrote: On Wed, 22 Sep 2010, Dave Cridland wrote: Possibly. It's worth noting that format-flowed, for instance, is well supported with the notable exception of Outlook. Apple's MUAs have stopped using format=flowed and now use really long lines instead, because that give better interop with the market leader. This is rather sad. It is very sad. So I wasn't mistaken - Apple Mail used to do the right thing, and now no longer does. Please file bug reports at http://bugreporter.apple.com/ . With enough Duplicates it's possible Apple will listen to reason, but ... Meantime I'll have to post to netnews using a newsreader in order to avoid being flamed to death by users of readers which decode the QP-encoding but then don't wrap the long lines, or don't do MIME. Just out of curiosity, where did you get confirmation that Apple Mail behaves the way it does for the reason it does? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On Fri, 24 Sep 2010, Sabahattin Gucukoglu wrote: Just out of curiosity, where did you get confirmation that Apple Mail behaves the way it does for the reason it does? Can't remember, sorry. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNS spoofing at captive portals
Has the IETF (or rather then IAB) written any simple documents that explain to less informed (i.e. marketing/product) managers why it is a bad thing for a captive portal to spoof DNS replies? (not just in regard to DNSSEC, but also in regards to just caching) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
--On Thursday, September 23, 2010 10:43 -0700 Randy Dunlap rdun...@xenotime.net wrote: ... the same people also complain when I trim. So its a combination of pathological behaviours, UI, and dominance behaviour That should just be a function of where the UI software positions the cursor, shouldn't it? Well, it is a bit more than that. If one had a UI that combines: -- Small screen with tricky selection and scrolling -- Insertion of prior messages in the reply with a ---original message-- line above them, rather than quoting. Note that, when this is done, the cursor inevitably ends up above the message. -- No mechanism for selecting which text is to be quoted as part of the reply command (or button, or whatever) or even any two of those, then one is quite likely to see top-posting -- almost anything else is just too time-consuming. In a better world, the right solution to that type of problem is certainly go find a decent MUA. But, in a world in which the number of MUAs that are well-designed and competently maintained to keep up with technology developments appears to be rapidly declining, the decision to switch tends to involve complex usability and feature tradeoffs, not a straightforward decision to go to something better. In (slight) defense of top-posting (which I definitely choose to do sometimes), if one is replying very briefly and in summary to a long and complex message, it is often more efficient for both the writer and the reader. One should clearly also trim the long message, but, if people get in a hurry and forget ... well, I would hope that we will never again see a time in which the bandwidth or disk space requirements for a few extra paragraphs are sufficiently expensive to be more important than people's time. FWIW, the thing that really irritates me is having someone respond to a message after quoting only a few lines (often good) but without supplying some clue that permits me to find the message being replied to if needed. Whether that is done by inserting some sort of attribution line, copying the author of the prior message on the reply, or even using a good In-reply-to field, assuming that one can quote a few lines, without attribution, because the recipient has obviously read the prior sequence of messages --in sequence and recently-- is just unrealistic, at least IMO. Again, the causes of the problem of replies without prior message context are often more poor UA design than bad user behavior, but that brings us back to the declining population of decent UAs. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On Fri, 24 Sep 2010 09:09:08 -0400 John C Klensin wrote: --On Thursday, September 23, 2010 10:43 -0700 Randy Dunlap rdun...@xenotime.net wrote: ... the same people also complain when I trim. So its a combination of pathological behaviours, UI, and dominance behaviour That should just be a function of where the UI software positions the cursor, shouldn't it? Well, it is a bit more than that. If one had a UI that combines: -- Small screen with tricky selection and scrolling -- Insertion of prior messages in the reply with a ---original message-- line above them, rather than quoting. Note that, when this is done, the cursor inevitably ends up above the message. I don't think that the cursor has to end up there. That's the MUA and it could control where the cursor ends up. -- No mechanism for selecting which text is to be quoted as part of the reply command (or button, or whatever) or even any two of those, then one is quite likely to see top-posting -- almost anything else is just too time-consuming. [snip] In (slight) defense of top-posting (which I definitely choose to do sometimes), if one is replying very briefly and in summary to a long and complex message, it is often more efficient for both the writer and the reader. One should clearly also trim the long message, but, if people get in a hurry and forget ... well, Forget? oh, you are just being too nice. ;) I would hope that we will never again see a time in which the bandwidth or disk space requirements for a few extra paragraphs are sufficiently expensive to be more important than people's time. Yes, I agree, it's about people's time. FWIW, the thing that really irritates me is having someone Ack that. One thing that bothers me is when people do mixed-line posting but end their reply say, 50% thru the message, but then they don't delete the rest of the message, so the reader has to scan the rest of the message to see if there are more comments. This saves time for the (one) sender and wastes time for N readers. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Posting Placement (was Re: Fisking vs Top-Posting)
I tend to assume that people write emails the way they would like to read them. Thus, if I am writing an email with a lot of detailed context from a previous message, I include the revelant portions of the message, and reply in line. However, when I am writing A reply that does not require detailed context, but may depend upon some context for either those who have not been reading everything, or the cases where the thread is complex enough that checking which piece one is responding to (even when the subject should not have changed) can be helpful, then I top post. Why do I top-post? Because I prefer to read email in the preview pane of my email reader. It is much faster for me to read. Top-posts I can generally read in the preview pane with 0 additional clicks. I can go scroll down and read the selected context if I need that. In contrast, with a bottom post I have to scroll through the whole thread, most of which I have read before, just to find out what this poster is adding. Since, as a reader, I strongly prefer to read top-posts, that is how I usually post. In this case, it is pretty clear that the details of the earlier conversation are relevant only to prove that a conversation is taking place, so I will assume readers who care have read those posts, and I have deleted it all. It is very true that if you are trying to parse a thread that you have not been following, a thread where everyone has bottom posted, while retaining sufficient context, is MUCH easier to figure out. I have had more than one thread where I have had to read the top-posts backwards from the bottom to figure out what the heck is going on. But that, for me, is a rare case. Other people probably read differently. So I do not claim that my reading experience is relevant for how other people shoudl post. I will cope however things are posted. I do want to re-iterate two points I have seen that are important. Both are relevant no matter what style of posting you like. 1) People need to read the whole email before composing their response. (You can draft ideas while reading, but make sure you actually read the whole thing before you finalise your response.) 2) People need to edit longer threads so that they do not copy large amounts of redundant and useless text. I will note on 1 that the satiric demonstration of this that followed shortly after the initial note was just beautiful. Thank you. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [certid] Why require EKU for certid?
On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: On 9/14/10 12:51 AM, Stefan Santesson wrote: General: I would consider stating that server certificates according to this profile either MUST or SHOULD have the serverAuth EKU set since it is allways related to the use of TSL and server authentication. At least it MUST be set when allowing checks of the CN-ID (see 2.3 below). [..snip..] What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating. Does this point need discussion? Without checking, I suspect that 5280 says you obey the EKU, period. OTOH I think Paul raises a valid point. OTOH (again) one could argue that the EKU provides a way to prevent a stolen cert/key issued to the machine for a different function from being repurposed to support a fake server. (I'm not convinced this is significant, but it's something.) Absent discussion and consensus, I vote for whatever 5280 says, which I suppose is what the current silence on the topic equates to. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09
On 09/23/2010 01:10 PM, Richard L. Barnes wrote: There is no black magic here, only the magic of the TLS server_name extension. If the client provides server_name=gmail.com, the server provides a gmail.com cert, otherwise it defaults to mail.google.com. Your browser is following two secure delegations before it lands at www.google.com (gmail.com - mail.google.com - www.google.com). I'd not even considered SNI. My guess based on the anecdotes in the thread is that IE8 doesn't support it. Not IE8, but the pre-Vista Windows I was testing it on that doesn't do extensions by default. Which is why I'd not considered that gmail would depend on SNI for its operation. I'd forgotten that this is Google we were talking about and not any other company in the world that would put support for MSIE on Windows XP ahead of protocol standards. :-) (You should also be more careful about your HTTP emulation! A client MUST include a Host header field in all HTTP/1.1 request messages .) Yep, that's why I requested HTTP/1.0. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but also in regards to just caching)
a) Most of the arguments explained in the 2003 IAB Commentary:
Architectural Concerns on the use of DNS Wildcards,
http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html,
apply in a similar fashion, but it indeed would be a good idea
to produce such document. I think much text from 2003 could
be leveraged.
b) It should be clearly spelled out that this practice falls among the
category of actions commonly known as man-in-the-middle attacks.
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
descibe these services in a much too friendly tone;
terms like service and benefits for users are clearly
abuse of language -- the above IAB statement already indicates
that similar interference with the DNS causes severe damage
to user perception and performance.
These drafts should clearly spell out the downside of these
methods and their fundamental nature, being MitM attacks.
d) In my personal opinion, the original idea of having recursive
DNS resolvers located close to the hosts should be given more
traction again in the future. All kinds of SOHO access gateways
or home gateways should preferably offer (locally) full recursive
and validating DNS resolution service. The ISP-based DNS recursor
was (and perhaps still is) a good idea in low-bandwidth (dial-in)
access networks, where the (bandwidth and monetary) costs of full
DNS service actually matter and are detrimental for the users, but
it does not make sense any more for broadband access networks with
(almost) bandwidth-usage independent billing models (flat rates).
Thus the dependency on (both technically and policy-wise!) powerful
central caching resolvers could be reduced dramatically.
DNSSEC validation makes most sense for applications when performed
as close as possible to the stub resolver, if the latter cannot
perform this function itself; this way, the unprotected path
at least is constrained to within the users' sites and hence their
own administrative domain.
Experience has shown that huge central resolver systems are very
attractive targets for external attacks as well as for insider
attacks (like ${subject}).
Kind regards,
Alfred Hönes.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+++
-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
This document is probably relevant, although it goes the route of
providing guidelines for minimum breakage rather than forbidding.
http://tools.ietf.org/html/draft-livingood-dns-redirect-02
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but also in regards to just caching)
a) Most of the arguments explained in the 2003 IAB Commentary:
Architectural Concerns on the use of DNS Wildcards,
http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html,
apply in a similar fashion, but it indeed would be a good idea
to produce such document. I think much text from 2003 could
be leveraged.
b) It should be clearly spelled out that this practice falls among the
category of actions commonly known as man-in-the-middle attacks.
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
descibe these services in a much too friendly tone;
terms like service and benefits for users are clearly
abuse of language -- the above IAB statement already indicates
that similar interference with the DNS causes severe damage
to user perception and performance.
These drafts should clearly spell out the downside of these
methods and their fundamental nature, being MitM attacks.
d) In my personal opinion, the original idea of having recursive
DNS resolvers located close to the hosts should be given more
traction again in the future. All kinds of SOHO access gateways
or home gateways should preferably offer (locally) full recursive
and validating DNS resolution service. The ISP-based DNS recursor
was (and perhaps still is) a good idea in low-bandwidth (dial-in)
access networks, where the (bandwidth and monetary) costs of full
DNS service actually matter and are detrimental for the users, but
it does not make sense any more for broadband access networks with
(almost) bandwidth-usage independent billing models (flat rates).
Thus the dependency on (both technically and policy-wise!) powerful
central caching resolvers could be reduced dramatically.
DNSSEC validation makes most sense for applications when performed
as close as possible to the stub resolver, if the latter cannot
perform this function itself; this way, the unprotected path
at least is constrained to within the users' sites and hence their
own administrative domain.
Experience has shown that huge central resolver systems are very
attractive targets for external attacks as well as for insider
attacks (like ${subject}).
Kind regards,
Alfred HÎnes.
--
+
++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-
Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax:
-18 |
| D-71254 Ditzingen | E-Mail: a...@tr-
Sys.de |
+
++
-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Posting Placement (was Re: Fisking vs Top-Posting)
On Sep 24, 2010, at 11:36 AM, Joel M. Halpern wrote: I tend to assume that people write emails the way they would like to read them. Thus, if I am writing an email with a lot of detailed context from a previous message, I include the revelant portions of the message, and reply in line. However, when I am writing A reply that does not require detailed context, but may depend upon some context for either those who have not been reading everything, or the cases where the thread is complex enough that checking which piece one is responding to (even when the subject should not have changed) can be helpful, then I top post. Why do I top-post? Because I prefer to read email in the preview pane of my email reader. It is much faster for me to read. Top-posts I can generally read in the preview pane with 0 additional clicks. I can go scroll down and read the selected context if I need that. In contrast, with a bottom post I have to scroll through the whole thread, most of which I have read before, just to find out what this poster is adding. Since, as a reader, I strongly prefer to read top-posts, that is how I usually post. I don't much care, but in general I think that a simple WFM or the like should be top posted; otherwise go with what seems the most natural to read. Regards Marshall In this case, it is pretty clear that the details of the earlier conversation are relevant only to prove that a conversation is taking place, so I will assume readers who care have read those posts, and I have deleted it all. It is very true that if you are trying to parse a thread that you have not been following, a thread where everyone has bottom posted, while retaining sufficient context, is MUCH easier to figure out. I have had more than one thread where I have had to read the top-posts backwards from the bottom to figure out what the heck is going on. But that, for me, is a rare case. Other people probably read differently. So I do not claim that my reading experience is relevant for how other people shoudl post. I will cope however things are posted. I do want to re-iterate two points I have seen that are important. Both are relevant no matter what style of posting you like. 1) People need to read the whole email before composing their response. (You can draft ideas while reading, but make sure you actually read the whole thing before you finalise your response.) 2) People need to edit longer threads so that they do not copy large amounts of redundant and useless text. I will note on 1 that the satiric demonstration of this that followed shortly after the initial note was just beautiful. Thank you. Yours, Joel M. Halpern ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect draft-livingood-dns-malwareprotect concerns what is primarily an opt-in service to block known malware sites for end users. Hopefully that is less controversial than the redirect one, but who knows. draft-livingood-dns-redirect was written to do two things. First was to document a relatively long-standing process in a reference-able IETF document where no documentation previously existed. Second was to document the best or least worst way to approach it, if a party was planning to do so. Since that time, I've added a bunch of stuff related to DNSSEC to make clear an incompatibility there. I'm a bit conflicted though about whether to keep it as informational or consider historic. In any case, as noted below, I'm more than happy to consider any text that might improve these document by providing more information on opposing viewpoints, etc. descibe these services in a much too friendly tone; terms like service and benefits for users are clearly abuse of language -- the above IAB statement already indicates Sorry you feel that way. Operators view these as services and describe them as such, so I am simply using that language. As I do my next pass through the documents I will review it for any non-neutral descriptors. Of course, also feel free to email me a list of the ones you think I should consider revising in some manner. that similar interference with the DNS causes severe damage to user perception and performance. The 2nd draft concerns protection from malware, which is generally assumed to be a service that users opt-into (a la OpenDNS, etc.). Those users who have decided to use such services very likely are much more concerned with malware than the fact that FQDNs associated with malware would be blocked. Again, I'm quite willing to include text you wish to propose to capture alternative viewpoints and criticisms, as that's an important part of such a document IMHO. These drafts should clearly spell out the downside of these methods and their fundamental nature, being MitM attacks. I'm happy to consider any text you would like to propose, and am quite willing to include specific notes that some in the community consider the techniques MitM attacks, in order to try to capture all viewpoints on the subject. Feel free to send any proposed text to me via email. Regards, Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On Fri, 24 Sep 2010, John C Klensin wrote: FWIW, the thing that really irritates me is having someone respond to a message after quoting only a few lines (often good) but without supplying some clue that permits me to find the message being replied to if needed. [...] or even using a good In-reply-to field, [...] Another example of Outlook's bad interoperability. I believe that there was one release in which it implemented standard message threading, but some bright spark decided to reinvent the wheel badly. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
At 6:18 PM + 9/24/10, Livingood, Jason wrote: I'm a bit conflicted though about whether to keep it as informational or consider historic. If it describes something that you believe is currently deployed, even if you think that deployment is non-optimal, it should be marked as Informational. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote: At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote: Has the IETF (or rather then IAB) written any simple documents that explain to less informed (i.e. marketing/product) managers why it is a bad thing for a captive portal to spoof DNS replies? (not just in regard to DNSSEC, but also in regards to just caching) a) Most of the arguments explained in the 2003 IAB Commentary: Architectural Concerns on the use of DNS Wildcards, http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html, apply in a similar fashion, but it indeed would be a good idea to produce such document. I think much text from 2003 could be leveraged. One important thing to realize is that this kind of service isn't always implemented using wildcards. Sometimes the service is implemented using interception proxies. b) It should be clearly spelled out that this practice falls among the category of actions commonly known as man-in-the-middle attacks. Agreed. Actually, when a server or interception proxy deliberately misrepresents the contents of others' DNS zones, the appropriate term (IMO) is fraud. IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect descibe these services in a much too friendly tone; Strongly agree, at least for the -redirect draft. At the very least, a distinction needs to be made between services which the individual user deliberately chooses, and services which are imposed without the users' knowledge or consent. The draft also glosses over the problems created by this practice for all applications other than web browsing by human beings. Not only does this provide misleading error indications for all other applications, it even breaks applications that are layered on top of HTTP. d) In my personal opinion, the original idea of having recursive DNS resolvers located close to the hosts should be given more traction again in the future. All kinds of SOHO access gateways or home gateways should preferably offer (locally) full recursive and validating DNS resolution service. Agree with this also. In many cases the ideal model seems to be one in which the host serves as its own primary DNS server, or at least as the master DNS zone. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. I'm not a lawyer either, but I at least know that fraud requires intent. If a naive user clicks on a link in spam, and the DNS cache intercepts the request and returns a pointer to a warning page rather than a Ukranian malware site, that's not fraud, that's a service. If you claim otherwise, people will look at you quizzically, like you're spouting nonsense, which under the circumstances would be understandable. It also reinforces the perception that the IETF is out of touch and hasn't noticed that it's no longer 1990. Any analysis of DNS spoofing needs to take into account intentions and tradeoffs. On networks of consumer PCs, intercepting requests for malware sites is a 100% win. I'm not thrilled about the practice of replacing NXDOMAIN with the A record of a page of links to lexically similar web sites, but the actual harm of doing that on consumer networks (not networks with servers) is pretty hard to show. Replacing a valid record that isn't a pointer to malware with another is indeed bad, but I don't know anyone who does that. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Sep 24, 2010, at 5:17 19PM, John Levine wrote: IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. I'm not a lawyer either, but I at least know that fraud requires intent. If a naive user clicks on a link in spam, and the DNS cache intercepts the request and returns a pointer to a warning page rather than a Ukranian malware site, that's not fraud, that's a service. If you claim otherwise, people will look at you quizzically, like you're spouting nonsense, which under the circumstances would be understandable. It also reinforces the perception that the IETF is out of touch and hasn't noticed that it's no longer 1990. Any analysis of DNS spoofing needs to take into account intentions and tradeoffs. On networks of consumer PCs, intercepting requests for malware sites is a 100% win. I'm not thrilled about the practice of replacing NXDOMAIN with the A record of a page of links to lexically similar web sites, but the actual harm of doing that on consumer networks (not networks with servers) is pretty hard to show. Replacing a valid record that isn't a pointer to malware with another is indeed bad, but I don't know anyone who does that. It will be interesting to see what will happen to these services when DNSSEC is used more widely. Me -- VPNs are your friend; I use them to deflect all sorts of damage. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
It will be interesting to see what will happen to these services when DNSSEC is used more widely. Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Malware that infects browsers and rewrites bank transactions on the fly is a huge problem, particularly in Europe, and requires no DNS funny business at all. We can certainly imagine attacks that depend on DNS poisoning, but any tradeoff that makes it easier to get infected by malware is, for typical PC users, a foolish one. Be careful what you ask for, and all that. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
--On Friday, September 24, 2010 08:17 -0700 Randy Dunlap rdun...@xenotime.net wrote: One thing that bothers me is when people do mixed-line posting but end their reply say, 50% thru the message, but then they don't delete the rest of the message, so the reader has to scan the rest of the message to see if there are more comments. This saves time for the (one) sender and wastes time for N readers. Again, if we all had consistent habits, many of these things would be non-problems. But we don't, and I don't know how to fix that. For that case in particular, I've sometimes done it deliberately, but... -- I always close/sign actual messages by typing my name, not relying on some signature block. So, if you see john or --john, not immediately following by a p.s. or something else with a forward pointer from the text above, I'm finished. -- Given that, I sometimes leave additional text as context for those who might need it, expecting that others will understand that they don't need to read anything after the signature line. Your comment suggests that expectation has been unreasonable. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
Tony == Tony Finch d...@dotat.at writes: Tony On Fri, 24 Sep 2010, John C Klensin wrote: FWIW, the thing that really irritates me is having someone respond to a message after quoting only a few lines (often good) but without supplying some clue that permits me to find the message being replied to if needed. [...] or even using a good In-reply-to field, [...] Tony Another example of Outlook's bad interoperability. I believe Tony that there was one release in which it implemented standard Tony message threading, but some bright spark decided to reinvent Tony the wheel badly. Yes. And now we have 15 years of this bad behaviour. My new financial planner had actually NEVER seen someone not top-quote, and he actually thought his computer was broken, and couldn't figure out how my text had moved. I do not think he realizes that you can even edit the quoted text. He is less than 30, so literally, he has never used anything else. I've also been told that some organizations retain everything as audit. (If they really wanted that, they should use message/rfc822, with an embedded signature) Such a nice social engineering hack on them to start CC'ing someone with a made up history of some dispute, and claim it is true, alas, I've never found a sufficiently interesting situation to bother trying it out. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NomCom 2010-2011: List of Willing Nominees has been Updated
Hi Folks, List of Willing Nominees has been updated: -- The second announced listing of willing nominees for the IETF open positions is now available at https://wiki.tools.ietf.org/group/nomcom/10/input/ In the past, such information was available only to a subset of the community. Now, for this NomCom, it is made available to everyone in the community and it is easy to obtain. How to access the list: --- To access the list (which is available to anyone), you will be asked to login. Any login you've used to subscribe to an IETF mailing list should work here. But if it doesn't, then you can easily obtain a username/password from tools.ietf.org as follows: Just select Get Passwd from the left margin and it will take you to the new login page. User name will be your email address and you can then request a password at this page http://trac.tools.ietf.org/newlogin Who is listed? -- The names you see are only the nominees who have accepted a nomination for one (or more) of the open IETF positions at this point in time. Since the Call for Nominations remains open until October 1, 2010, this list is expected to grow. Who is not listed? -- It is important to realize this list does not include the names of people who have been nominated for a position and who either (a) have not accepted a nomination or (b) may have accepted but have yet to be listed. If you sent an acceptance more than 24 hours ago, and are not listed please contact the NomCom chair. Additional Nominations needed: -- More nominations are needed, particularly for most IESG open positions. Self nomination is welcome. Nominations remain open until October 1. Instructions on how to nominate someone for one or more of the IETF open positions is found in the call for nominations at https://datatracker.ietf.org/ann/nomcom/2468/ The list of open positions can be found at: http://wiki.tools.ietf.org/group/nomcom/10/ Feedback: - The open list disclosure by this NomCom is to support the feedback process. NomCom can accept feedback at any time. Detailed instructions on submitting feedback will be posted in a separate message. If you wish to provide anonymous feedback, the chair and any of the members will be happy to handle this for you. The Nominating Committee chair can be reached at nomcom-ch...@ietf.org and the entire nominating committee can be reached at nomco...@ietf.org. The email addresses of individual NomCom members is also on the NomCom 2010-2011 pages a https://wiki.tools.ietf.org/group/nomcom/10/ Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Second Last Call: draft-nottingham-http-link-header-10.txt (Web Linking) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Web Linking' draft-nottingham-http-link-header-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-10-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ The purpose of this Second Last Call is to confirm some late changes to the IANA procedure/registry. The following changes are proposed: In Section 6.2 (Link Relation Type Registry), add the 2nd paragraph that reads: The underlying registry data (e.g., the XML file) must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions (http://trustee.ietf.org/license-info). In Section 6.2.1 (Registering New Link Relation Types), delete the following paragraph: When a registration request is successful, the Designated Expert(s) will update the registry XML file (using the format described in Appendix A including the MIT license) and send it to the link-relations-annou...@ietf.org mailing list (which SHOULD NOT be centrally archived, so as to avoid load issues from automated agents, and only accept posts from the Designated Expert(s)), so that implementers interested in receiving a machine-readable registry can do so. Simultaneously, they will send a text (not XML) version of the registry to IANA for publication. And finally, delete the whole Appendix A (together with A.1, which describes the Relax NG grammar) which reads: Appendix A. Link Relation Registry Format To facilitate applications that wish to use registry data in an automated fashion, this specification defines an XML-based format for the registry entries. Each registered relation type is represented by a RelationType element, and if any of the app data values are other than the default value identified in the Application Data registry, they will be represented by appdata elements. Note that this format is NOT that in which IANA publishes the registry, because doing so would subject IANA's servers to, potentially, very high load (e.g., if Web browsers were to automatically update their copies of the registry). Instead, this format is published to the link-relations-annou...@ietf.org mailing list, so that interested implementers can subscribe and distribute the machine-readable document using their own infrastructure. No IPR declarations were found that appear related to this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6019 on BinaryTime: An Alternate Format for Representing Date and Time in ASN.1
A new Request for Comments is now available in online RFC libraries. RFC 6019 Title: BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 Author: R. Housley Status: Standards Track Stream: IETF Date: September 2010 Mailbox:hous...@vigilsec.com Pages: 6 Characters: 11394 Obsoletes: RFC4049 URL:http://www.rfc-editor.org/rfc/rfc6019.txt This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
