Subject: RE: [TLS] Record layer corner cases

From: Peter Williams <[email-masked]>
Date: Thu, 23 Nov 2006 20:57:42 -0800

> For root certs, the practice is to have them never expire [0]. You'll never> see this written down anywhere (you're supposed to roll over certs every few> years), but I think in practice everyone in the industry knows that root cert> replacement is so unworkable that you just give your certs an infinite> lifetime. When it comes to security vs.availability, availability always wins> out.> > Peter.
 
The business/investement model dictated this. VeriSign existed to make money for its venture investors; nothing would stand in that way, and certainly not personal privacy interests (For example, implement mandatory key escrow! or be put out of business by USG!! VeriSign management quickly kowtow'ed, as did most but not all of the IETF luminaries, to be fair to the VeriSign team). So whilst capitalism broke through the barriers to engender adoption, capitalism also upheld certain other social issues concerning privacy limits via deception, etc. So, fair is fair...
 
But, we are still learning, about crypto and society. Peter was very wrong recently! Even though TLS1.0 had null cipher suites for years, the credit-card world did not *actually* crumble. At the same time, its true that only in the recent IE7 has the global infrastructure for grandmas finally made TLS1.1 the default (and with MSFT IETF-unverified techniques for testing which TLS extensions are actually supported on servers!). So, perhaps we will yet see what further evidence of TLS design vs practice has to offer, now it enters mainstream testing.
 
Peter W.
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today!
http://get.live.com/toolbar/overview

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

---

From: Peter Williams <[email-masked]>
Date: Sat, 25 Nov 2006 19:43:57 -0800

Using TCP "urgent mode", say, for security signaling/controls is a marked deviation from the constructs and design precepts of the SSL Handshake, but not the SSL Protocol, note. I'm being very pedantic with terminology, for a reason: as we discussed earlier, the SSL Protocol is an encapsulation of {SSL Handshake, or other ALPHA handshake(s)) by the Record Protocol. 
 
Allowing the (standard) SSL Handshake to use TCP urgent mode would detract from allowing the SSL3 to be recognized as a fully fledged Internet Standard, known as TLS, a standing it clearly deserves - given its demonstrated range of applicability, its hardware and software implementation knowhow, and the way SSL session handling succesfully cooeprates with stateful inspection firewalls.  In the same vein, recognizing that said potential Internet Standard has proper "future proofing" features (allowing ALPHA handshake designs down the line to evolve the standard) supports SSL3's designation as a fully mature, Internet Standard, known as TLS. That SSL3 is not tied to today's dominant transport (TCP over IPv4 over the US IP backbone architecture) is also good for that standing!
 
Without interfering with the recognition SSL3 in its TLS1.1 form should have as an Internet Standard , we could reasonably keep this WG open if there were a new, distinct standards track initiative to specify one or more "ALPHA Handshakes" - that (a) parallel the SSL Handshake, and (b) have some knowledge of and interaction with post-hooked socket providers (TCP, X, or some of the class d addressed reliable channels we experimented with, long ago, using multicast key management, core-based access and connection controls, and session directory support). A long long time ago, we found it necessary to indeed allow the handshake to *interactively* control how the reliable transport channel behaved, for those transports which merge byte transfer with the very key management concept and access/connection controls being used in the handshake's design.
 
If this is too abstract for folks, there were at one point I-Ds from NSA designers/engineers on using multicast key management for IKE-enhancements addressing multi-drop security association management, that one can peruse for background. Some of these ideas are appropriate for multi-drop session management, particularly when ALPHA-design handshakes would be cooperating with the SAML2 protocols at the https.v2  layer, in the setup/teardown of multi-drop client authentication sessions.

> Subject: RE: [TLS] Record layer corner cases> Date: Thu, 23 Nov 2006 11:37:38 +0200> From: [email-masked]> To: [email-masked]; [email-masked]> CC: > > [email-masked] wrote:> > > > I think this would be taking it too far (consider sending> > ServerHelloDone in its own packet). Plus if you implement> > TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3> > which don't have the restriction.> > A separate record doesn't mean its own IP packet (or TCP segment);> it's just 5 bytes of record header overhead (in case of> NULL_WITH_NULL). But yes, maybe it would still be taking it too far...> > (But TLS 1.2 spec doesn't require you to implement any older spec; and> even the older specs in reality seem to have the restriction that you> can't fragment handshake messages if you want good interoperability.)> > Best regards,> Pasi> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Express yourself with gadgets on Windows Live Spaces
http://discoverspaces.live.com?source=hmtag1&loc=us

---

From: Peter Williams <[email-masked]>
Date: Wed, 29 Nov 2006 09:18:50 -0800

I've gave up making this argument about 5 years ago after 10 years of trying - its ineffective, despite being valid.
Folks roll their eyes when you tell then (a) path *validation* is about strict hierarchical evaluation (b) path *discovery* is about you choosing the certs that makeup your chosen path.
 
They get even more confused when you then tell them that actually, you don't even need to do validation or discovery in SSL/TLS if that is your design whim. Its conforming and as intended, tho not particularly interoperable with the "Netscape https" world, or the DoD-profile of "Netscape https"
 
They get even more confused when you tell them that actually, if you do put 0, 1 or more X.509 Certificate values format in SSL3's PKCS#7 bag in certificate-data, then any of the values can be trust anchors - with arbitrary values in the certificate date fields.
 
You can just send a self-signed cert of the SSL server, if you want, as in the IIS6 resource kit. You can turn off the URI name validation, too, per Netscape https.
 
Lets remember, from the SSL patent: SSL provides the security service of "strongly naming" (my term) the TCP port, including its IP address. In the Novell embodiment, it strongly names the SPX/IPX port. In NATO secure X.400 over IP, it strongly names the TSAP.  This cryptographic port naming is a function of the cryptography and the handshake design, not the certificates. When you no longer trust the cryptographic binding to the newly-named port, you were supposed to escape (sent OOB using the appropriate network service), force a new handshake, rebuild the sessions exchanging the tokens over the current session, and rebind without dropping the connection. Just like a layer 5 secure session-layer protocol entity is supposed to do!
 
Certificates just name and control public keys; in the cryptographic analysis, the strong naming provided by the socket service (or socket-like API)  does not depend on certificates. Neither the the assurance level of that service nor the strength of the port naming mechanism depend on certificates. This trust model is directly analogous to  the .NET trust model, when you sign your .dll, with an RSA key that has no certificate controls attached. The assurance and strength come from the handshake design, and the math/key of the PKC algorithm, not the key distribution.
 
Of course, Https is just http sent over a socket enhanced with SSL, per the patent and per the original declaration when seeking IANA's registration.
 
In "Netscape https", there is of course a more advanced trust model designed for the web, that is rather broken, and doesnt work well with reducing trust (involving multiple hidden session control handshakes, potentially!) to a simple padlock icon in a browser targeting grandma. It involves a hodge podge of PKI theory, URI theory, HTTP proxying practice, and SSO Connect tunneling and bridging. I hope it never becomes an Internet Standard, and I do not support it being on the standards track! 
 
At the same time, its very effective, socially. Celebrate a success in the difficult world of crypto-politics, and just leave it alone, IETF!  The act of observing the information may destroy the delicate balance of its nature! Standardize on TLS 1.1 with its SAML extensions, and now stop! Come back in 5 years, once the internet's upper layers have evolved some more.

> Subject: RE: [TLS] Record layer corner cases> Date: Wed, 29 Nov 2006 09:26:17 -0500> From: [email-masked]> To: [email-masked]> CC: > > The point is that trust anchor installation is an out-of-band process:> standards say nothing about the due diligence that a relying party> should apply before deciding to accept a trust anchor. Out-of-band> also means that if you receive a root cert that expires in 2050, you> are perfectly within your rights to configure your application to make> the corresponding TA valid until 2040, or 2060, as you see fit.> > The standards also say nothing about how relying party applications> might be instrumented to perform debugging and error logging.> It is perfectly legal to check a root cert every single time you> receive it, and generate whatever error messages you wish if you> don't like what you see. But it's also legal (according to TLS> and X.509) *and secure* to ignore a root cert received in a> handshake and validate the intermediate CA cert using just your> own pre-installed TA information.> > Therefore, it is incorrect to claim that a web site or a browser> that is configured to send an expired root cert is misconfigured.> You are free to complain, but they are free, and correct, to point> out that standards do not require them to send a root cert> that is acceptable to you. The responsibility is on you to decide> what intermediate CAs to trust based on your own TA list, not based> on the root certs someone else has installed in their applications.> > Dave> > > -----Original Message-----> From: Kyle Hamilton [mailto:[email-masked]] > Sent: Tuesday, November 28, 2006 10:54 PM> To: Kemp, David P.> Cc: [email-masked]> Subject: Re: [TLS] Record layer corner cases> > A TA that creates a CA identification/authentication certificate in> the correct format (including proper date handling) is much more> likely to create other certificates in the correct format, and thus> NOT create issues in ASN.1 parsing. Various ASN.1 parsers have had> security vulnerabilities that came to light.> > -Kyle H> > > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 Nov 2006 15:29:44 +1300

"Kemp, David P." <[email-masked]> writes:

>Or did they consciously implement the X.509v4 behavior before it was
>documented in X.509v4 because they intuitively understood that it was the
>right way to handle TAs?

Oh, one thing I forgot from my other message: Wouldn't such an implementation
be totally non-compliant with the spec if it implemented behaviour that was at
odds with the actual requirements?  If everyone ignored the spec and
implemented whatever they intuitively felt right we'd get... well, I think
we've already got it.

Peter.