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 phis
Sam,
I reviewed your document on "Requirements for Web Authentication Resistant to
Phishing". I think the document is very useful. Here are some comments:
The document provides guidance on designing secure authentication mechanisms
for Web services. The goal is to replace HTML-form- and passwo
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
helpf
At Sat, 18 Aug 2007 07:25:14 +0200,
Eliot Lear wrote:
>
> 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
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 ta
At Mon, 20 Aug 2007 13:12:51 -0400,
Sam Hartman wrote:
>
> Hi, Eric, responding as an individual.
>
> Obviously, I disagree with your basic claim that it is too early to
> write a document like this.
Not quite. My claim is that the IETF should not be publishing
a document like this and then req
> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes:
Eric> At Mon, 20 Aug 2007 13:12:51 -0400,
Eric> Sam Hartman wrote:
>> Hi, Eric, responding as an individual.
>>
>> Obviously, I disagree with your basic claim that it is too
>> early to write a document like this.
At Tue, 21 Aug 2007 13:05:59 -0400,
Sam Hartman wrote:
>
> > "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes:
>
> Eric> At Mon, 20 Aug 2007 13:12:51 -0400,
> Eric> Sam Hartman wrote:
> >> Hi, Eric, responding as an individual.
> >>
> >> Obviously, I disagree with your
At 1:05 PM -0400 8/21/07, Sam Hartman wrote:
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.
That's good to hear. But...
I do
hope that we have consensus these are good requirements,
We absolutely do not have
> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
>> 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 discuss
At Tue, 21 Aug 2007 20:34:30 -0400,
Sam Hartman wrote:
>
> > "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
>
> >> 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 dur
Your view of the facts are quite at odds with the written record and,
more importantly, with RFC 2026.
At 8:34 PM -0400 8/21/07, Sam Hartman wrote:
> "Paul" == Paul Hoffman <[EMAIL PROTECTED]> writes:
>> I do hope that we have consensus these are good requirements,
Paul> We absol
Sam Hartman wrote:
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.
That's not what RFC2026 says.
It's not clear why we bother documenting things carefully when we wind up
inven
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 hone
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
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 PROTECTED]>
> An: IETF discussion list
> CC: IESG <[EMAIL PROTECTED]>
> Betreff: Re: Revi
rinne <[EMAIL PROTECTED]>
>> An: IETF discussion list
>> CC: IESG <[EMAIL PROTECTED]>
>> Betreff: Re: Review of draft-hartman-webauth-phishing-05
>>
>
>
>> Part of the problem may be historical: Requirement documents are a
>> relative
> "Henning" == Henning Schulzrinne <[EMAIL PROTECTED]> 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
--On Wednesday, 22 August, 2007 10:40 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:
>> "Henning" == Henning Schulzrinne <[EMAIL PROTECTED]>
>> writes:
>
> Henning> Rather than an IESG note or in addition to, I
> think the Henning> author should clearly state, in the
> abstract, t
Hi.
Both your and Eric's comments need a longer response.
It was my intent to use strong and weak password equivelantsin the
same way as the IAB document. We agree on what the IAB document
defines the terms to mean. I'll go look through my text and clarify
what needs clarification.
I'm confus
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 doc
Sam Hartman wrote:
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
At 10:40 AM -0400 8/22/07, Sam Hartman wrote:
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-w
Hi Sam.
> I'm confused by your comments on 3.1. I agree with you that an
> attacker could take for example a login password in today's systems
> and use that to to gain the information necessary to spoof other UI.
>
> The primary goal of this document is to propose requirements that make
> it dif
At Wed, 22 Aug 2007 12:18:52 -0400,
John C Klensin wrote:
> 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 reg
25 matches
Mail list logo
