On 03/25/2014 04:47 PM, Trevor Perrin wrote:
Please be cautious about suggesting user indications. UI is complicated and
>all that. More specifically in the browser case, even if you could strongly
>authenticate a connection over which you request ahttp:// page, I wouldn't
>want to give that page the https lock treatment. Note thathttps:// has
>different semantics (referer semantics, mixed content, etc).
Good points, thanks. Maybe adding other auth methods to HTTP-over-TLS
would be best done silently, with no UI unless a security failure
occurs?
Please be cautious about suggesting user indications. UI is complicated
and all that.
Let me put that another way: Off-the-cuff suggestions for what the
HTTP-over-TLS UI should look like, in the absence of (a) analysis and
(b) significant input from HTTP experts, will almost certainly be wrong.
For that matter, HTTP is a protocol, not an application or user
interface. A web browser is just one of many kinds of applications that
use HTTP, and many of those applications aren't even interactive. For
this reason also, generalizations about what the HTTP-over-TLS UI should
look like will also almost certainly be wrong. Different applications
using HTTP-over-TLS will need different ways of handling success or
failure to negotiate AE.
For the specific case of web browsers: I seriously doubt that adding
other auth methods to web browsers using HTTP-over-TLS should be done
silently, as then there would be no incentive for sites to provide the
additional authentication information.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
