Re: security features.... (Re: Facts, please)

[Tony Finch]

On Tue, 19 Sep 2006, Harald Alvestrand wrote:
>
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure against quite a
> few attacks, and widely deployed.

But mostly ignored, because the user interface is dreadful. Practically
all websites use one of the ad-hoc mechanisms that Russ referred to.

> The requirements needed to be "satisfactory" depend very much on your
> viewpoint; last week I talked to the guy who implemented Freenigma (PGP for
> web mailers, http://www.freenigma.com), and he commented that "this will never
> get past the security gurus in the IETF because it's so simple, people might
> actually use it".
>
> That says something frightening about the kind of impression we give to people
> who work on making usable security. "Usable" needs to be an important
> component of "satisfactory".
>
> (He's quite aware of the obvious security defects of his scheme, btw. It's a
> tradeoff.)

http://www.links.org/?p=130

Over the last year we've moved all our email users over to secure
authentication (with TLS and SASL, or the old passowrd authentication
alternatives) and the main usability problem is not the protocols as
specified. The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with terrible user
interfaces bristling with options.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Robert Sayre]

On 9/19/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote:

Robert Sayre wrote:
>
> I don't disagree. The IETF might first try to design an authentication
> feature worth requiring. None of the current options are at all
> satisfactory.

In fact TLS + HTTP Basic Auth is pretty interoperable, secure against
quite a few attacks, and widely deployed.


Ah, this is the "wink, wink" approach to mandatory authentication.
Specify something no one uses. Here is my bank's web site:
. It looks like a phishing attack.



That says something frightening about the kind of impression we give to
people who work on making usable security. "Usable" needs to be an
important component of "satisfactory".

(He's quite aware of the obvious security defects of his scheme, btw.
It's a tradeoff.)


Fully agree. Many non-standard schemes are more secure and more usable
than the IETF options, though.

Tony Finch wrote:

The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with terrible user
interfaces bristling with options.


Negotiation features don't work very well in practice so client
vendors don't rely on them.

--

Robert Sayre

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: security features.... (Re: Facts, please)

[Hallam-Baker, Phillip]

> From: Harald Alvestrand [mailto:[EMAIL PROTECTED] 
> > I don't disagree. The IETF might first try to design an 
> authentication 
> > feature worth requiring. None of the current options are at all 
> > satisfactory.
> 
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure 
> against quite a few attacks, and widely deployed.
> 
> The requirements needed to be "satisfactory" depend very much 
> on your viewpoint; last week I talked to the guy who 
> implemented Freenigma (PGP for web mailers, 
> http://www.freenigma.com), and he commented that "this will 
> never get past the security gurus in the IETF because it's so 
> simple, people might actually use it".
> 
> That says something frightening about the kind of impression 
> we give to people who work on making usable security. 
> "Usable" needs to be an important component of "satisfactory".

I think the question starts with a false premise, that the security layer 
should be in HTTP. Since HTTP is the new IP this makes no more sense than 
having authentication at the IPSEC layer.

The place for the authentication layer is actually HTML and that is out of 
scope. Moreover there has to be deep level support in the O/S if the 
authentication layer is going to be robust.

If we take the traditional IETF view of security perfectionism then the only 
answer on the table is the WS-* based identity metasystem, CardSpace, Higgins 
etc running on top of trustworthy hardware.

If we take a more pragmatic view (I hope we do) then we accept that we have to 
have something else on tap that we can use now, OpenID has a lot to offer. 

Regardless of which view we take it is clear that it would be most beneficial 
if the two approaches were to meet in the middle. Starting the tunnel at both 
ends at once only save time if the two tunnels actually meet up.


>From a security point of view it is clear to me that neither approach has any 
>bearing on HTTP. Or rather to the extend that it does the bearing is minimal. 
>So I don't see any real purpose in delaying the advance of HTTP to full 
>standard.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Harald Alvestrand]

Hallam-Baker, Phillip wrote:

I think the question starts with a false premise, that the security layer 
should be in HTTP. Since HTTP is the new IP this makes no more sense than 
having authentication at the IPSEC layer.
  
I think the concept of  "THE security layer" is a false premise. There's 
no shortage of FPs

The place for the authentication layer is actually HTML and that is out of 
scope.
Actually I think Secure HTML (RFC 2659) died for lack of interest, not 
because it was out of scope

 Moreover there has to be deep level support in the O/S if the authentication 
layer is going to be robust.

If we take the traditional IETF view of security perfectionism then the only 
answer on the table is the WS-* based identity metasystem, CardSpace, Higgins 
etc running on top of trustworthy hardware.

If we take a more pragmatic view (I hope we do) then we accept that we have to have something else on tap that we can use now, OpenID has a lot to offer. 


Regardless of which view we take it is clear that it would be most beneficial 
if the two approaches were to meet in the middle. Starting the tunnel at both 
ends at once only save time if the two tunnels actually meet up.


From a security point of view it is clear to me that neither approach has any 
bearing on HTTP. Or rather to the extend that it does the bearing is minimal. 
So I don't see any real purpose in delaying the advance of HTTP to full 
standard.
  
I think the inevitable dread of the inevitably interminable discussion 
of details of indetectable significance among the people who would have 
to carry it forward has more to do with its non-advancement than the 
missing usable security option




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Jeffrey Altman]

Robert Sayre wrote:
> On 9/19/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote:
>> Robert Sayre wrote:
>> >
>> > I don't disagree. The IETF might first try to design an authentication
>> > feature worth requiring. None of the current options are at all
>> > satisfactory.
>>
>> In fact TLS + HTTP Basic Auth is pretty interoperable, secure against
>> quite a few attacks, and widely deployed.
> 
> Ah, this is the "wink, wink" approach to mandatory authentication.
> Specify something no one uses. Here is my bank's web site:
> . It looks like a phishing attack.

If you try https://www.chase.com it redirects you to
http://www.chase.com.  How lame.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: security features.... (Re: Facts, please)

[Gray, Eric]

Harald,

The below is an easy mis-construction to make - from discussion
within the IETF, involving security experts. 

What I believe I've actually seen is along the lines of "we don't
want  because it is likely to be
mis-represented as having resolved security issues it has already been
determined it does not resolve."  One case where this has come up, is
in discussions of the use of TCP/MD5 - where the problem is not so much
that anyone "mis-represents" it as almost anybody can use it with little
- or no - work to be done.

There's certainly a degree of legitimacy in the concerns about 
possible misrepresentation.  If it's "for free" - then it is really
tempting to try to represent it as adequate (unless you're selling a
product that does something better).

From that, it is not hard to see how someone might get the idea
that "ease of use" might be a "problem" with a security/authentication
mechanism.  It's certainly easy to see how this would be doubly true in
any "easy to use" solution someone might wish to propose that is already
known to be less than perfect...

--
Eric

--- [SNIP] ---
--> The requirements needed to be "satisfactory" depend very much on your 
--> viewpoint; last week I talked to the guy who implemented Freenigma
--> (PGP for web mailers, http://www.freenigma.com), and he commented that 
--> "this will never get past the security gurus in the IETF because it's 
--> so simple, people might actually use it".
--> 
--> That says something frightening about the kind of impression we give 
--> to people who work on making usable security. "Usable" needs to be an 
--> important component of "satisfactory".
--> 
--> (He's quite aware of the obvious security defects of his scheme, btw. 
--> It's a tradeoff.)
--> 
-->Harald
--- [SNIP] ---

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Dave Cridland]

On Tue Sep 19 18:50:41 2006, Robert Sayre wrote:

Tony Finch wrote:

The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with 
terrible user

interfaces bristling with options.


Negotiation features don't work very well in practice so client
vendors don't rely on them.


They work just fine in email, which is where Tony is complaining 
about their lack of use.


It's entirely possible to discover TLS support and authentication 
methods, and automatically select the strongest combination, with 
minimal user interaction. I have yet to find any email server (IMAP, 
ESMTP, ACAP, etc) for which the negotiation in-built into the 
protocol fails to the extent that the negotiated features are not in 
fact supported.


Twice, I have seen the negotiated features fail, but only twice, both 
times asa result of bugs in the server, and nothing to do with the 
design of the protocols as such. Both cases are vanishingly rare, and 
one was in unreleased software, so I'm less than convinced that they 
represent an argument that this negotiation does not work very well 
in practise.


Unfortunately, this does not leave many possible explanations for why 
many client implementors make this much more complicated for the user 
than it needs to be.


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Sam Hartman]

> "Hallam-Baker," == Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:

>> From: Harald Alvestrand [mailto:[EMAIL PROTECTED] > I don't
>> disagree. The IETF might first try to design an authentication
>> > feature worth requiring. None of the current options are at
>> all > satisfactory.
>> 
>> In fact TLS + HTTP Basic Auth is pretty interoperable, secure
>> against quite a few attacks, and widely deployed.
>> 
>> The requirements needed to be "satisfactory" depend very much
>> on your viewpoint; last week I talked to the guy who
>> implemented Freenigma (PGP for web mailers,
>> http://www.freenigma.com), and he commented that "this will
>> never get past the security gurus in the IETF because it's so
>> simple, people might actually use it".
>> 
>> That says something frightening about the kind of impression we
>> give to people who work on making usable security.  "Usable"
>> needs to be an important component of "satisfactory".

Hallam-Baker,> I think the question starts with a false premise,
Hallam-Baker,> that the security layer should be in HTTP. Since
Hallam-Baker,> HTTP is the new IP this makes no more sense than
Hallam-Baker,> having authentication at the IPSEC layer.

For what it's worth, I think there need to be components both at the HTTP and 
HTML layers.

You want the binding to TLS at the HTTP layer for a number of reasons
including support for DAV, ATOM and other situations where there is no
HTML.  It's also easier to bind across one layer than two.  Finally,
HTML limits you to one round trip.  Sometimes that's undesirable.


However, I think you want the UI, and in the HTML case the
specification of what authentication mechanisms to use to be done in
HTML.

--Sam


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Russ Allbery]

Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:

> I think the question starts with a false premise, that the security
> layer should be in HTTP. Since HTTP is the new IP this makes no more
> sense than having authentication at the IPSEC layer.

> The place for the authentication layer is actually HTML and that is out
> of scope. Moreover there has to be deep level support in the O/S if the
> authentication layer is going to be robust.

There are reasons to provide security at multiple layers.  Security at the
HTTP layer is better if the purpose is to prevent unauthorized people from
retrieving resources via HTTP.  Security at the HTML layer is better for
some applications where you want to authenticate the server content to the
browser and are trying to prevent phishing.

You may scoff at doing security at the HTTP layer, and yet nearly everyone
who maintains HTTP content that requires authentication does exactly that,
usually by putting more weight on cookies than they were really designed
to bear and sometimes by (ab)using other HTTP headers (cf Negotiate-Auth).
The small handful of exceptions mostly instead do authentication at the
SSL layer (and face significant UI challenges in doing so, unfortunately,
which mostly rule out those solutions except within fairly controlled
communities).

> If we take the traditional IETF view of security perfectionism then the
> only answer on the table is the WS-* based identity metasystem,
> CardSpace, Higgins etc running on top of trustworthy hardware.

I think this is a little silly.  There are much less complex security
solutions that would meet the IETF criteria simply by enabling one to use
SASL or GSS-API for authentication, as can be seen in many other
applications.

HTTP poses special challenges because it's semi-stateless and because it's
in some respects fundamentally split between two symbiotic protocols (HTTP
and TLS) in a more fundamental way that for Internet protocols where TLS
is optional and strong authentication can be achieved without TLS, but
most of the challenges really stem from the fact that it's extremely
widely used, extremely widely deployed, and a very tempting target for
attack.

> From a security point of view it is clear to me that neither approach
> has any bearing on HTTP. Or rather to the extend that it does the
> bearing is minimal. So I don't see any real purpose in delaying the
> advance of HTTP to full standard.

At this point, widespread deployment of HTTP without interoperable
security is water under the bridge, and I agree that it probably doesn't
make a lot of sense to block its advancement towards full standard because
of missed opportunities years ago.  It shares, in other respects, the
features of a full standard, such as extremely high resistance to change.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf