Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-13.txt

From: [email-masked]
Date: Mon, 18 Dec 2006 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: Using SRP for TLS Authentication
	Author(s)	: D. Taylor, et al.
	Filename	: draft-ietf-tls-srp-13.txt
	Pages		: 26
	Date		: 2006-12-18
	
This memo presents a technique for using the Secure Remote Password
   protocol as an authentication method for the Transport Layer Security
   protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tls-srp-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-srp-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Peter Williams <[email-masked]>
Date: Thu, 21 Dec 2006 09:50:18 -0800

An important concept in IETF is that the WG is distinct from the mailing list. Furthermore, WG and authors
are distinct. Furthermore IESG processes are yet more distinct. There is not a WG in IETF that would
have me, for example! Put Peter's name on an I-D, and its the kiss of death!
 
The mailing list arguments are NOT the place where Eric's jugements are based, if I look
at 10 years of history of viewing previous resolutions in IETF. They are in a place you and 
I cannot see, with political forces that are not visible. There is no accountability, and 
no means of reasoning against them. Many personal, funding, back-project & other
biases come into play.
The ONLY way to argue against this process is to deploy. If there is adoption, those 
non-mailing list processes do Change. They are still very biased and un accountable, but
the politics DOES WORK. IETF is not a plebs paradise; its built on the politics of 
wars-of-adoption. One has to admit, at the end of the game, its specifications are
models of engineering clarity and do-ability, when they stay below 50 pages.

> Date: Thu, 21 Dec 2006 18:10:48 +0100
> EKR wrote:> > Peter Sylvester <[email-masked]> writes:> > > >> Would you mind giving a little bit more detailed explanation in particular> >> what are the reasons why this cannot be on standards tracks, or what would> >> be necessary if it would be etc.> >> > >> > There are two reasons. First, as a matter of policy we are attempting> > to move new work to Standards Track only where there is fairly strong> > support for the work. In this case, the support for this work did> > not appear to be particularly strong.> > > Several existing interoperable implementations exist. I think that this is> perfectly in the spirit of the IETF. If accepted as a standards track, > the protocol> would probably directly directly go to draft.
 
_________________________________________________________________
Fixing up the home? Live Search can help.
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=wlmemailtaglinenov06

---

From: Peter Williams <[email-masked]>
Date: Thu, 21 Dec 2006 13:00:30 -0800

> To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorité; > die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 
The main problem I have is almost immaterial, and is actually manifest in the tag line.
 
The English rendition contains a URL, with obvious benefits. It also focuses on the zignature
vs. the Zertifikate. The French and German renditions don't; they refer to the English rendition. 
The French version then gets hungup on "authority", and the German gets hungup on perhaps or 
perhaps not ever 'finding" stuff.

---

From: Peter Williams <[email-masked]>
Date: Sat, 23 Dec 2006 11:42:10 -0800

Open:
 
The stated rationale against SRP is poor, in my opinion. I doesn't "politically" convey that other unstated factors were 
_not_ actually in play (hints of Powell's UN argument, here, now that this is "a role model"). Me and Pasi thought this (one night 
in the bar...), trying to appear rationalized by appealing to a bit of counting, on a dubious mailing list call.  It
doesn't smell right; like no toilets and hotels for blacks in 1960s Mississippi, to enforce limited social mobility
and containment, by some oppressive group or other, working through indirect policy means. All manner of 
indirect biases become possible, with this limited argument. Its too easy to be 100% wrong, and be in no 
position to recover from the resulting mess.
 
If we consider the Intel/personal line, on the topic, however, we get to reopen now the core argument, on TLS 
itself. Fairs fair! Eric and co need to seen to be very consistent; its a difficult leadership job, especially so 
when you are an IAB member!
 
If we are going to look at IP, TLS (with SRP in particular) is not on solid grounds itself, given the nature of 
the SSL patent license.  The SSL patent make insufficiently general claims covering user auth inventions, 
anti-phishing inventions, etc. Others have, for an (NDA) fact. B4 the IETF era, you might even
see my name... on applications. Ive also done stuff subsequently, tho. not while being IETF contributor
on SSL.
 
http://www.imc.org/ietf-mxcomp/mail-archive/msg04033.htmlPhil was not correct that SSL Patent (validly) covers transport layer security (lots of SSL-like layer
security protocols existed before it (TNI-based), for layer 4 ports.) I half remember working
for Motorola GSTG, with the patent-crazy engineers who worked that area in the late 80s. The claims 
only cover a particular system architecture of deploying a session layer protocol, where session and 
connection states are managed independently, with cached session management in the vlantagged-trunking 
protocol (master switch), connection handling in the (slave) switch(es) handling a given vlan (to use some fun, 
modern embodiments). Lots of other SSL-related patents application can (and have) been filed that 
are unrelated to the architecture. Its easy to step on them, once they emerge or their continuations
emerge: SSL combined with fault-tolerant re-homing of gateways, re-election of master trunking nodes...., 
re-handshaking for trunk tunneling of labeled record_types....
 
If one notes, I've been going ON and ON ad nauseam about the historical architecture, and the development 
thereof. I'm trying to keep IETF on solid footings, re the SSL patent, to extract the IP protection value out of 
the parts of the (poorly written) license grant that are actually sustainable, and useful. We can help protect 
IETF and its open mission, if we just stay within certain tramlines. Using the SSL patent like this, is like how 
we used the RSA patent, to safeguard the core of the public interest from certain power players, whose mission 
did not well align with that of the open networking community reaching out to grandma. Yes, that policy generates 
much short-term enmity, makes a few people millions, but if we look at RSA... its now doing what the beauty 
of the math discovery allows for. It didnt get subverted, with capitalism/greed acting as political countermeasure
to the almighty power others had.
 
We want the same for SSL, dumping horrors like IESG-endorsed! RSA_EXPORT, for example.  Hobbling the
final protocol is one thing, hobbling the key management is another!

> Date: Fri, 22 Dec 2006 14:35:04 -0800> From: [email-masked]> To: [email-masked]> Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt> CC: > > On Fri, 22 Dec 2006, Blumenthal, Uri wrote:> > > I've heard that other parties claim that their patents cover SRP> > method as well. Stanford license agreement pretty much says "yeah> > those claims may be true - and if so it's your problem". (Caveat:> > I'm not a lawyer - the above is how I understand the written text.> > Feel free to correct me and provide the right interpretation.)> > AFAIK it's standard boilerplate.> > > I understand that since Stanford doesn't charge for the license,> > one can't demand or expect much from them, but you must understand> > those who find such a license less than reassuring.> >> > In short - I'd like to see some evidence that political/legal/IPR> > problems indeed have been solved (which is harder than writing an> > implementation :-).> > Under the current circumstances, the growing base of running code> for TLS/SRP and the rough consensus among its implementors is> the best evidence one could reasonably expect. If SRP weren't> truly free, it would be in the same boat as the other ZKP protocols> and would not have attracted the interest level it has, especially> with OSS projects.> > > Regards,> > Uri> > <Disclaimer> I speak for myself only> > Tom> -- > Tom Wu> http://www-cs-students.stanford.edu/~tjw/> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Try amazing new 3D maps
http://maps.live.com/?wip=51