Re: [Uta] Treating Javascript developers like they are stupid.

My interpretation of this case is that there is a major difference today in "treating" native vs. Javascript application developers due to the existing web security model, with websockets and webrtc leading the pressure for change.

This could have been a topical paper for STRINT (where IETF and W3C experts will meet), unless it is already there.

If not, I don't see any harm of writing and submitting a draft (to UTA) with specific suggestions for changes in the error codes being delivered (through APIs) to web applications using TLS. Time permitting, we may have the right people in and/or outside the room to bounce ideas off each other. Most helpful would be to have a list of allowed codes with justification for each  including an explanation for why it wouldn't lead to additional vulnerabilities already existing using other "techniques".

Orit.

> -----Original Message-----
> From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Yaron Sheffer
> Sent: Sunday, February 02, 2014 4:37 AM
> To: Alyssa Rowan; uta@ietf.org
> Subject: Re: [Uta] Treating Javascript developers like they are stupid.
> 
> Hi Alyssa,
> 
> Yes, there's a trade-off here but I agree with Olle that there's a lot
> of value in exposing TLS behavior and errors to the app layer. Besides,
> malicious apps can use timing information as a (less informative)
> oracle, e.g. to distinguish between a non-existent host, a failed TCP
> and connection a failed TLS handshake.
> 
> And it is more than just errors. Some things I would like to see in the
> interface are:
> 
> - Errors, including TLS alerts.
> - The ability to know what identity the server is claiming, so as to
> make policy decisions.
> - The ability to control TLS policy, such as what protocol version is
> being negotiated (so that the app can avoid SSLv3 even if the browser is
> misconfigured).
> - An app should be able to extract channel binding data from TLS, to
> facilitate crypto-binding of the app messages with the transport channel.
> - Control of credentials being used for client authentication: client
> certs, symmetric keys used with TLS-PSK, passwords used with TLS-SRP and
> similar. For symmetric keys and passwords, credentials should be pulled
> from a browser-specific "password manager", so the app should never see
> them.
> 
> Thanks,
> 	Yaron
> 
> 
> On 02/01/2014 03:34 PM, Alyssa Rowan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 31/01/2014 11:24, Olle E. Johansson wrote:
> >> Caused by a discussion about web sockets I've looked into
> >> Javascript a bit. In the web sockets specification they state
> >> clearly that ALL errors - dns, network errors, TLS - is just a
> >> connection error. The developer should not know, and it is stated a
> >> security risk if he gets the information about why a connection
> >> failed. It's all up to the browser.
> >
> >>  From the specification at http://dev.w3.org/html5/websockets/:
> >> ========================
> >>> Allowing a script to distinguish these cases would allow a script
> >>> to probe the user's local network in preparation for an attack.
> >
> > I think it's not treating JavaScript developers like they're stupid,
> > so much as (correctly) treating them like they're possibly malicious.
> > This is a defensive, but sensible and correct approach in practice,
> > given the most common use case by far: running code from random
> > websites which users visit, many of which are not even protected en
> > route by TLS, and many of which transclude IFRAMEs from ad networks
> > and heaven knows where else, too.
> > [...]
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta