Requirements for Web Authentication Resistant to Phishing
draft-hartman-webauth-phishing-09
Discuss
Yes
No Objection
(Dan Romascanu)
(David Ward)
(Lars Eggert)
(Tim Polk)
Recuse
(Sam Hartman)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
(Cullen Jennings)
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Jari Arkko Former IESG member
(was No Objection, Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2007-08-22)
Unknown
I'd like Christian Vogt's comments (see below) for Sections 4.3 and 8 to be addressed.
Lisa Dusseault Former IESG member
(was Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2007-08-23)
Unknown
As document sponsor I'm taking on Cullen and Ross's DISCUSSes to determine consensus better on this document.
Ross Callon Former IESG member
(was No Record, Discuss, No Record, No Objection)
Discuss
Discuss
[Treat as non-blocking comment]
(2007-08-23)
Unknown
This might be redundant with Cullen's discuss, but... To me this document addresses a very important issue. However, it also seems clear from the related email discussion that this document does not represent IETF consensus. Given that this is coming from a security AD, I think that the "General's dilema" (ie, the danger of the document being interpreted as being more normative than it is intended to be) is particularly important to avoid in this case. Therefore I think that we need to add some sort of warning to the extent that this document is an individual submission that is intended to help to encourage progress on dealing with phishing attacks, but that this does not represent IETF consensus at this time, and that this does not set requirements for future work. We might also want to take a close look at the document regarding whether "requirement" should be "recommendation" in some or all cases.
Chris Newman Former IESG member
Yes
Yes
(2007-08-23)
Unknown
I am voting yes because I feel strongly the IETF needs to publish and approve a document like this and do so relatively soon to take a step forward in this area. I have spoken to some reviewers in the applications area who were pleasantly surprised after reading this document and found it clear and valuable. I am seeing an emerging rough consensus in the intersection between application and security areas to do real work on this topic. Getting a minimalist requirements document done might allow that effort to skip the time-wasting requirements gathering phase and move on to evaluation of real protocol work that will draw in the appropriate technical experts and would thus be good for the IETF in general. This document needs a revision to address the changes Sam wants to make based on Eric's review, Russ's comments and the issues Christian Vogt raised. I trust Jari to hold his discuss for that revision. It is my educated guess there is rough consensus in the IETF to publish this document. However, additional work to document that rough consensus would be helpful given the strength of the two last call objections. I trust Cullen to hold his discuss awaiting such evidence.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2007-08-22)
Unknown
I am voting "no-objetion" with some reservations about whether we really have community consensus. At least two people have voiced strong objections to the publication of this document. Another has suggested that individual submission is not the appropriate mechanism to tackle such an important topic.
Russ Housley Former IESG member
No Objection
No Objection
(2007-08-19)
Unknown
Section 3 says: > > Similarly in a system that used smart cards, the smart cards would > need to be trusted not to give attackers access to private keys or > other authentication material. > This should accomodate other authentication tokens too. I suggest: > > Similarly in a system that uses smart cards or other authentication > tokens, the token needs to be trusted not to give attackers access > to private keys or other authentication material. Section 4.1 says: > > Carrying a smart card or USB token ... > To match above, I suggest: > > Carrying a smart card or other authentication token ... > Then, the reaining text in Section 4.1 should be revised to talk about authentication tokens in general. Most is unnecessarily specific to smart cards. I think the Security Considerations should say someting about DNS, especially in the context of the RFC 2818 checking.
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
Recuse
Recuse
()
Unknown
Cullen Jennings Former IESG member
(was Discuss)
No Record
No Record
()
Unknown