Subject: Review of draft-hartman-webauth-phishing-05

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Aug 2007 10:17:23 -0700

I'm just digging out of my backlog and I got to this draft. Pleae
consider these last Last Call comments.

-Ekr

$Id: draft-hartman-webauth-phishing-05-rev.txt,v 1.1 2007/08/17 17:20:20 ekr Exp $

GENERAL
I think this draft is premature. There's a very large and growing
academic literature on phishing resistant authentication systems
and I don't think the data definitively supports any single
approach. Givn that, it seems to me that it's too early for
the IETF to be publishing anything claiming to be "requirements"
for phishing resistant authentication, especially if the intent
is to hold future efforts to this standard. If the IESG chooses
to publish this, it should be marked with a clear disclaimer
that this is an individual's opinion and not a stake in the
ground by the IETF.

I'm disappointed by the sparseness of the bibliography. As I
said, there's a large literature on this topic and this draft
cites essentially none of it. At minimum it would be appropriate
to cite:

  [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, "A Convenient
  Method for Securely Managing Passwords", In Proceedings of the 14th
  International World Wide Web Conference (WWW 2005)
  
  [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell
  Stronger Password Authentication Using Browser Extensions.
  Proceedings of the 14th Usenix Security Symposium, 2005.
   
  [2] Stuart Schechter, Rachna Dhamija, Andy Ozment and Ian Fischer,
  "The Emperor's New Security Indicators", Proceedings of the IEEE
  Symposium on Security and Privacy, May 2007.
  
  [3] "Rachna Dhamija, J. D. Tygar and Marti Hearst", Why Phishing Works, in
  the Proceedings of the Conference on Human Factors in Computing
  Systems (CHI2006), 2006.
  
But really this just scratches the surface.

It's possible that this is just an editorial choice, but when I read
this document I came away with the impression that it ignored large
parts of the existing literature--as opposed to just not citing it.
In particular, I don't see how one can discuss strong password 
equivalence in cleartext password systems without discussing
PwdHash, etc. This leaves the impression that the author has
pre-decided on what set of approaches are good, which, as I said,
is premature. It's particularly surprising that this document
focuses attention on ZKPP/PAKE systems and yet utterly neglects
TLS-PSK.

There seems to be a general failure in this document to distinguish
between the interface provided by passwords and protocols that use
passwords.  For instance, basic auth, PwdHash, digest, SRP, and
password-derived public keys all could be made to have very similar
user experiences, yet the underlying protocol technology is
fundamentally very different. The entire draft needs a scrub
for this.

DETAILED COMMENTS

S 1.
   TLS implementations typically confirm
   that the name entered by the user in the URL corresponds to the
   certificate as described in [RFC2818].

- The TLS stack doesn't do this. The HTTPS implementation does.
- It's not just the "name entered by the user". It's the link
  being dereferenced, no matter how entered.

   information.  Domain names that look like target websites, links in

s/like target/like those of/
 
The domain names don't look like the web sites themselves.

S 3.1.
   We assume attackers can convince the user to go to a website of their
   choosing.  Since the attacker controls the web site and since the
   user chose to go to the website the TLS certificate will verify and
   the website will appear to be secure.  The certificate will typically
   not be issued to the entity the user thinks they are communicating
   with, but as discussed above, the user will not notice this.

It's really important to emphasize that this is a production versus
verification issue. If you simply never go to URLs in emails, you
will in general not get phished because your intent is captured
by whatever URL you've bookmarked, typed in, etc. The way you
get phished is when you allow someone else to produce a URL that
is claimed to match some real-world identity.

Why is this important:
1. It suggests that another form of user education might work.
2. Once you realize that this is an issue of getting the user
to check for the presence of given indicia, it becomes questionable
whether *any* approach will work (see [2]).

So, I'm not convinced this is a correct threat model.

   The attacker can convincingly replicate any part of the UI of the
   website being spoofed.  The attacker can also spoof trust markers
   such as the security lock, URL bar and other parts of the browser UI.
   There is one limitation to the attacker's ability to replicate UI.
   The attacker cannot replicate a UI that depends on information the
   attacker does not know.  For example, an attacker could generally
   replicate the UI of a banking site's login page.  However the
   attacker probably could not replicate the account summary page until
   the attacker learned the user name and password because the attacker
   would not know what accounts to list or approximate balances that
   will look convincing to a user.  Of course attackers may know some
   personal information about a user.  Websites that want to rely on
   attackers not knowing certain information need to maintain the
   privacy of that information.

I'm not sure what this is supposed to be claiming, but it seems to
me to be either trivial or wrong.

The trivial interpretation is that the attacker can take a picture of
the intended UI and display it on the screen. This is obviously true,
but whether that's convincing is less clear: for instance, browsers
could ALWAYS frame every site-produced window, thus allowing the
user to distinguish the browser UI from site produced data. Whether
that's convincing or not is an empirical question of course, but
given the data on the types of scheme this draft proposes, I think
that this statement is too strong.

The wrong version would be to say that the attacker can *cause* the
browser to display the wrong security indicia. This is not correct
as far as I know. Clearly the attacker can cause the browser to
display the "lock" icon, but he can only partly control the cert.
Again, whether this is "convincing" is an empirical question.

   The attacker can convince the user to do anything with the phishing
   site that they would do with the real target site.  As a consequence,
   when passwords are used, if we want to avoid the user giving the
   attacker their password, the web site must prove that it has an
   established authentic relationship with the user without requiring a
   static password to do so, and in a way that cannot be visually
   mimicked so as to trick a user. 

As I noted earlier, this confuses passwords the UI with passwords the
protocol. SRP uses passwords (heck, it's in the name!) but it's not
vulnerable to this attack.

S 4.1.

   A solution to these requirements MUST also support smart cards and
   other authentication solutions.  Some environments have security
   requirements that are strong enough that passwords simply are not a
   viable option. 

This seems premature. Moreover, it again confuses interface with
protocol. To take an example, SRP can be used perfectly well with
smartcards: you do the client-side computation on the smartcard.
Pretty much any password-based solution can be ported to smartcards
simply by placing the password on the card. Calling out smartcards
in particular is also way too specific.

S 4.2.

   There are three basic approaches to establishing a trusted UI.  The
   first is to use a dynamic UI based on a secret shared by the user and
   the local UI; the paper [ANTIPHISHING] recommends this approach.  A
   second approach is to provide a UI action that highlights trusted or
   non-trusted components in some way.  This could work similarly to the
   Expose feature in Apple's OS X where a keystroke visually
   distinguishes structural elements of the UI.  Of course such a
   mechanism would only be useful if users actually used it.

This seems to me to neglect a number of approaches:

1. The Ctrl-Alt-Delete approach which doesn't highlights non-trusted
and trusted components, but simply brings up an un-interceptable
dialog.

2. Chrome on every single component (forbid frameless windows).

I appreciate that (2) is out of style right now, but again, the
data that the approaches you suggest actually work better is 
minimal.

   Finally,
   the multi-level security community has extensive research in
   designing UIs to display classified, compartmentalized information.
   It is critical that these UIs be able to label information and that
   these labels not be spoofable.

This seems like a category error. The first two approaches are actual
things. This is just "there is research". Did that research actually
lead to any technology?

S 4.3.
   A critical requirement is that when a user authenticates to a
   website, the website MUST NOT receive a strong password equivalent
   [IABAUTH].  A strong password equivalent is anything that would allow
   a phisher to authenticate as a user with a different identity
   provider.

s/with a different identity provider/to a different relaying party/.

   Weak password equivalents (quantities that act as a
   password for a given service but cannot be reused with other services
   ) MAY only be sent when a new identity is being enrolled or a
   password is changed.  A weak password equivalent allows a party to
   authenticate to a given identity provider as the user.

Where does this come from? Seems wrong to me (see [1]). The key
is to make sure that the WPE goes to the right place.

   There are two implications of this requirement.  First, a strong
   cryptographic authentication protocol needs to be used instead of
   sending the password encrypted over TLS.

Only because of the unjustified second requirement on WPEs. I don't
see any security reason why PwdHash isn't fine here.

   The zero-knowledge class of
   password protocols such as those discussed in section 8 of the IAB
   authentication mechanisms document [IABAUTH] seem potentially useful
   in this case.  Note that mechanisms in this space tend to have
   significant deployment problems because of intellectual property
   issues.

I'm confused as to why you're citing mechanisms which the IETF has
in many cases declined to standardize when there are phishing-resistant
mechanisms that don't have that problem, i.e., conventional
challenge-response.

S 4.4.
   Authentication of the server and client at the TLS level is
   sufficient to meet the requirement of mutual authentication.  If
   authentication is based on a shared secret such as a password, then
   the authentication protocol MUST prove that the secret or a suitable
   verifier is known by both parties.  Interestingly the existence of a
   shared secret will provide better protection that the right server is
   being contacted than if public key credentials are used.  By their
   nature, public key credentials allow parties to be contacted without
   a prior security association. 

Again, this confuses interface with protocol. There are lots of ways
around this problem. For instance, you could use SSH l-o-f style
authentication and warn when a new public key is encountered from the
server.

   In protecting against phishing
   targeted at obtaining other confidential information, this may prove
   a liability.  However public key credentials provide strong
   protection against phishing targeted at obtaining authentication
   credentials because they are not vulnerable to dictionary attacks.

Well, maybe. One natural way to build a PK-based system based
on passwords (interface/protocol again) is to derive the PK from
the password. At which point you have a dictionary attack again.

   Such dictionary attacks are a significant weakness of shared secrets
   such as passwords intended to be remembered by humans.  For public
   key protocols, this requirement would mean that the server typically
   needs to sign an assertion of what identity it authenticated.

I don't understand this last point.

S 4.5.
   Users expect that whatever party they authenticate to will be the
   party that generates the content they see.  One possible phishing
   attack is to insert the phisher between the user and the real site as
   a man-in-the-middle.  On today's websites, the phisher typically
   gains the user's user name and password.  Even if the other
   requirements of this specification are met, the phisher could gain
   access to the user's session on the target site.  This attack is of
   particular concern to the banking industry.  A man-in-the-middle may
   gain access to the session which may give the phisher confidential
   information or the ability to execute transactions on the user's
   behalf.

Well, maybe. Again, see PwdHash, which ties the WPE to the URI, hence
to the TLS cert.

   1.  Assuming that only certificates from trusted CAs are accepted and
       the user has not bypassed server certificate validation, it is
       sufficient to confirm that the identity of the server at the TLS
       level is the same at the HTTP authentication level.  In the case
       of TLS client authentication this is trivially true.

I don't understand this last claim.

S 4.6.
   important that the protocol enable this.  For such identities, the
   user MUST be assured that the target server is authorized by the
   identity provider to accept identities from that identity provider.
   Several mechanisms could be used to accomplish this:

I'm not convinced that just because some financial wants this it
suddenly becomes an IETF requirement. Doing any kind of multi-party
authentication is a lot more complicated than two party, so it's
way premature to be specifying requirements. This entire section
should be struck.

S 4.6.
   In Section 4.2, we discuss how a secret between the user and their
   local computer can be used to let the user know when a password will
   be handled securely.  A similar mechanism can be used to help the
   user once they are authenticated to the website.  The website can
   present information based on a secret shared between the user and
   website to convince the user that they have authenticated to the
   correct site.  This depends critically on the requirements of
   Section 4.5 to guarantee that the phisher cannot obtain the secret.
   It is tempting to use this form of trusted UI before authentication.
   For example, a website could request a user name and then display
   information based on a secret for that user before accepting a
   password.  The problem with this approach is that phishers can obtain
   this information, because it can be obtained without knowing the
   password.  However if the secret is displayed after authentication
   then phishers could not obtain the secret.  This is one of the many
   reasons why it is important to prevent phishing targeted at
   authentication credentials.

This only applies if the channel is encrypted or the attacker is 
off-path.

S 7.
ben Laurie -> Ben Laurie

Appendix A.
This is redundant.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Sat, 18 Aug 2007 07:25:14 +0200

Hi Eric,

I have one overall comment and one specific comment on your comments ;-)

The overall comment is that we need a starting point to improve HTTP.  
Sam's draft seems to me at least a stake in the ground from which to 
work with.  I'm all for the document being improved.  It would be 
helpful if you could suggest changes to the text to do that.  I realize 
that's a lot more work, but I think we really can put a huge dent in 
phishing, and we don't need to wait around for academia on this one.  
The IETF needs to address areas where protocols are currently unable to 
support secure authentication methods.

> in particular is also way too specific.

I think perhaps we have a terminology issue.  By password, I think Sam 
means those things people type into UIs.  By smartcards I think he means 
something that does it for you in some secure way not specific to the 
IEEE standard.  The major point that Sam is calling out, and he is doing 
so at my urging, is that we need to be able to support a solution where 
the authentication component is separate from the host operating system, 
yet having a secure communication channel from end to end.  This may 
need to be wordsmithed but that's the intent.

Thanks,

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Aug 2007 22:44:49 -0700

At Sat, 18 Aug 2007 07:25:14 +0200,
Eliot Lear wrote:
> work with.

Yeah, I don't think the world is improved by putting a stake in the
ground at a poorly chosen location [nor, for that matter, do I agree
that necessarily HTTP is the correct location for improvement.] And as
I argue in my review, we don't understand the ground well enough to
place it in a good location. 

> I'm all for the document being improved.  It would be 

I'm afraid I don't agree with either of these assertions, for the
reasons I indicated in my review.

> support secure authentication methods.

It's yet to be established that there is anything wrong with the
protocols at all. On the contrary, the current protocols appear
to me to be quite capable of doing most of what one would want
if coupled with the appropriate UI. And it's the UI issues that
are poorly understood.

> need to be wordsmithed but that's the intent.

Yes, and the point that I'm making is that this is a UI issue, which
is largely orthogonal to the protocol. In fact, with properly designed
protocols one side can be quite oblivious to where the peer's
credential is stored--though of course restrictions can be enforced
by restricting direct access to the keying material. And that's
the issue: this document repeatedly conflates UI and protocol.

As for the term "smartcard", if you don't mean ISO 7816/7810, then
you should choose some more generic term. I believe "token" is the
one currently in vogue.

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Aug 2007 13:12:51 -0400

Hi, Eric, responding as an individual.

Obviously, I disagree with your basic claim that it is too early to
write a document like this.  I've asked the sponsoring AD to make a
consensus call on whether we have sufficient support to be making this
sort of statement.  If not, then I'll be happy to take my document to
the rfc editor.  However I think it is completely pointless for us to
argue about that particular issues: we're not going to agree.

I disagree that the references need to be significantly expanded.  I
am familiar with the work you cited in your message.  If you would
like to propose specific text that improves the document and cites
those references I'd like to consider your specific text suggestions.

It seems you have read the document and think I favor ZKPP protocols.
It's certainly true that in a world without patents I think they would
be interesting to explore.  However I wanted to discuss them mostly
because I thought that the patent problem was important to turn out.

It's certainly true that I have thought about what solutions I'd like
to see.  I think the solutions will likely be in the challenge
response at the HTTP level or TLS-PSK space.

I think the primary concern will be what we can manage to get deployed
not protocol details.

I've tried not to expose that too much in the document; I understand we disagree.

I would like to make some changes based on your comments.

First, I would like to make a pass to improve the separation between
user interface and protocol.  I doubt I'll get to a level you'll be
happy with.

Second, I'd like to address your comment about WPE and enrollment.

Finally, I see no problem correcting areas where I was less precise
than you wished I had been.  Examples of this include conflating the
TLS and HTTPS layer in the introduction.

--Sam

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Aug 2007 10:42:05 -0700

On a thread about a specific document that is proposed to be an 
Informational RFC coming through the IETF process:

At 1:12 PM -0400 8/20/07, Sam Hartman wrote:
>I've asked the sponsoring AD to make a
>the rfc editor.

This is pointless. No one other than an expert at the IETF process 
could differentiate between the two types of Informational RFCs in 
RFC repository (and many IETF process experts would not get it right 
on the first try). An Informational RFC is an Informational RFC 
regardless of the path that got it published.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Aug 2007 11:01:58 -0700

Paul Hoffman wrote:
> This is pointless. No one other than an expert at the IETF process could 
> differentiate between the two types of Informational RFCs in RFC 
> repository (and many IETF process experts would not get it right on the 
> first try). An Informational RFC is an Informational RFC regardless of 
> the path that got it published.

RFC 2026, sec. 4.2.2 does not appear to designate two different types
of Informational RFCs.  Where is this specified in the standards process?

> --VPN Consortium

Andy

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Aug 2007 15:09:09 -0400

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> On a thread about a specific document that is proposed to be
    Paul> an Informational RFC coming through the IETF process:

    Paul> At 1:12 PM -0400 8/20/07, Sam Hartman wrote:
    >> I've asked the sponsoring AD to make a consensus call on
    >> whether we have sufficient support to be making this sort of
    >> statement.  If not, then I'll be happy to take my document to
    >> the rfc editor.

    Paul> This is pointless. No one other than an expert at the IETF
    Paul> process could differentiate between the two types of
    Paul> Informational RFCs in RFC repository (and many IETF process
    Paul> experts would not get it right on the first try). An
    Paul> Informational RFC is an Informational RFC regardless of the
    Paul> path that got it published.

The difference is the IESG note.  I respect your belief that many
people would not understand that difference.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Aug 2007 20:21:27 -0700

At Mon, 20 Aug 2007 15:09:09 -0400,
> people would not understand that difference.

Well, the difference is in part the IESG note. More importantly,
the question is whether the IESG intends to hold future work 
to the requirements in this document. If they do, then this 
document needs significantly more review and a much stronger
showing of consensus. Arguably, if they do it should be
required to be PS or BCP.

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 05:44:31 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Well, the difference is in part the IESG note. More
    Eric> importantly, the question is whether the IESG intends to
    Eric> hold future work to the requirements in this document. If
    Eric> they do, then this document needs significantly more review
    Eric> and a much stronger showing of consensus. Arguably, if they
    Eric> do it should be required to be PS or BCP.

Obviously as an individual, I disagree that it would be necessary for
significantly more review to take place.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Aug 2007 09:29:00 -0700

At Mon, 20 Aug 2007 13:12:51 -0400,
Sam Hartman wrote:
> write a document like this. 

Not quite. My claim is that the IETF should not be publishing
a document like this and then requiring that future work conform
to it. I don't have a problem to it being published as basically
a White Paper with a clear understanding that protocol proposals
will not be held to this standard. Hence my suggestion for
an IESG Note to formalize this understanding.

> am familiar with the work you cited in your message. 

Yes, but the purpose of the references section isn't for you, but for
consumers of the document. A document which does is neither 
an adequate guide to the state of the art (which this one is not)
nor contains pointers to the literature does not serve the community
well. More importantly, if you're going to impose *requirements*
on the community, they should be clearly informed by the existing
state of the art. The only way to do so is to actually discuss
that topic, not have the reader be forced to take on trust that
the literature supports the author's position. 

To give one concrete example, there is an emerging body of work (with
the Shechter paper I cited being the best-known example) a variant of
one of the techniques you specifically recommend in S 4.2 (a shared
secret between the UI and the user, though in this case it was a
shared secret with the bank with a similar UI metaphor) was shown 
to be of limited effectiveness. 

To give another example: two of the other papers I cited (HWF05 and
RJBMM05) describe UI-only mechanisms that provide for unique
per-server passwords and a special UI with no modification whatsoever
to the network protocol. I appreciate that you feel that other
approaches are more promising, but the fact that this document
but that doesn't mean that a document of this type should pretend
that they don't exist.

> If you would

To be blunt, this is your job, not mine. We're talking about major
rewriting, not a couple of paragraphs.

> It seems you have read the document and think I favor ZKPP protocols.

No, I think discussing only ZKPPs and not non-ZK challenge-response
protocols gives an incorrect impression of the state of play,
as does failing to discuss PwdHash style protocols. In the former
case, because it neglects an important alternative. In the latter
case, it actually excludes it due to the requirement for mutual
auth in S 4.4 (as well as not mentioning it.)

> because I thought that the patent problem was important to turn out.

Wait, your claim is that we should discuss options which are quite
possibly not viable due to IPR considerations and which in two cases
WGs have declined to standardize, but that it's not important to
discuss several proposed and in fact likely alternatives?  I'm finding
this a bit puzzling.

> I think the primary concern will be what we can manage to get
> deployed not protocol details.
> 

I have no idea what you're talking about here. 

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 13:05:59 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> At Mon, 20 Aug 2007 13:12:51 -0400,
    Eric> Sam Hartman wrote:
    >> Obviously, I disagree with your basic claim that it is too
    >> early to write a document like this.

    Eric> Not quite. My claim is that the IETF should not be
    Eric> publishing a document like this and then requiring that
    Eric> future work conform to it. I don't have a problem to it
    Eric> being published as basically a White Paper with a clear
    Eric> understanding that protocol proposals will not be held to
    Eric> this standard. Hence my suggestion for an IESG Note to
    Eric> formalize this understanding.

I don't think it would be appropriate to publish this document as a
BCP that future HTTP authentication work needs to be held to.  I do
hope that we have consensus these are good requirements, that it would
be desirable to work on solutions that meet these requirements and
that it would be a reasonable discussion to ask why particular work
did not plan to meet these requirements or whether these requirements
should be referenced in chartering work.  I suspect you are not part
of such a consensus if it exists.

    >> I disagree that the references need to be significantly
    >> expanded.  I am familiar with the work you cited in your
    >> message.

    Eric> Yes, but the purpose of the references section isn't for
    Eric> you, but for consumers of the document. A document which
    Eric> does is neither an adequate guide to the state of the art
    Eric> (which this one is not) nor contains pointers to the
    Eric> literature does not serve the community well. 

I disagree that it is a goal of this document to serve as a guide to
the state of the art nor is it necessary or desirable to contain
pointers to the literature in this space.  In general I've tried to
cite sufficient sources to make the requirements clear , not to
justify them.  I believe this practice is consistent with a lot of
IETF requirements documents.  Obviously I will take direction from the
proto shepherd or responsible AD if they believe I should be adopting
different goals for when sources need to be cited.

    Eric> More
    Eric> importantly, if you're going to impose *requirements* on the
    Eric> community, they should be clearly informed by the existing
    Eric> state of the art. The only way to do so is to actually
    Eric> discuss that topic, not have the reader be forced to take on
    Eric> trust that the literature supports the author's position.
I think we disagree in principle. However you mention a number of
cases where the document would be improved by specific citations.  I
appreciate that feedback and will work on including citations.

    Eric> To give one concrete example, there is an emerging body of
    Eric> work (with the Shechter paper I cited being the best-known
    Eric> example) a variant of one of the techniques you specifically
    Eric> recommend in S 4.2 (a shared secret between the UI and the
    Eric> user, though in this case it was a shared secret with the
    Eric> bank with a similar UI metaphor) was shown to be of limited
    Eric> effectiveness.
I will include discussion.

    Eric> To give another example: two of the other papers I cited
    Eric> (HWF05 and RJBMM05) describe UI-only mechanisms that provide
    Eric> for unique per-server passwords and a special UI with no
    Eric> modification whatsoever to the network protocol. I
    Eric> appreciate that you feel that other approaches are more
    Eric> promising, but the fact that this document but that doesn't
    Eric> mean that a document of this type should pretend that they
    Eric> don't exist.
I'll take a look at where such a discussion could fit in and see if it
makes sense.

    >> If you would like to propose specific text that improves the
    >> document and cites those references I'd like to consider your
    >> specific text suggestions.

    Eric> To be blunt, this is your job, not mine. We're talking about
    Eric> major rewriting, not a couple of paragraphs.

  We disagree about what the document should be trying to do.
If there were someone interested in doing the work necessary to make
the document cover the additional issues you'd like to see it cover, I
think it would be a good idea to at least consider whether that is
worth the delay.  Absent such a volunteer, I think the main question
before us is whether that work is necessary or whether we have a
consensus that the current scope is OK.

    >> It seems you have read the document and think I favor ZKPP

    Eric> No, I think discussing only ZKPPs and not non-ZK
    Eric> challenge-response protocols gives an incorrect impression
    Eric> of the state of play, as does failing to discuss PwdHash
    Eric> style protocols. In the former case, because it neglects an
    Eric> important alternative. In the latter case, it actually
    Eric> excludes it due to the requirement for mutual auth in S 4.4
    Eric> (as well as not mentioning it.)

    >> It's certainly true that in a world without patents I think
    >> they would be interesting to explore.  However I wanted to
    >> discuss them mostly because I thought that the patent problem
    >> was important to turn out.

    Eric> Wait, your claim is that we should discuss options which are
    Eric> quite possibly not viable due to IPR considerations and
    Eric> which in two cases WGs have declined to standardize, but
    Eric> that it's not important to discuss several proposed and in
    Eric> fact likely alternatives?  I'm finding this a bit puzzling.

Yes.  I think in a document like this it is more important to discuss
options that might appear promising but are in fact not than to
discuss options that are likely directions.  However I don't feel
particularly strongly about this.  If you think that the text about
ZKPPs would cause the reader to believe look in that direction I'd be
happy to work on it.

    >> I've tried not to expose that too much in the document; I

I've tried not to expose my thoughts about how this should be solved
in the document.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Aug 2007 12:39:04 -0700

At Tue, 21 Aug 2007 13:05:59 -0400,
> of such a consensus if it exists.

Again, I don't understand how you're claiming this document should be
used. Clearly, it would be reasonable for someone in the future to
argue that it was reasonable to work on solutions that met requirements
listed in arbitrary papers published in other venues, or to ask why
proposed work didn't meet those requirements. This is a reasonable
question to ask for any document, regardless of publication venue. 
On the other hand it would be reasonable to say "yeah, I haven't
read that document, but feel free to reiterate its arguments if you
think they apply." Is it your belief that if the IETF publishes this
document as Informational that it should have some status other than
this?

> IETF requirements documents. 

Yes, but in most cases, there is a historical record in the form
of the WG mailing list which justifies the requirements. That
situation does not apply here.

> appreciate that feedback and will work on including citations.

Not to put too fine a point on it, but these are examples, not an
exhaustive list. This is a systemic issue and it's not fixed just
by fixing these specific cases.

> I will include discussion.

I don't see how discussion helps.

This draft basically recommends a technique which may well not work.
That's fine if you're writing a white paper, but I don't see how it
can go in a requirements document, especially as controlling where
the user types their password is the heart of the problem

> I'll take a look at where such a discussion could fit in and see if it

It's more than just including discussion. As I indicated below,
your document actually prohibits this type of solution.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Aug 2007 15:58:50 -0700

At 1:05 PM -0400 8/21/07, Sam Hartman wrote:
>BCP that future HTTP authentication work needs to be held to.

That's good to hear. But...

>I do
>hope that we have consensus these are good requirements,

We absolutely do not have any such consensus. There was barely any 
discussion during IETF Last Call. There was not a mailing list for 
discussing the draft. Speaking for myself, I didn't comment because I 
thought it was meant to be an Informational RFC saying what Sam 
Thinks About These Requirements. The IETF Last Call announcement said 
*nothing* suggesting that this was a consensus call. There was also 
no call for consensus on either the Applications Area or Security 
Area mailing lists.

It is inappropriate to change the intended use of this document after 
IETF Last Call. Even if you use the term "consensus" loosely, it is 
also inappropriate to change the status of this document ("consensus 
is unknown" vs. "it has consensus") after the discussion, 
particularly given how little discussion there was.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 20:34:30 -0400

>> I do hope that we have consensus these are good requirements,

    Paul> We absolutely do not have any such consensus. There was
    Paul> barely any discussion during IETF Last Call. There was not a
    Paul> mailing list for discussing the draft. 

Hmm.  I actually think that as ad-sponsored informationals go this got
a lot of constructive discussion in ietf last call.  It was discussed
on the dix and http-auth lists and at the WAE BOF.  My perception of
the room at WAE was that with the exception of the requirement about
mutual authentication this was relatively non-controversial and that going forward with such a document would be useful.

Now, we may actually be saying the same thing.  I think this document
has received review similar to other IETF informational documents.
There's a lot of open question about what the status of such documents
is; absent evidence such as an IESG note I assume such documents have
rough consensus of the IETF.  Others may not read things that way or
may assume a different level of support behind informational documents
for which we do an IETF last call.

Ultimately though the issue of adequacy of review rests with Lisa and
the IESG.  I'm obviously recused from formal participation in that
process.

Paul> Speaking for myself,
    Paul> I didn't comment because I thought it was meant to be an
    Paul> Informational RFC saying what Sam Thinks About These
    Paul> Requirements. 

If I wanted to publish such a document I would have gone to the rfc editor.

    Paul> The IETF Last Call announcement said *nothing*
    Paul> suggesting that this was a consensus call. 
I thought all IETF last calls are consensus calls.

    Paul> It is inappropriate to change the intended use of this
    Paul> document after IETF Last Call. 

Here we agree.  I'm not asking for treatment any different than any
other AD-sponsored informational document.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Aug 2007 17:49:40 -0700

At Tue, 21 Aug 2007 20:34:30 -0400,
Sam Hartman wrote:
> a lot of constructive discussion in ietf last call.

Uh, where? I just looked through the IETF mailing list and the only
such discussion I see after the 5/23 IETF LC was (1) between you 
and Eliot and (2) the present discussion. I wouldn't exactly
characterize the present discussion as supporting a claim of
consensus.

> It was discussed on the dix and http-auth lists and at the WAE BOF.
> My perception of the room at WAE was that with the exception of the
> requirement about mutual authentication this was relatively
> non-controversial and that going forward with such a document would
> be useful.

I was not aware the BOFs were a standard venue for assessing
consensus for document advancement.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Aug 2007 22:03:46 -0700

Your view of the facts are quite at odds with the written record and, 
more importantly, with RFC 2026.

>a lot of constructive discussion in ietf last call.

Unless I am reading the official archive wrong, you had a few round 
trips with one person.

>It was discussed
>on the dix and http-auth lists and at the WAE BOF.

Unless I am reading the archive of those two mailing lists 
incorrectly, your draft has not been discussed there in over a year. 
According to the minutes of the WAE BoF a year ago, the draft as it 
stood at that time was indeed discussed, but the minutes do not say 
that there was IETF consensus even then.

>My perception of
>mutual authentication this was relatively non-controversial and that 
>going forward with such a document would be useful.

That is my interpretation of the minutes as well. And that is 
irrelevant to saying that there is IETF consensus for the document, 
given that you have made many changes to the draft in the past year. 
Also, recently you have found that agreement in the room at a BoF was 
insufficient reason to move forwards with work,

>Now, we may actually be saying the same thing.

I'm quite sure we are not.

>I think this document

We disagree here, at least for all the mailing list traffic that I 
have seen for your document.

>is;

OK, we agree here. :-)

>absent evidence such as an IESG note I assume such documents have
>rough consensus of the IETF.

...but not here.  RFC 2026 says:
    An "Informational" specification is published for the general
    information of the Internet community, and does not represent an
    Internet community consensus or recommendation.
I do not read that as meaning that the IESG needs to put a note in 
every RFC for which that statement will be true.

>Others may not read things that way or

<hand raises>

>the IESG. I'm obviously recused from formal participation in that

If the document is meant to convey IETF consensus, and can be used to 
block later protocol proposals, the level of review is not nearly as 
important as the document status. You seem to be describing a BCP.

>If I wanted to publish such a document I would have gone to the rfc editor.

That's fine, but those of us who might have reviewed the document had 
no indication that you thought that way (nor that you thought that 
this document, with the scant discussion, had the weight of IETF 
consensus.

>I thought all IETF last calls are consensus calls.

RFC 2026 is pretty clear on this:
    An "Informational" specification is published for the general
    information of the Internet community, and does not represent an
    Internet community consensus or recommendation.

>other AD-sponsored informational document.

Here we disagree. Your statements in the past few messages were 
asking for a status (IETF consensus) that is not granted to other 
Informational RFCs, and were saying that such status allows blockage 
of future documents until a review was done against this one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Aug 2007 22:23:59 -0700

> I thought all IETF last calls are consensus calls.

That's not what RFC2026 says.

It's not clear why we bother documenting things carefully when we wind up 
inventing interpretations at will.

And the 'we' means a whole lot more than you or me or this particular topic.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Aug 2007 07:47:08 -0400

Ah.  I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct.  I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations) in my head because honestly I cannot find any other
way to think about it that makes any sense to me.  I certainly view an
informational docmuent that has gone through an ietf last call as a
statement from the IETF.  We'll add this to one of the many areas
where I completely fail to get RFC 2026.

I definitely don't want to block other work with this document.  I
think that to be particularly useful I'd like to get to a point where
we can say that having authentication schemes that meet these
requirements would be useful and that for some value of we
significantly greater than me, we think that would be a useful step
along the road to combatting phishing.  I thought I was trying to have
that discussion here; you at least seem to think that is not the case.
At some future point we might charter work with the goal of doing
something similar to those requirements; in such a case, we might
decide to hold that work to these requirements.  We're not discussing
doing that today.

If I believe there is a reasonable chance of success I'm willing to
put in significant effort towards achieving my goal.  Absent that
belief I'm more interested in getting something out and working on
running code.

So, Here is a proposed IESG note that I think is consistent with my
intent and RFC 2026:

This document proposes requirements for HTTP authentication that are
intended to help combat the problem of phishing.  These requirements
attempt to reduce the consequences of a user being tricked into using
a server provided by an attacker instead of the server they intended
to trust.  These requirements have no normative force; publication of
these requirements does not bind future work to follow them.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Aug 2007 09:10:20 -0400

Part of the problem may be historical: Requirement documents are a  
relatively recent phenomena and likely postdate 2026. I suspect the  
original intent of informational documents was to document non-IETF  
protocols for the benefit of implementors, as well as record various  
other non-standards items such as April 1 poetry or workshop results,  
where it is pretty clear that this is the opinion of the author or  
some definable group, such as the IAB.

On the other hand, I have yet to see working group-issued  
requirements documents being used for anything except shadow boxing  
(and, occasionally, recording some early WG thinking), so maybe we  
shouldn't take them too seriously.

Rather than an IESG note or in addition to, I think the author should  
clearly state, in the abstract, that this is a personal opinion only.

Henning

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 22 Aug 2007 15:29:34 +0200

Hi Henning, 

many of these document are turned into a religious thing and then every time you suggest something your solution is compared against some of these documents. As document author you are often not excited about this approach. 

Examples: 
* RFC 3693 (Geopriv Requirements)
* EAP Keying Framework 
* RFC 4962 containing the Housley criteria

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 22 Aug 2007 09:10:20 -0400
> Von: Henning Schulzrinne <[email-masked]>
> An: IETF discussion list <[email-masked]>
> CC: IESG <[email-masked]>
> Betreff: Re: Review of draft-hartman-webauth-phishing-05

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Aug 2007 17:16:15 +0300

Hannes -- for the record EAP Keying Framework is destined
to become a Proposed Standard. It was also developed by a
consensus process in the WG, and extensively discussed
(perhaps even for too long). Not sure its a good example to
use in this discussion. I do agree with your point otherwise,
though.

Jari

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Aug 2007 10:40:07 -0400

>>>>> "Henning" == Henning Schulzrinne <[email-masked]> writes:

    Henning> Rather than an IESG note or in addition to, I think the
    Henning> author should clearly state, in the abstract, that this
    Henning> is a personal opinion only.

I don't think my personal opinion would make a very useful document,
but if that's all we can come away from this process with then that's
all we will achieve.

First, I'd rather try and build consensus and get more review.

Failing that, I think we could come up with a way of describing the
status of this document that does not give the impression that it has
even less review than other documents that are of the same status.
I.E. I think it would be an unfortunate outcome if we feel the need to
add a bunch of warnings in this case simply because we've had a
discussion and realized that we don't entirely agree on what our
documents mean.

I think making it clear that this is not normative is quite important.

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Aug 2007 12:18:52 -0400

--On Wednesday, 22 August, 2007 10:40 -0400 Sam Hartman
<[email-masked]> wrote:

>     Henning> Rather than an IESG note or in addition to, I
> think the     Henning> author should clearly state, in the
> abstract, that this     Henning> is a personal opinion only.
> 
> I don't think my personal opinion would make a very useful
> document, but if that's all we can come away from this process
> with then that's all we will achieve.
> 
> 
> Failing that, I think we could come up with a way of
> describing the status of this document that does not give the
> impression that it has even less review than other documents
> that are of the same status. I.E. I think it would be an
> unfortunate outcome if we feel the need to add a bunch of
> warnings in this case simply because we've had a discussion
> and realized that we don't entirely agree on what our
> documents mean.

Sam,

It is the question of how to accurately reflect the amount of
review and/or agreement that has caused me to be so concerned
about the apparently-rigid language in RFC 3932 and
interpretations of that language that make it even more rigid.

Some informational documents are better reviewed than others.
Some represent consensus about the right things to do, others
don't.  Some of those that do not represent a consensus about
what to do still represent consensus that the document a
reasonable and comprehensive description of a situation and
possibly the range of known solutions.   Any of these may be
useful (or not).   Which category a document falls into is
largely independent of whether a document goes through the IESG
track or the RFC Editor one.

IMO, the thing we need to be careful about is assertions about
IETF consensus or IETF review: If such consensus exists and has
been formally verified, or such a review actually took place and
was meaningful, it is reasonable to say that.  But the absence
of formal review or verification doesn't imply "bad" or
"dangerous" or "incompetent", it just implies that one
particular review and approval process didn't take place.

Maybe, instead of having arguments about consensus,
recommendations, and whether or not things are going to be taken
to be normative, it is time we permit --and perhaps require--
authors of Informational documents to insert a statement that
accurately describes one or both of (i) levels of review and
consensus and (ii) intended use.  It would then be a key element
of whatever review process is used to verify that such
statements are accurate.

Taking this document as an example, it would seem reasonable to
me to say "This has been discussed around the IETF and
elsewhere.  While some people agree with it, others do not and
some of the others believe it is premature with regard to both
the developing state of the art and it literature review and
citations.  It is the intention of the author that the document
be used to inform the ongoing debate and discussion, not that it
be considered normative or a constraint on future work in the
IETF or in other forums".  

If I am correct that a statement of that type accurately
represents your view and that of others who support the content
of the document, EKR's view, and reality, we would then be
finished.
 
> I think making it clear that this is not normative is quite

Obviously.  But it is only part of the problem and solution, IMO.

    john

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2007 12:04:35 -0700

Henning Schulzrinne wrote:
> On the other hand, I have yet to see working group-issued requirements 
> documents being used for anything except shadow boxing (and, 
> occasionally, recording some early WG thinking), so maybe we shouldn't 
> take them too seriously.
I have a less jaded view of requirement documents than Henning, but I
suppose I should since I've written a couple. They can certainly function
as Henning says, but for the last one I took on writing, the situation was
pretty dire: endless email threads, people talking past each other, complete
non-clarity on what the end goals -- and challenges -- really were, etc, 
etc.
If you add on top of that egos attached to concrete drafts which are often
not at all apparent what problems _they're_ trying to solve, it makes it
nearly impossible to even know what people even disagree on, let alone
agree on.

For that kind of situation, biting the bullet seems like a sensible way 
forward.
It's a pretty thankless job in many ways though in those situations: wading
through endless threads trying to make some sense of the cacophony is not
much fun. Yet it did settle things down to a great extent, even if it 
was mainly
from sheer exhaustion.

       Mike

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Aug 2007 15:12:48 -0400

Henning,

Some WGs issue Informational RFCs that represent WG consensus, but 
which are not viewed as suitable Standards track documents, for 
various reasons.  For example, RFC 3647 is one of the most widely 
cited of the PKIX RFCs, yet it is Informational because its a policy 
and procedures document, not a protocol document. Some WGs also 
choose to publish a requirements spec as Informaitonal, even thought 
the document that will meet the requirements will itself be standards 
track.

So I think we have a wide variety of document types that wind up as 
informational RFCs, even today.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2007 12:53:04 -0700

> these requirements does not bind future work to follow them.

Sam, I guess the question I have is why an individual submission is actually
the right vehicle for this sort of document. From the outside -- though 
pretty
interested in the phishing problem -- I'd think that a more community 
consensus
type of document with more teeth (ie, some normative force) would be a
Good Thing if consensus could be found. I read quite a few of these 
comments
as being more of the nature that there wasn't a very good forum to shape the
content. I can sympathize with the notion that comments on IETF list during
last call for a document as important and likely controversial is 
insufficient.
This list is noisy enough after all.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Aug 2007 14:21:32 -0700

>First, I'd rather try and build consensus and get more review.

This would be excellent. You, or Lisa as sponsoring AD, can ask the 
IESG to stop the review and pull back. You could publicize the 
mailing list on which this would be discussed (ietf-web-auth, not 
dix, I hope). Discussion could be had (and had and had...). At the 
end, the document could be a real-live BCP with community consensus.

That means more work by more people, but the likely outcome would be 
one or more protocols with more chance of being implemented.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Aug 2007 08:20:34 -0700

At Wed, 22 Aug 2007 12:18:52 -0400,
> of the document, EKR's view, and reality, we would then be

I consider this to be a fair summary of my view, at least.

-Ekr