Subject: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Sep 2007 19:09:14 +0100

This message is trying to summarize recent discussions on 
draft-hartman-webauth-phishing-05.txt.

Several people voiced their support for the document (on IETF mailing 
list and in various other off-list discussions). Ekr doesn't think that 
the document should be published in the current form and he has some 
good technical points that need to be addressed. At least one more 
revision is needed to addressed recent comments from Ekr and SecDir review.

It is quite clear that some people got confused about intended status of 
this document and whether it represents IETF consensus. Sam has 
clarified what was his intention, but another consensus call is needed 
to make sure people agree with Sam.

Subsequent discussions and consensus calls on the document would happen 
on <[email-masked]>.

Alexey,
in my capacity of shepherd for draft-hartman-webauth-phishing

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 09 Sep 2007 19:30:01 +0100

Eric Rescorla wrote:

>Alexey wrote:
>I object to this procedure.
>
>This document has already had an IETF Last Call, where it failed to
>achieve consensus.
>
Ekr, I have to disagree with you.
One objection about the document and one objection about the intended 
status doesn't constitute "failed consensus", considering there are at 
least 8 other people who are in favor of publishing the document. I can 
publish the list of reviewers, if you insist.

>At this point, it doesn't need additional last
>calls to "make sure that people agree with Sam", but rather to go back
>to the authors to try to build support in the community.
>
I was probably not clear enough in my previous message:
1). The document needs more work.
2). The document needs more reviews. Discussions of future revisions 
should happen on [email-masked]
3). The document was effectively reset to pre-IETF LC state.

>Not liking the result of the previous Last Call is not a sufficient basis for
>issuing another one.
>  
>
This statement taken in isolation is certainly correct. However if the 
original LC didn't ask the right question, don't you think this makes 
answers meaningless?

>At some point in the future, it may be appropriate to issue another
>consensus call, but since this is not a WG mailing list--indeed, the
>IESG has twice declined to charter a WG in this area--nor are you the
>chair, it doesn't seem to me that you have standing to do that. When
>that time comes, I would expect the IESG to designate an appropriate
>time and place.
>  
>
I have support of the shepherding AD.
Do you think this is insufficient?

---

From: der Mouse <[email-masked]>
Date: Mon, 10 Sep 2007 10:14:07 -0400 (EDT)

> I really dislike the use of "fishing" with creative spelling in a
> document prepared for an international standards organization.

Perhaps unfortunately, that is *the* word for the behaviour in
question, at least in English.  It was not invented for the draft, and
"com[ing] up with something [else]" would be *less* descriptive and
would render the document cryptic to the people who's been working
against phishing for years.  Perhaps it's a bad word to use in other
languages, but that should be addressed by the translator(s) in
question, not by mangling the original.

> [...], because it sends a number of very bad messages:

> - it's ok for browser vendors to play fast and loose with security
>   related UI elements such as the lock icon and the URL bar (i.e.,
>   have them controlled by the remote server)

> - it's ok for domain vendors to sell domains that use IDN trickery

> - it's ok for certificate vendors to sell certificates that seem to
>   be tied to some known entity but are in reality tied to a different
>   entity

It appears they *are* OK, pragmatically; at least, the first and third
- and quite possibly the second, for all I know - are continuing with
no apparent backlash.

> All of these are unacceptable and we as users of these services,
> community members, engineers and IETF members should do what we can
> to make sure that they don't happen.

Ideally, yes.  Let me know when you manage to get users to drop every
major Web browser and every major cert vendor because they're insecure
against these attacks - never mind when you find users competent to
even understand the issue, much less evaluate Web browsers and cert
vendors in these regards.

In the meantime, I see nothing wrong (and much right) with a draft that
addresses this problem - or at least tries to - in the world as it is,
rather than the world as you, me, and a tiny minority of other people
would like it to be.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 08 Sep 2007 13:53:36 -0700

This document has already had an IETF Last Call, where it failed to
achieve consensus. At this point, it doesn't need additional last
calls to "make sure that people agree with Sam", but rather to go back
to the authors to try to build support in the community. Not liking
the result of the previous Last Call is not a sufficient basis for
issuing another one.

-Ekr

---

From: Bill Manning <[email-masked]>
Date: Sun, 9 Sep 2007 16:48:39 -0700

On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote:
> On 10-sep-2007, at 0:51, Marshall Eubanks wrote:
> 
> >I tend to rely on Dictionaries to sort these things out - from  
> >Dictionary.com
> 
> Dictionaries are useless, when in doubt they just add definitions.  
> For instance, try figuring out how many bytes there are in a megabyte  
> from a few dictionaries.
> 

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, 
`it means just what I choose it to mean -- neither more nor less.'

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 9 Sep 2007 18:47:58 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 

> During the reading of this document, it occurred to me that 
> HTTP digest authentication (RFC 2617) rather than the widely 
> used practice of having security credentials be typed into an 
> HTTP form would achieve 90% of the requirements all by 
> itself. 

Well maybe if people had listened to me then :-)

But at this point fifteen years later Digest is not the way to go. First Digest was designed under the express constraint of avoiding patent encumberances. RSA and D-H were both off the table at the time.

If I was to redo Digest today or expand its scope I would do it differently. The main reason I would not is that SAML and WS-* both provide an excellent solution. I very much like and support the Cardspace idea of building into the O/S platform. I very much like the OpenID concept of making the barrier to entry very low. I would like to arrive at a happy combination of the existing proposals not see more proposals put on the table at this point.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2007 01:21:00 +0200

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Sep 2007 23:37:45 +0200

On 8-sep-2007, at 20:09, Alexey Melnikov wrote:

> This message is trying to summarize recent discussions on draft- 
> hartman-webauth-phishing-05.txt.

> Several people voiced their support for the document (on IETF  
> mailing list and in various other off-list discussions). Ekr  
> doesn't think that the document should be published in the current  
> form and he has some good technical points that need to be  
> addressed. At least one more revision is needed to addressed recent  
> comments from Ekr and SecDir review.

Here's an outsider review.

What's an Ekr, btw?

I really dislike the use of "fishing" with creative spelling in a  
document prepared for an international standards organization. The  
world certainly doesn't need more words that sound the same and  
differ in meaning only by the way they're written, and I'm not sure  
how prevalent this terminology is outside the US and/or the English  
speaking world. Please come up with something more descriptive.

During the reading of this document, it occurred to me that HTTP  
digest authentication (RFC 2617) rather than the widely used practice  
of having security credentials be typed into an HTTP form would  
achieve 90% of the requirements all by itself. (More or less the same  
thing for S/MIME in mail.) The main part that's missing there is  
protection against a man in the middle. Obviously TLS goes through  
great pains to avoid men in the middle, but the document has no  
trouble throwing that out of the window:

    The attacker can also spoof trust markers
    such as the security lock, URL bar and other parts of the browser  
UI.

And:

    Users do not typically understand
    certificates and cannot make informed decisions about whether the
    subject name in a certificate corresponds to the entity they are
    attempting to communicate with.  As a consequence of this  
assumption,
    users will likely be fooled by strings either in website names or
    certificates that look visually similar but that are composed of
    different code points.

Although I agree that a system that can work even under these  
assumptions would be great, I think it's harmful to adopt them in  
this way, because it sends a number of very bad messages:

- it's ok for browser vendors to play fast and loose with security  
related UI elements such as the lock icon and the URL bar (i.e., have  
them controlled by the remote server)

Last but not least, I'm guessing that "ben Laurie" is actually "Ben  
Laurie".

---

From: Bill Manning <[email-masked]>
Date: Sun, 9 Sep 2007 16:48:39 -0700

--bill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 9 Sep 2007 18:47:58 -0700

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2007 01:21:00 +0200

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Sep 2007 23:37:45 +0200

What's an Ekr, btw?

And:

---

From: Bill Manning <[email-masked]>
Date: Sun, 9 Sep 2007 16:48:39 -0700

--bill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 9 Sep 2007 18:47:58 -0700

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2007 01:21:00 +0200

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Sep 2007 23:37:45 +0200

What's an Ekr, btw?

And:

---

From: "tom.petch" <[email-masked]>
Date: Mon, 10 Sep 2007 16:45:36 +0200

----- Original Message -----
From: "der Mouse" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2007 4:14 PM
Subject: Re: [saag] Next step on web phishing
draft(draft-hartman-webauth-phishing-05.txt)

> question, not by mangling the original.

Stick the word in quotes which conveys the message that we know that this is not
a good piece of terminology, but that we are pragmatic enough to recognise that
using it will convey the right meaning to most people.

But on the other strand under this Subject:, I am with those who think that the
IETF has demonstrated an absence of consensus and that the proposed way forward
to try and achieve it by other means in plain wrong.

Tom Petch

---

From: Paul Leach <[email-masked]>
Date: Mon, 10 Sep 2007 16:29:24 -0700

I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 10 Sep 2007 16:52:35 -0400

> I object to this procedure.
shep>
> that time comes, I would expect the IESG to designate an appropriate

I think you're overreacting, possibly due to a misinterpretation of what 
Alexey said and/or of the current state of the document.

My reading of the IESG evaluation record suggests that there are indeed 
some issues that the community feels need to be addressed before the 
document can move forward.  Its current state is "IESG Evaluation::Revised 
ID Needed", which, along with the evaluation record, suggests that the 
responsible AD has asked the author and shepherd to get these issues 
resolved and submit a new document.  I don't know what will happen once 
this is done, but unless the IESG feels we already have _rough_ consensus 
to publish the document _and_ there are no major changes, I would expect to 
see a new last call on the revised document.  Of course, that last call may 
see renewed objections from the same individuals, or from others; that does 
not necessarily mean the last call "failed" -- remember, we operate on 
_rough_ consensus.

Now, given that the responsible AD has asked for a new document, it seems 
to me that Alexey, as the shepherd of an individual submission, has quite a 
bit of latitude in how to get there and what it will take before he is 
willing to take the document back to the IESG.  Given that this document is 
a group effort, it's entirely reasonable for Alexey to want to know that 
people contributing to the work agree with any changes Sam makes, and to 
issue consensus cals in an appropriate forum to do this.  No one is 
laboring under the impression that such a call would serve to "override" 
the "failed" IETF LC.  Instead, when Alexey in his role as shepherd 
believes the document is ready to go back to the IESG, he will inform Lisa 
of that fact, and the IESG will decide what to do next.

-- Jeff
-- Jeff

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 12:19:22 +0100

> `it means just what I choose it to mean -- neither more nor less.'

There has been a discussion recently on LTRU as to whether a Terms and
Definitions section should be introduced within RFCs - much like those
within ISO Standards.

Best regards

Debbie Garside

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: 10 September 2007 00:49
> To: Iljitsch van Beijnum
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Alexey Melnikov;
> [email-masked]
> Subject: Re: Next step on web phishing
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 12:04:01 -0700 (PDT)

> Definitions section should be introduced within RFCs - much like those

And my response to this suggestion is the same as it was for the "IANA
considerations" or "Internationalization considerations" section suggestions:
By all means have a "terms and definitions" section or whatever in the document
if there's a need for one, but don't make having one mandatory in all
documents.

We already have more than enough useless (from a technical content
perspective) boilerplate in our documents. We don't need any more, and
when such sections are always present but usually say "no such and such
are present" they aren't helping.

The last time this came up in the context of IANA considerations it was
asserted that having such sections act as a useful check to make sure there are
no needed definitions or considerations. The problem is people don't work this
way. If the section is mandatory they'll add it when the document is first
created. Sometimes they'll remember to keep it up to date and sometimes they
won't. But when someone reviews the document they'll see that section
and assume its presence means whatever has been checked. So the mandatory
section approach can actually result in more errors and omissions, not less.

It took me only a few minutes the last time we had one of these discussions
to find a documentt (in the RFE Editor's queue, as I recall) where
this had happened: A "there are no IANA considerations" section had been
added early on but when the document acquired IANA considerations it
wasn't updated. And nobody who reviewed the document caught it.

				Ned

P.S. I've read a lot of ISO and CCITT specifications and I have found
their terms and definitions material to be fairly hit or miss in terms of
utility.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 16:11:03 -0400

> perspective) boilerplate in our documents. 
+1

Actually I don't have so much of a problem with having such sections in
drafts at review time, but I hate to see them clutter up published
RFCs.    There are a lot of times when these sections aren't applicable,
and having them in the final document just interferes with readability. 

I also think that a Terms and Definitions section might encourage
document authors to make up new terms when they're not necessary, which
would also interfere with readability.  (geeks love to create new language.)

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 16:55:57 -0400

Ned Freed wrote:
>> RFCs.
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 11 Sep 2007 21:56:49 +0100

Ned wrote:

> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.

I agree.  Which is why a Terms and Definitions section is darn useful as is
an overall Term Bank.  However, I will not labour the point as I have long
ago found that trying to sell Terminology standardization to industry is
practically impossible - unless you rename it as Knowledge Management.

Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled
egg and I, in interpreting your request, presented you with scrambled egg...
You may be somewhat disappointed at breakfast! ;-)

Best regards

Debbie Garside

> From: Ned Freed [mailto:[email-masked]]
> Sent: 11 September 2007 21:27
> To: Keith Moore
> Cc: Ned Freed; Debbie Garside; [email-masked];
> [email-masked]; 'Iljitsch van Beijnum';
> [email-masked]; [email-masked]; [email-masked];
> Subject: Re: Next step on web
> phishingdraft(draft-hartman-webauth-phishing-05.txt)
>
>
> > >> There has been a discussion recently on LTRU as to
> whether a Terms
> > >> and Definitions section should be introduced within RFCs - much
> > >> like those within ISO Standards.
> > >>
> > >
> > > And my response to this suggestion is the same as it was for the
> > > "IANA considerations" or "Internationalization
> considerations" section suggestions:
> > > By all means have a "terms and definitions" section or
> whatever in
> > > the document if there's a need for one, but don't make having one
> > > mandatory in all documents.
> > >
> > Actually I don't have so much of a problem with having such
> sections
> > in drafts at review time, but I hate to see them clutter up
> published
> > RFCs.
>
> My position is the exact opposite. Full and complete review
> of drafts it of paramount importance and anything thqt
> interferes with that is unacceptable.
> And as I have pointed out, we have "running code"
> demonstrating that these things are at best distracting and
> at worst actively interfere with proper review.
>
> What's appropriate to appear in the final RFC is up to the
> RFC Editor. That's what the word "editor" implies. If the RFC
> Editor deems it appropriate to remove null sections that's
> fine, if they feel they should be retained that's fine too.
> Someone reading an RFC to learn how to implement something
> has a definite goal in mind and isn't going to be (or at
> least shouldn't be) distracted by boilerplate in the same way
> a reviewer looking for issues - a far more nebulous
> proposition - can be.
>
> > There are a lot of times when these sections aren't applicable, and
> > having them in the final document just interferes with readability.
>
> It depends on what sort of reading you're doing.
>
> > document authors to make up new terms when they're not necessary,
> > which would also interfere with readability.  (geeks love to create
> > new language.)
>
> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.
>
> RFC 2119 is a case in point. While I have some small issues
> with how RFC 2119 defines its terms, I've come to realize
> that having consistent meanings for these terms is far more important.
>
> 				Ned
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2007 17:05:11 -0400

Oh, it's very useful to have consistent terminology. And if a document
needs to use new terms, they should definitely be defined before use.  I
just don't want to encourage people to make up new terms (or more
likely, whole new paradigms with their own lexicons) when existing ones
will do.  I'm reminded of recent work in NEA, but they're not the only ones.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 11 Sep 2007 15:39:22 -0400

> I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into considerati…

Would someone send a pointer to Eric Rescorla's critique of the
draft? I couldn't find it, although I found comments by various 
other folks on the IETF draft tracker.

--Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 11 Sep 2007 15:39:22 -0400

--Shumon.

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)

> There are a lot of times when these sections aren't applicable,

> would also interfere with readability.  (geeks love to createFrom [email-masked] Wed Sep 12 12:52:33 2007
Date: Tue, 11 Sep 2007 15:39:22 -0400
From: Shumon Huque <[email-masked]>
To: Paul Leach <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft
	(draft-hartman-webauth-phishing-05.txt)
Organization: University of Pennsylvania
Cc: "[email-masked]" <[email-masked]>,
	"[email-masked]" <[email-masked]>,
	"[email-masked]" <[email-masked]>,
	"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

--Shumon.

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)

> would also interfere with readability.  (geeks love to createochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <[email-masked]> for [email-masked];
	Tue, 11 Sep 2007 13:41:44 -0700 (PDT)
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Next step on web phishing
	draft(draft-hartman-webauth-phishing-05.txt)
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked],
	'Iljitsch van Beijnum' <[email-masked]>, [email-masked],
	[email-masked], [email-masked], Debbie Garside <[email-masked]>,
	[email-masked]

> would also interfere with readability.  (geeks love to create new language.)

Very good point. Having lots of slightly varying definitions of various terms
could be hugely harmful.

RFC 2119 is a case in point. While I have some small issues with how RFC 2119
defines its terms, I've come to realize that having consistent meanings for
these terms is far more important.

				Ned

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Sep 2007 16:10:21 -0500

This thread has morphed into something else entirely.  Please change the
subject and move it to an appropriate list (I've set Reply-To:
[email-masked]; please respect it).

For the record, things like IANA considerations sections should be
required of I-Ds, even if to say that there aren' new language.)

				Ned

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Sep 2007 16:10:21 -0500

For the record, things like IANA considerations sections should be
required of I-Ds, even if to say that there aren't any.  A single such
section gathering several such sub-sections should do ("Misc
Considerations.  This draft has no IANA considerations.  This draft has
no ...").  And some such sections might be removed by the RFC Editor, or
not (e.g., remove IANA considerations sections that say there are no
IANA considerations).

Nico
-- 

 new language.)

				Ned

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Sep 2007 16:10:21 -0500

Nico
-- 

t any.  A single such

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Wed, 12 Sep 2007 13:34:07 -0400

My viewpoint is somewhat in between. The sections need to be there, but
only in the final draft(s) that are intended for Last Call. Prior to
that, those sections don't need anything more than a "To Be Determined"
notation. Prior to the Last Call, those sections usually don't add
anything to the technical meat of the draft and aren't necessary.
(Unless of course, the draft is dealing with IANA issues throughout.)

During Last Calls, there are many people reviewing the drafts from many
angles, including the protocol point of view and the IANA point of view
and the internationalization point of view and ....

	Tony Hansen
	[email-masked]