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

[Peter Williams <home_pw@xxxxxxx>]

I don't like the initial part of the binding onto the SSL protocol, if anyone cares! I like the way it uses serverkeyexchange; its cute, 
clever, and uses public key ideas in the core handshake in novel ways. I can see why folks with a particular mindset
about public key and certs will politik against it, though. It doesn't fit with classical doctrine, or the way some
agencies are working (legitimately!) to steer public critical infrastructure towards a certain grade of PKI.
 
(a) It's initial phase is architecturally as suspect as the GSSAPI idea. (The GSS handshake tokens' state could yet pan out 
as improving current session resumption practices, tho. ) GSS API at least doesn't have anything security critical tho.
 
(b) The SRP session resumption restrictions on the USING of an extension value make it really suspect, architecturally
 
Recall that User auth for apps, inband to the SSL Handshake, was withdrawn as the record in SSLv2 spec shows. Client 
Certs are there, but they really are there for making trusted T-connects, not user auth. VeriSign issues a million client certs as 
an experiment. it was not a great success, repurposing client auth as a form of user auth, in the https
arena. In the 802.1x arena, there is possibly a different story and maybe a different outcome, tho, when we
are no longer dealing with "hosts" and logins, but performing device auth to join a nic into an adjacency net, and
where RADIUS does the rest (e.g. securid-enhanced Radius for wireless-nic bridging to ISPs over DSL etc, 
without or without TTLS)
 
Ive never fathomed why folks dont just invent their own client protocols of the Record Protocol for user
auth purposes, give it a record_type, and mandate the dispatcher performs the custom SSL handshake extension 
directly upon session state change after the finish protocol, discarding any APDU till it completes, and sets its
own secure state, a new modified Connection secure sub-state peculiar to the enhancement.. This is what 
the record_type extension capability was for! If I were doing GSSAPI 1-token userauth (a signed blob, of the current
write mac?), I'd do it there, also.
 
In terms of politics, I bet the GSSAPI gets fast tracked once it gets critical mass, whereas SRP will be held up 
procedurally for ever.

---

> To: Peter.Sylvester@xxxxxxxxxx
> Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt 
> Date: Thu, 21 Dec 2006 11:50:35 -0800
> From: ekr@xxxxxxxxxxxxxxxxxxxx
> CC: tls@xxxxxxxx

> In a thread starting November 28, 2005, I asked for expressions of
> support. I received three responses in favor of moving it forward
> as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi
> and I judged that this did not meet the bar of WG support for
> a decision to move it forward at PS.
> 
> -Ekr
> 
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls

---

Try amazing new 3D maps Check it out!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls