Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05

From: Eric Burger <[email-masked]>
Date: Sat, 28 Dec 2013 09:22:43 -0500

Would it not make sense to say that time is on the granularity of day or even week? I doubt time of day would be important. 

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger

-------- Original message --------
From: Hector Santos <[email-masked]> 
Date:12/28/2013  8:44 AM  (GMT-05:00) 
To: [email-masked] 
Cc: Dave Crocker <[email-masked]>,"Murray S. Kucherawy" <[email-masked]>,Eric Burger <[email-masked]>,[email-masked],The IESG <[email-masked]>,IETF Apps Discuss <[email-masked]> 
Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 

On 12/26/2013 5:15 PM, Dave Crocker wrote:

> Experimental status is for the purpose of understanding a protocol
> that might not be well enough understood, yet, or with exploring its
> possible dangers.  Neither is at issue here.

Dave,

This proposal is impossible to implement *without* a sound 
client/server time negotiation contract and definition.  As such, it 
contains many privacy and security exposure problems.  That certainly 
fits your definition for experimental status.

I will add it also increases new level of both client domain and 
server domains responsibilities and product liability issues that can 
not be ignored.  As Eric pointed out with SOX and HIPAA regulatory 
compliancy considerations, you also have PCI/DSS (Payment Card 
Industry/Data Security Systems) industry compliancy issues to contend 
with as well.

Without a client/server time definition, you are not sure what times 
are being issued by different RRVS clients and the clients themselves 
will not be sure what backend user times will they be compared with. 
  This is a higher risk and thus until it is well know what times are 
being used, I can not at this time endorse implementing it (for our 
package).

On the other hand, we perhaps know that times YAHOO or FACEBOOK are 
expecting so if this proposal is documenting the YAHOO/FACEBOOK 
behavior for time negotiations as a standard, this would be more 
acceptable and practical for implementation.

If not, there are more project R&D that need to be done.  For example, 
there might be a Sender Domain Time Definition Factor in the 
negotiating handshake for message acceptability.  If you say there is 
not, then this presumes a single design time definition by all clients.

Finally, with the advent of increased industry awareness to better 
"engineer" privacy and security considerations into our protocols, it 
is prudent that we have these discussions about having a solid 
understanding on how these protocols are expected to work.  Its about 
"Getting it right, the first time."  Increasing the engineering 
quality of the work.  Hopefully, to reduced all lost of 
project/product R&D investment being asked to be done.

IMO, with all the unknowns, especially with the inability to implement 
this without resolving these unknowns, eliminating or reduction 
potential security related concerns with these exposures, qualifies 
this proposal as an experimental status.   The IETF should consider it 
as an experiment when there are still many unknowns.

Thanks for your considerations.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Dec 2013 11:44:10 -0500

On 12/28/2013 9:22 AM, Eric Burger wrote:

>Would it not make sense to say that time is on the granularity of day
> or even week? I doubt time of day would be important.

For this special proposed RRVS *security* protocol, the only concern I 
can see with a reduced granularity would be a security one.

At the security level, a possible threat with SMTP session brute force 
timestamp attacks where different RRVS commands are retried with 
different time stamps. What may become a PR (and legal) concern with 
this RRVS "security" proposal and promotion is the claim that 
traditional SMTP transaction acceptance can be turned into a rejection 
with the addition of a timestamp, thus providing a new technology and 
method to offer better secured and user verified and RRVS 
authenticated communications. Conversely, it also means a rejection 
can be turned into an acceptance with the issuing of a proper timestamp.

So with a reduced granularity, a concern may be that you can zoom in 
(i.e. binary search) faster at the acceptable date.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 28 Dec 2013 09:38:11 -0800

On Sat, Dec 28, 2013 at 6:22 AM, Eric Burger <[email-masked]>wrote:

> Would it not make sense to say that time is on the granularity of day or
> even week?
>
>
You could, or you as the receiver could simply make your decision based on
the date and discard the time-of-day precision.  However...

> I doubt time of day would be important.
>

...it is.

-MSK