Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS

From: [email-masked] (Peter Gutmann)
Date: Sat, 09 Dec 2006 01:57:59 +1300

Russ Housley <[email-masked]> writes:

>I would like to see this documented in a separate document that can be
>referenced by TLS, S/MIME, and any other protocol that needs to make use of
>PKCS#1 v1.5.

Do you mean the NULL/absent parameters issue?  I can do that fairly easily,
I've still got the text I used for the PWRI RFC, and as I mentioned in an
earlier post it'd be good to have a single point of reference for this.  Since
it's cross-WG, under whose auspices would the draft be handled?

Peter.

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

---

From: Peter Williams <[email-masked]>
Date: Sun, 10 Dec 2006 09:57:07 -0800

sounds more like they are using some or parts of the "SSL Handshake" (parts of which are now known as a "client protocols" of the TLS record layer, in a very dubious architectural move by IETF :-) given the SSL "privacy" goal) as a replacement for IKE, within the IPSEC architecture. 
 
I.E. there may be no TLS Record layer, in openVPN's application context ?
 
I can see why this will get the DARPA-funded folks in IETF jumping up and down, with rage; its dumps the (US-dominated) oakley compromises.
 
I don't believe this (i.e. merely) was an intended modality of the SSL patent, but _not_ inconsistent with the open-ness intended. N&S-derived handshakes for accessing network authentication servers have been around a fair while! I remember reading the article on the Cambridge design, when I was at school (20 years ago)!
 
WS-SX's SecureConversation is following the same course as OpenVPN we can note, however. They are paying careful attention paid to how T-bridges can be handled, each with different security policies concerning how handshakes are selected, the crypto module is seeded etc. It updates and nicely extends much of the unspecified/unstandardized work done in SSL Connect proxy land, with a strong focus on (a) multiple key management domains for each bridge segment, and (b) ensuring connectionless transports are properly handled (c) initiator/respondent access point roaming, and auto-rekeying of the cascade of T-bridge segments... upon roam of either endpoint (GSM security model, styled)

> From: [email-masked]> To: [email-masked]; [email-masked]; [email-masked]> Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS> Date: Mon, 11 Dec 2006 06:11:21 +1300> > Peter Williams <[email-masked]> writes:> > >"OpenVPN actually runs TLS over UDP byimplementing a reliability layer for> >the TLS control channel. TLS is a fairlystrong, well regarded protocol,> >easily accessible using the OpenSSL library,and it seems to be the obvious> >choice for initial authentication and keyexchange. "> >http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00263.html> > In a nutshell what OpenVPN does is use TLS for the handshake and IPsec's ESP> for the UDP transport.> > >Is this still true? I'm proud of the designers who did this, if its true.> >They "got it' > > They certainly did. Throw away IKE and AH, and what's left of IPsec (ESP) is> actually pretty decent - they took the bits that worked and glued them> together to get... well, something else that works.> > Unfortunately the result is completely unpalatable to the IPsec folks, and> probably not too palatable for the TLS side either.> > Peter.
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today!
http://get.live.com/toolbar/overview