RE: Proposed answer to MWBP WG (ACTION-566)

Don't know the amount of traffic carried over satcom, not sure what else is appropriate or can be done. Could be just a note that it is understood as an issue.

Leaving sensitive data in clear text is a poor option, even if using a satcom link.
 
B




-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Wednesday, January 28, 2009 5:27 PM
To: Doyle, Bill
Cc: W3C WSC Internal
Subject: Re: Proposed answer to MWBP WG (ACTION-566)

Apologies if this is provocative, but what's the market share of  
mobile communications over satellites, as opposed to mobile  
communications over Wi-Fi or GSM or 3G?

I think it's pretty well understood that a best practices document  
puts forward practices that apply in a majority of cases.... ;-)
--
Thomas Roessler, W3C  <tlr@w3.org>







On 28 Jan 2009, at 23:22, Doyle, Bill wrote:

> Mobile communication using satellites as a backbone can have issues  
> using TLS/SSL.
>
> TLS/SSL sessions require a number of handshakes to set up. Satcom  
> communication as a network can introduce significant delays to set  
> up a tls/ssl session. Each TLS/SSL handshake has quite a bit of  
> distance to cover, as I understand latency can be close to 250  
> milliseconds per handshake, I am tracking down real numbers.
>
>
> Bill D.
>
>
>
>
>
> -----Original Message-----
> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org 
> ] On Behalf Of Thomas Roessler
> Sent: Wednesday, January 28, 2009 12:31 PM
> To: W3C WSC Internal
> Subject: Proposed answer to MWBP WG (ACTION-566)
>
>
> Here we go... Comments by EOB next Tuesday?
>
>> Hi,
>>
>> thanks for your request for advice with respect to the proposed best
>> practices on the use of HTTPS.  The Web Security Context Working
>> Group has considered the proposed best practice on a recent
>> conference call.
>>
>> The short version of the advice is "don't do this, it's a bad
>> practice."
>>
>> The longer version:  We believe that you mean to recommend token-
>> based authentication schemes (where only an initial login
>> transaction is done through HTTPS, but most interactions are through
>> plain HTTP, with an appropriate token transmitted as a cookie or in
>> some HTTP header) similar to the ones currently in use at large web
>> properties.  While there may be situations in which the use of such
>> schemes is justified as the result of a complex trade-off, we oppose
>> a best practice recommending this approach.  There are several
>> reasons for this advice:
>>
>> 1. Use of HTTP in such schemes often leaves the asset that should
>> really be protected out in the open:  E.g., a webmail service
>> implemented according to this advice might permit an attacker full
>> access to the victim's inbox.
>>
>> 2. When using TLS, there is no reason to repeat the initial public
>> key handshake for every single HTTP request:  The resource-intensive
>> piece of the protocol occurs when the TLS handshake is first
>> executed (e.g., when accessing the login page); future HTTP requests
>> only require cheap symmetric key operations.
>>
>> 3. The practice described is particularly bad in the case of
>> applications targeted at mobile use:  Mobile devices are
>> increasingly used to access the Web through whatever Wireless LAN
>> might be available.  There is no reason to trust these networks;
>> indeed, there is hardly a situation with a higher exposure to
>> network attacks than an untrusted Wireless LAN environment.
>> Therefore, the Best Practices document should call out the overall
>> risk profile, and *encourage* use of TLS.
>>
>> 4. We note that your specification seems to aim at relatively
>> complex Web Applications, which implies a high likelihood that
>> powerful mobile devices will be used with these applications.  That
>> implies both an even higher likelihood for the use of W-LAN, and a
>> comparably low likelihood that resource constraints will indeed be
>> seriously affected by the use of TLS.
>>
>> On behalf of the Web Security Context WG,
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
>

Received on Thursday, 29 January 2009 13:53:04 UTC