Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 19, 2006, at 12:30 PM, Stephen Farrell wrote: I wish you'd stop with the spurious figures. These figures strongly suggest the recommendation in section 5.2 is inadequate to accommodate lapses in availability owing to vacations, when that is important to the sender. Section 5.2 ... ,--- | A signer SHOULD NOT sign with a key that is expected to expire within | seven days; that is, when rotating to a new key, signing should | immediately commence with the new key and the old key SHOULD be | retained for at least seven days before being removed from the key | server. '___ A safer recommendation would be: : A signer SHOULD NOT sign with a key that is expected to expire within : a transit period where protection is desired; that is, when rotating : to a new key, signing should immediately commence with the new key : and the old key SHOULD be retained for at least the period where : transit protection is desired before being removed from the key : server. Again, all this is an aside for us. There's no required correlation between x= and key life cycles. Please stop flogging that dead horse. The x= parameter is a totally separate issue. Where have I conflated the two? There: [1]. Took all of 5 seconds to find one. There are others. [1] http://mipassoc.org/pipermail/ietf-dkim/2006q2/003248.html Hector made the inference key availability and the x= parameter are related. My statement was simply: "When the transport includes IMAP and POP, this 7 day advice is far too short of a period to ensure verification." This was referring to section 5.2 and was not commenting upon the conclusion reached by Hector. My apologies for not changing the subject line. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Doug, I wish you'd stop with the spurious figures. Douglas Otis wrote: Again, all this is an aside for us. There's no required correlation between x= and key life cycles. Please stop flogging that dead horse. The x= parameter is a totally separate issue. Where have I conflated the two? There: [1]. Took all of 5 seconds to find one. There are others. Stephen. [1] http://mipassoc.org/pipermail/ietf-dkim/2006q2/003248.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 19, 2006, at 1:33 AM, Stephen Farrell wrote: Douglas Otis wrote: When a large portion of a country's population goes on vacation for 5 Exactly what portion is that? What portion of the population would be enough to matter? "The expected transit time of a message from originator to recipient" refers to transit latency where originators and recipients are typically people. A measure of "normal" or the mean of person to person email message transit latency will be within the realm of a few days at most. Concerns related to how long a key should remain available to protect this transit period must consider typically induced latencies due to common human behavior. While machine to machine latencies are often measured in seconds, but still equipment failure recovery often gives up after 5 days. Transports beyond SMTP listed as being protected by DKIM carry the message to the recipient. These transports may suffer typical spikes in latency when a person is on vacation. Unusual behaviors will not be attractive, as the bad actor would have trouble knowing when to exploit this behavior. The question of expected transit time requires the consideration of what is "typical" human behavior. The DKIM charter appears to ask the question of expected transit times of messages between humans. The norm is not interesting, but social behavior is predicable. The WG may conclude the mailbox following a vacation will not be assured protection based upon their inadequate recommendations. This would be unfortunate. A criminal could easily take advantage of such poor recommendations and run phishing expeditions during typical vacation periods. People, being social, often exhibit predictable behaviors that criminals often exploit. Going on vacation is a classic example. A person coming back from vacation finding urgent notices from their bank, who also learns messages do not verify after a few days, would be exposed to possible exploits that deliberately spoof such messages knowing many other valid messages will also not verify. In a quote from the Cornell page: "In Europe, vacation time often occurs in August--all of August! A European Union directive prescribes four weeks annual leave for all employees (EC 93/104 Art.7(1))." Average Number of Vacation Days Per Year Italy 42 days France 37 days Germany 35 days Brazil 34 days United Kingdom 28 days Canada 26 days Korea 25 days Japan 25 days U.S.13 days Source: World Tourism Organization (WTO). I bet a beer that there are more Swedes that have an email address they never or sporadically read than there are Swedes that regularly read mail except for during their supposed 5-week offline. But that's as bogus as your assertion, since its also based on no data. At this point in time, until some data supports the duration of the typical spikes in latency due to vacations, assuming the WG decides to protect recipients over their vacation, the recommendations made in Section 5.2 in the base draft should only explain what the key availability duration should cover, and not indicate that 7 days is okay. In my view, 7 day key availability is not adequate to protect emails to the recipient at the MUA. By assuring protection at the MUA, DKIM can offer protection once the sender starts signing their messages, and the recipient obtains an email client able to verify DKIM signatures. No other dependency would slow DKIM deployment and use. There would be no delay induced waiting for the deployment results header handling, for example. If you've got a real distribution, then that'd be interesting. Deriving/divining a figure of 6.26 days without that isn't usefully more interesting. Maybe John would like ASRG to include this as part of their work. The standard deviation figure was mentioned to explain that the nature of the distribution of the data must be considered before making conclusions about what a standard deviation implies. If the WG decides to protect individuals over their vacation, then the duration of these vacations could be assessed using statistics. Looking at POP polling intervals and running statistics on this information as a whole will overwhelm the information related to vacations. Looking for periods longer than a few days of no polling might provide suitable information. With the US typically taking short vacations, the more interesting data would also likely be found elsewhere. Again, all this is an aside for us. There's no required correlation between x= and key life cycles. Please stop flogging that dead horse. The x= parameter is a totally separate issue. Where have I conflated the two? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rul
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Douglas Otis wrote: When a large portion of a country's population goes on vacation for 5 Exactly what portion is that? I bet a beer that there are more Swedes that have an email address they never or sporadically read than there are Swedes that regularly read mail except for during their supposed 5-week offline. But that's as bogus as your assertion, since its also based on no data. If you've got a real distribution, then that'd be interesting. Deriving/divining a figure of 6.26 days without that isn't usefully more interesting. Maybe John would like ASRG to include this as part of their work. Again, all this is an aside for us. There's no required correlation between x= and key life cycles. Please stop flogging that dead horse. S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote: Douglas Otis wrote: If 7 days provides for the SMTP transport, and people in Sweden and France want to verify messages following their 5 week vacation, then this would require a minimum of 42 days of key availability. The suggestion for 45 days provided an additional 3 days to assure availability following such a vacation. Eh... That's nonsense. You may as well say that if I choose to stay offline for a year, then everyone has to abide by that and leave keys lying about until I'm back. When a large portion of a country's population goes on vacation for 5 weeks (or maybe all of August), as provided by local laws, 90% of the time they would have normal access to their email. This would significantly affect the distribution of transit delays. A message verified at the MUA, where keys are removed every few days, then expose these individuals to the fraud DKIM could have prevented, even when only checked at the MUA. August may become a phishing season. : ( If you knew the distribution of transit times based on some reasonable sample, then I'd listen. Presumably there's a bell curve in there and we could argue about how many std. devs. to ask signers to take into account. Anything less soundly based is only as good as our charter, i.e. "a few days at most" so we may as well stick with that. "A few days at most" is _not_ what the charter says. "... the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. Most engineers would read this sentence differently, looking for what is being measured. Normal latency is _really_ not important nor significant consideration for establishing a limit. Consider a European work schedule with an 8 hour work day 5 days a week, where email access is obtained from a system at the work place. The standard deviation for email access latency would be about 50 hours. Key availability needs to accommodate the possible SMTP latency of 7 days + access latency where 16/48 hours may be predominate latency. This latency would suggest 99% of an area under a Gaussian bell curve or normal distribution would be encompassed by adding an additional 6.26 days to that needed for SMTP latency. The problem with this conclusion is that the distribution caused by a vacation is _not_ Gaussian. Ostensibly non-arbitrary vacation rules don't count. The fact that you forgot maternity/paternity/parental leave e.g. in Bayern or Ireland and the fact that those durations differ and change outside the control of the IETF are all exceptionally good indicators that you're basically way off base. Human behaviors are always outside the control of an IETF standard, however a protective standard should accommodate typical human behaviors. In some countries, a human induced latency within the MUA transport may commonly extend for better than a full month, where the mean is still 50 hours. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Lyndon Nerenberg wrote: Real, significant, usable, numbers would be welcome. I've not seen any. I'll see what I can pull from the mail logs at work. We push a couple of million messages a day, and exercise the AOL and Yahoo mail throttles on an ongoing basis. That'd be great. Esp. if you could co-ordinate with a few others first that see similar distributions. Thanks, S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Real, significant, usable, numbers would be welcome. I've not seen any. I'll see what I can pull from the mail logs at work. We push a couple of million messages a day, and exercise the AOL and Yahoo mail throttles on an ongoing basis. --lyndon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Lyndon Nerenberg wrote: On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote: If you knew the distribution of transit times based on some reasonable sample, then I'd listen. Presumably there's a bell curve in there and we could argue about how many std. devs. to ask signers to take into account. Anything less soundly based is only as good as our charter, i.e. "a few days at most" so we may as well stick with that. Factoring on normal successful deliveries misses an uncommon, How (un)common? > but important, class of messages: those delayed by temporary transport failures. E.g. hardware-induced SMTP server failure, intermediate network outages, system- and network-admin PEBKAC, recipient mail store quota violations, and inbound SMTP server throttling (AOL, Yahoo). All of these are out of the transacting parties control (even the quota case, since the receiver can't always control what gets dumped in their inbox). What we need to examine are the stat's related to these delay scenarios, and base the lifetime on those numbers, ignoring the typical successful delivery case. (My guess is that sendmail's default delivery timeout will heavily influence the results.) Real, significant, usable, numbers would be welcome. I've not seen any. Absent such we're back at the charter text. S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote: If you knew the distribution of transit times based on some reasonable sample, then I'd listen. Presumably there's a bell curve in there and we could argue about how many std. devs. to ask signers to take into account. Anything less soundly based is only as good as our charter, i.e. "a few days at most" so we may as well stick with that. Factoring on normal successful deliveries misses an uncommon, but important, class of messages: those delayed by temporary transport failures. E.g. hardware-induced SMTP server failure, intermediate network outages, system- and network-admin PEBKAC, recipient mail store quota violations, and inbound SMTP server throttling (AOL, Yahoo). All of these are out of the transacting parties control (even the quota case, since the receiver can't always control what gets dumped in their inbox). What we need to examine are the stat's related to these delay scenarios, and base the lifetime on those numbers, ignoring the typical successful delivery case. (My guess is that sendmail's default delivery timeout will heavily influence the results.) --lyndon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Doug, Douglas Otis wrote: If 7 days provides for the SMTP transport, and people in Sweden and France want to verify messages following their 5 week vacation, then this would require a minimum of 42 days of key availability. The suggestion for 45 days provided an additional 3 days to assure availability following such a vacation. Eh... That's nonsense. You may as well say that if I choose to stay offline for a year, then everyone has to abide by that and leave keys lying about until I'm back. If you knew the distribution of transit times based on some reasonable sample, then I'd listen. Presumably there's a bell curve in there and we could argue about how many std. devs. to ask signers to take into account. Anything less soundly based is only as good as our charter, i.e. "a few days at most" so we may as well stick with that. Ostensibly non-arbitrary vacation rules don't count. The fact that you forgot maternity/paternity/parental leave e.g. in Bayern or Ireland and the fact that those durations differ and change outside the control of the IETF are all exceptionally good indicators that you're basically way off base. The real point is that there is no required correlation between x= and the duration for which a key is made available (!= being available) in DNS. There are many reasons why x= can be in the future but yet no key is available to check a signature. Endless argument about some subset of those is unproductive. So, let's move on. This is a useless dead-end. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 5:36 PM, Stephen Farrell wrote: Doug, Your response is non-responsive :-( Douglas Otis wrote: On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote: Douglas Otis wrote: The duration of the signature should cover the "expected" distribution of transit times for a message from the originator to recipient. Sure. Can you get us the peer reviewed stats so we can remove those quotes from "expected"? I certainly don't have 'em, and in the absence of such real, agreed-upon information I think we're just wasting time speculating. Section 5.2 in the base draft makes an _unsupported_ speculation about adequate key availability. The transit period should extend beyond norms for SMTP, as indicated in other places within the this Base and the Threat draft, when describing MUA signing and verification. So you have no data to offer. When talking about transports, such as those related to the MUA, transit times include SMTP delivery plus delays created by the typical vacation/convention/civic duties, etc. If 7 days provides for the SMTP transport, and people in Sweden and France want to verify messages following their 5 week vacation, then this would require a minimum of 42 days of key availability. The suggestion for 45 days provided an additional 3 days to assure availability following such a vacation. The table below outlines minimum paid vacation mandates for full time workers: Country Vacation Time Argentina 14 calendar days Australia No national law, but 4 weeks is standard Belgium 20 days, premium pay Bulgaria20 business days Canada At least 2 weeks, determined by provincial law Chile 15 working days Czech Republic 4 weeks France 5 weeks Germany 4 weeks Hong Kong 7 days Hungary 20 work days Ireland 4 weeks Israel 14 days Italy Mandated vacation, length determined by employment contract Japan 10 days paid time off (includes other leave time) Mexico 6 days Poland 18 working days Puerto Rico 15 days Saudi Arabia15 days Singapore 7 days South Africa21 consecutive days South Korea 10 working days Spain 30 calendar days Sweden 5 weeks Taiwan 7 days The Netherlands 4 weeks Turkey 12 work days UK No national law, implementing EC directive (4 weeks annual leave) Ukraine 24 calendar days US No national requirement. Some public employee requirements. Venezuela 15 paid days Source: Keller, William L., Timothy J. Darby, and American Bar Association. International Labor Law Committee. International Labor and Employment Laws. 2 vols. Washington, D.C.: Bureau of National Affairs, 1997, 2002 Supplements http://www.ilr.cornell.edu/library/research/QuestionOfTheMonth/ archive/vacationtime.html Concerns regarding how long a key should remain available depends upon what transport is being protected by the signature/key mechanism. The desire was to focus upon determining the transports, rather than offering conservative estimates for what the transports may require when accessed directly by the recipient. Too short a period unfortunately removes protection from some of these transports. There are recent mails talking about "months later", those discussions are not, IMO, in scope and are significantly distracting. Deciding whether other transports beyond SMTP might expect protection by DKIM message verification could be productive without too much distraction. DKIM is to be used for: 1) SMTP only Starting at the MSA and ending at the MDA mailbox. 2) SMTP + other transports Starting at the originator and ending when first viewed by the recipient. So we agree that "months later" is irrelevant. Good. What is relevant is the transport being protected. Each transport demands a different duration of key availability, even though in most cases, the key will be used within a few days. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Doug, Your response is non-responsive :-( Douglas Otis wrote: On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote: Douglas Otis wrote: The duration of the signature should cover the "expected" distribution of transit times for a message from the originator to recipient. Sure. Can you get us the peer reviewed stats so we can remove those quotes from "expected"? I certainly don't have 'em, and in the absence of such real, agreed-upon information I think we're just wasting time speculating. Section 5.2 in the base draft makes an _unsupported_ speculation about adequate key availability. The transit period should extend beyond norms for SMTP, as indicated in other places within the this Base and the Threat draft, when describing MUA signing and verification. So you have no data to offer. There are recent mails talking about "months later", those discussions are not, IMO, in scope and are significantly distracting. Deciding whether other transports beyond SMTP might expect protection by DKIM message verification could be productive without too much distraction. DKIM is to be used for: 1) SMTP only Starting at the MSA and ending at the MDA mailbox. 2) SMTP + other transports Starting at the originator and ending when first viewed by the recipient. So we agree that "months later" is irrelevant. Good. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote: Douglas Otis wrote: The duration of the signature should cover the "expected" distribution of transit times for a message from the originator to recipient. Sure. Can you get us the peer reviewed stats so we can remove those quotes from "expected"? I certainly don't have 'em, and in the absence of such real, agreed- upon information I think we're just wasting time speculating. Section 5.2 in the base draft makes an _unsupported_ speculation about adequate key availability. The transit period should extend beyond norms for SMTP, as indicated in other places within the this Base and the Threat draft, when describing MUA signing and verification. There are recent mails talking about "months later", those discussions are not, IMO, in scope and are significantly distracting. Deciding whether other transports beyond SMTP might expect protection by DKIM message verification could be productive without too much distraction. DKIM is to be used for: 1) SMTP only Starting at the MSA and ending at the MDA mailbox. 2) SMTP + other transports Starting at the originator and ending when first viewed by the recipient. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Doug, Douglas Otis wrote: The duration of the signature should cover the "expected" distribution of transit times for a message from the originator to recipient. Sure. Can you get us the peer reviewed stats so we can remove those quotes from "expected"? I certainly don't have 'em, and in the absence of such real, agreed-upon information I think we're just wasting time speculating. There are recent mails talking about "months later", those discussions are not, IMO, in scope and are significantly distracting. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 2:25 PM, Stephen Farrell wrote: Douglas Otis wrote: On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote: There's been a good bit of MUA related discussion about long time periods. Our charter says explicitly that the following is out of scope: * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. The term transit however does include the IMAP and POP transport and the recipient may perform DKIM verifications at the MUA rather than elsewhere. The difference between 7 and 45 days does not make this a "long term" assertion. Seems like it does to me: "a few days at most" is pretty clear. The duration of the signature should cover the "expected" distribution of transit times for a message from the originator to recipient. The Threat and Base draft specifically includes the IMAP and POP MUAs as suitable transports using DKIM verification. Many emails are received by their recipients over these transports within a few days. A normal transit time does not describe the "expected" distribution of transit times however. A good design should encompass a large percentage of the distribution of transit times. Not all email will transit within a few days, and not all email is transmitted and verified exclusively by servers using SMTP. If the goal is to provide a signature only to be verified between SMTP MTAs, then the Threat and Base draft need to be substantially changed to reflect this design constraint. Creating a flow of about- to-expire messages does not offer significant protection from message replay abuse, which will still thrive within the current 7 day limit. (Even 7 days is more than a few days.) A statement of what is normal should not affect the consideration for the period of availability needed to reasonably cover the expected distribution of transit times over SMTP, IMAP, POP, UUCP, HTTP, etc. The charter criteria is clear, the signature should cover the transit duration from originator to recipient. This statement does not appear to limit the signature availability to a few days, it only indicates what is normally seen for transit times. Normal is not very interesting when setting limits. A greater amount of information must be considered when setting such limits and why they call it engineering. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Stephen Farrell wrote: There's been a good bit of MUA related discussion about long time periods. Our charter says explicitly that the following is out of scope: * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. A good part of the discussion seems to me to fall under this heading. So while MUA verification isn't precluded, that bullet says that we should not spend time figuring out what needs to happen in an MUA, or indeed anywhere, months after signing. Thank you. That said, what I'd really, really, really like is a DKIM signer plugin for Thunderbird. I've looked at the plugin for the DK verifier and have come to the conclusion that I'm old and in the way. unhipply yours, Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
Doug, Douglas Otis wrote: On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote: There's been a good bit of MUA related discussion about long time periods. Our charter says explicitly that the following is out of scope: * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. The term transit however does include the IMAP and POP transport and the recipient may perform DKIM verifications at the MUA rather than elsewhere. The difference between 7 and 45 days does not make this a "long term" assertion. Seems like it does to me: "a few days at most" is pretty clear. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote: There's been a good bit of MUA related discussion about long time periods. Our charter says explicitly that the following is out of scope: * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. The term transit however does include the IMAP and POP transport and the recipient may perform DKIM verifications at the MUA rather than elsewhere. The difference between 7 and 45 days does not make this a "long term" assertion. The goal of DKIM offering protection for the "expected transit time", ensuring the message reaches the "recipient", remains the critical criteria which seems well within the charter. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On Apr 18, 2006, at 1:03 PM, Scott Kitterman wrote: On 04/18/2006 15:43, Douglas Otis wrote: Or the primary goal of offering protection for all obtainable use cases? I guess we disagree about MUA level verification being obtainable. I actually have some e-mail accounts I only check about once or twice a year. If we design for the MSA-MTA-MDA case, it should cover most typical MUA cases too. When the design criteria handles the typical MUA use scenarios, it would also meet the needs of the MSA/MDA verification case. Checking email every 6 months does not represent the typical use of email. In the MSA-MTA-MDA case we can place an upper bound on how long from signing to delivery. With the MUA case, we could spend weeks arguing over it to no point. DKIM verification is still specified as taking place beyond the MDA. MUA verification was the reason for excluding the envelope. The MUA use case has already resulted in design considerations. MUA level verification will never have the same level of reliability as MTA/MDA verification for a variety of reasons, of which this is only one, so lets not focus on it. The MUA verifications should not have lower reliability due to poor key availability recommendations. As this is forgoing perhaps critical protections, there should be a reason offered besides verification at the MUA may take longer. Add a statement that MUA verifications may take longer than verification at the MDA. 5.2 Select a private-key and corresponding selector information ,--- | A signer SHOULD NOT sign with a key that is expected to expire within | seven days; that is, when rotating to a new key, signing should | immediately commence with the new key and the old key SHOULD be | retained for at least seven days before being removed from the key | server. '__ Here the draft has completely discounted DKIM verification at the MUA. : ( To ensure MUA verification remains practical and safe, the draft should change key availability recommendations. : A signer SHOULD NOT sign with a key that is expected to expire within : 45 days; that is, when rotating to a new key, signing should : immediately commence with the new key, and the old key SHOULD be : retained for at least 45 days before being removed from the key : server. Adding the expiry within the key could still retain the shorter SMTP acceptance constraint. : A signer SHOULD NOT sign with a key that is expected to expire within : 45 days; that is, when rotating to a new key, signing should : immediately commence with the new key, and the old key SHOULD be : retained for at least 45 days before being removed from the key : server. The signer may add a retirement date that represents the : time the key was no longer used for signing. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
There's been a good bit of MUA related discussion about long time periods. Our charter says explicitly that the following is out of scope: * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. A good part of the discussion seems to me to fall under this heading. So while MUA verification isn't precluded, that bullet says that we should not spend time figuring out what needs to happen in an MUA, or indeed anywhere, months after signing. So let's move on. Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
On 04/18/2006 15:43, Douglas Otis wrote: > On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote: > > I would not say that we shouldn't include DKIM protection beyond > > SMTP, but that whatever happens after delivery shouldn't distract > > us from the primary use case. > > Or the primary goal of offering protection for all obtainable use cases? > I guess we disagree about MUA level verification being obtainable. I actually have some e-mail accounts I only check about once or twice a year. If we design for the MSA-MTA-MDA case, it should cover most typical MUA cases too. In the MSA-MTA-MDA case we can place an upper bound on how long from signing to delivery. With the MUA case, we could spend weeks arguing over it to no point. MUA level verification will never have the same level of reliability as MTA/MDA verification for a variety of reasons, of which this is only one, so lets not focus on it. If you'd like some experience with this, you can go play with the Thunderbird Extension for Sender Verification. http://taubz.for.net/code/spf/ In the end, deployed experience with DKIM will tell us how long to leave keys in DNS. No point in getting to worked up over it now anyway. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
