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

From: Peter Williams <[email-masked]>
Date: Thu, 21 Dec 2006 21:54:24 -0800

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: [email-masked]> Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt > Date: Thu, 21 Dec 2006 11:50:35 -0800> From: [email-masked]> CC: [email-masked]
> 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> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Try amazing new 3D maps
http://maps.live.com/?wip=51

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Tom Wu <[email-masked]>
Date: Fri, 22 Dec 2006 11:30:50 -0800 (PST)

> write mac?), I'd do it there, also.

If I understand this correctly, the user authentication would take place
after (and on top of) an underlying TLS session?  In this case, what
ciphersuite would that session use?  If it's anonymous, it's still
vulnerable to active attack, even if you do application-level or some
other protocol inside a TLS session.  If it's certificate-based, you
still depend on a PKI of some sort.  The security of the TLS/SRP scheme
depends on the password authentication being intertwined with the key
exchange.

Tom
-- 
Tom Wu
http://www-cs-students.stanford.edu/~tjw/

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 26 Dec 2006 01:58:46 -0700

...primarily because there's no "record_type extension" mechanism.
There's not even a defined range for experimental ones.

Yes, it's security-critical.  And yes, new record types cannot be
created without WG action.  However, I should think that this would be
a VERY good reason for defining a range of record types that can be
experimented with, and which can be guaranteed to be safely ignored by
non-experimental stacks.

and if I had any idea how to write an RFC or who to submit it to, I'd
write up an idea for how to handle it.

-Kyle H

On 12/21/06, Peter Williams <[email-masked]> wrote:
>  the record_type extension capability was for! If I were doing GSSAPI
> 1-token userauth (a signed blob, of the current

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 19:43:57 -0800

----- Original Message -----
From: "Kyle Hamilton" <[email-masked]>
To: "Peter Williams" <[email-masked]>

> experimented with, and which can be guaranteed to be safely ignored by

struct {
        uint8 major, minor;
} ProtocolVersion;
enum {
        change_cipher_spec(20), alert(21), handshake(22),
        application_data(23), (255)
} ContentType;
struct {
        ContentType type;
        ProtocolVersion version;
        uint16 length;
        opaque fragment[SSLPlaintext.length];
} SSLPlaintext;

just define your own, number 255. Define your own major=255 and minor=255
if you want, also

When interworking with a conforming SSL entity, you should get
unexpected_message fatal alerts. From your responder, with the knowledge
of the experimental types, you will presumably not.

There is no harm in defining your own record_types. You were supposed to.

Experiment!

> write up an idea for how to handle it.

Don’t bother till there is evidence of a community that wants to interwork.