[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TLS] IETF67 TLS Summary

 
After 10 year, all IETF WGs should automatic candidates for closure. PEM and PKIX were exceptions for lengetivity, because govt policies had long kept crypto technology suppressed, and time was the necessary element for good stuff to find its place in the Internet. TLS isnt in the PEM/PKIX category, tho. SSL was just a remake of already standardized NSA stuff,  based on a well understood set of design principles for secure IP lans/wans, done way back in 1989! Several folks posting here were part of it!

I think TLS has had benefits, over SSL3, in the EAP wireless, wap and IM space; and I do think IETF added some value to SSL3 - measured in objective levels of adoption in non web spheres. I find the SAML extensions fascinating, and have lots of applicability with a next generation https suiting web2.0 worlds (done in non IETF forums, better suited to web standardization). Kerberos assertions from a remote IDP presented in a SAML authorization, carried in a TLS extensions, converted to a trusted identity for a secure OS host relying on TLS security contexts to create a local TPM context controlling how the secure realmode desktop experience in Windows in China is limited by remote US policy..... these are all exciting and future thinking ideas. But they are DARPA *research*, not modern-IETF *standardization* efforts.
 
Making TLS into a generic endpoint of all upper layer services (just because https is pretty universally implemented and widespread in applicability) is not appropriate. The GSS-API initiative is such an inappropriate initiative; its wrongheaded, and doesn't simply solve a kerberos problem. Fix broken kerberos -for-internet ciphersuites by all means (they have been broken ever since introduced in 1995!), but dont - via TLS standardization - make https into a universal bearer for all authentication techniques that have no design addressing the specific dynamics of the hypermedia world. Similarly, with signed evidence, make TLS handshakes participate in the surveillance and eavesdropping world that Americans live in, so ISPs can more easily prove that their infrastructures satisfy the spying culture mandates. This is good for the Internet Society, continues the debate over those difficult political issues, and will lead to an increased adoption of the "trusted Internet" into mainstream US society. But, lets not just create work items for the sake it it.
 
TLS WG is looking very tired, speaking as a well-meaning, well-informed SSL outsider, peeking in, occasionally. Ignore the comments, as one sees fit. In my view, however, its time to create new work groups addressing TLS spinoffs, only when needed, with new leadership dynamics - assuming there is some real groundswell momentum that needs the magical IETF process to then do its usual thing. Right now, it really looks like old money for old rope tying up old problems, anew.
 
 

> To: saag@xxxxxxx; tls@xxxxxxxx
> Date: Fri, 17 Nov 2006 17:22:27 -0800
> From: ekr@xxxxxxxxxxxxxxxxxxxx
> CC:
> Subject: [TLS] IETF67 TLS Summary
>
> TLS met on Friday morning.
>
> The major discussion item was TLS 1.2, which is moving along. The only
> contentious issue is the PRF. The general theory seemed to be to have a
> default PRF (based on SHA-256) and then require future cipher suites to
> define their own PRF with a preference for something based on the TLS
> PRF. We also discussed the IV for counter mode and GCM but no consensus
> was reached and the issue will be taken to the list.
>
> Pasi Eronen presented on a bunch of bugs in the way that TLS stacks
> handle legal but unusual record layer constructs. These don't appear to
> be security issues but rather interop issues. It was suggested that TLS
> 1.2 forbid some unusual behaviors (e.g., empty fragments in the
> handshake). Text will be proposed on the list.
>
> Russ Housley gave a presentation on adding signatures to TLS for
> evidentiary purposes. This was somewhat contentious but the WG seemed
> generally in favor. This would require a charter change and discussion
> on the list.
>
> Tim Polk gave a presentation on some issues NIST had with TLS. Mostly
> these are minor issues or clarifications. Resolutions to be proposed on
> the list.
>
> Stefan Stantesson gave a presentation on an approach he's been working
> on for integrating GSS-API with TLS. This was quite contentious and no
> consensus seemed on hand. However, no actual draft is available so the
> next stage is for Stefan to circulate one.
>
> -Ekr
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls


Check the weather nationwide with MSN Search Try it now! 
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls