Re: [TLS] Comments on TLS identity protection

[<[e-mail]>]

> <[e-mail]> writes:
>> By definition http over SSL is https. Nothing more is stated.
>
> I'm not sure what "nothing more is states" means. RFC 2818 provides
> a fair amount of detail on HTTPS.

Well, perhaps yes and perhaps no; I can argue two ways: by definition and by
example. By definition, the cited work states "This memo describes how to 
use
TLS to secure HTTP connections over the Internet." By example, the cited 
work
doesn't state how IE2 and IE3 browsers working in a pure Novell net
workstation environment allow the win95/98/Me stack to resolve HTTPS URLs,
while even optionally cooperating with IP-websites using port 443! Surely, 
this
example alone demonstrates that https is not limited to Internet! It 
supports the
very  first of the cited work! RFC 2818 does not define https: the protocol
the usage profile(s), the URL resolver. Its just another designer's profile.

The terms "https" was defined in the SSL patent. https is "http over SSL
[the architecture]". The patent does not say...it MUST be bound to an SSL
transport addressed using IANA-registerd TCP port (and lets note that IESG 
has
essentially repudiated its https/ftps port architecture, and we all know 
https
can bind to any SSL layer 4 port number!): http over client.write PCTv1 over
reverse-tunnel server.write SSLv2 over netbios over SPX/IPX over Ethernet.v1 
is
just fine, where WINS resolves the netbios names in the certs!! The patent 
clearly
indicates the claims are not limited to internet bearers, does not assume 
DNS
support by the resolver of the https URL protocol. If all that early stuff
(now seen used very little in its original Novell form) happened to gateway 
to
IP SSL sites using SSL Connect (still seen in modern Microsoft ISA proxies,
with interesting tunneling constructs these days), then IE3 browsers 
(applying
the "https" URL on Novell nets) could even talk to Internet websites. This
was "IE3-https"; im not sure Navigator.v4 ever bothered to match; it's a 
long
time ago, tho. It was an "mozilla-compatible but \"embraced-and-extended\" 
https")

The patent defines what SSL is (the general state machine architecture, not
any particular handshake,ciphersuite or transport embodiment). It says very
little about https. Its an example application. Its
pretty clear, that the usage profile models featured in LDAP and HTTPS1.1 
(to
start and stop TLS session/connections as indicated by signals inband to
application-data record_types) are very different to the "classical" class 
of
https-es, from the Mozilla and SSL Connect world, which are based on the 
rules of
URL protocol resolution.

Given "https" can include fallback to PCT1.0, Does IETF-https include PCT 
1.0
fallback?  ? No! the https URL protocol resolver does, tho! Obviously,
in PW world, experimental PWSSLs got added to that resolver, playing with
things like ENUM addresses.

So, RFC 1818 is deficient in many regards, as THE spec of "https". It doesn't
address non-internet bearers, and it does not address URL resolvers. It then
essentially advocated making the URL resolver is the packet originator of 
TLS
connections and the initiator the TLS Session, interfering with the wider 
T-bridging
architecture that https facilitated, in practice. Its just "RFC 2818-defined
https" (and mighty fine profile it is too, particularly in its focus on
closure rules)

So, hopefully this argument demonstrates that 2818-https is but another
variant of https, no more no less; hopefully, it acts as much as a 
conformance
test target as a protocol spec (facilitating interoperability of the subtler
elements, for mainstream internet https websites.)

I do doubt whether 2818-https is functionally equivalent to IE-https, 
IE3-https,
wininet-https, soap-binding-https, netscape-https, mozilla4-https,
saml2-bindings-https, ws-fed-bindings-https, however; I believe it can be
built with a lesser number of security critical functions than most of 
those,
however.

IF we need more evidence, we can cite already heard testimony from others, 
not Peter,
that IIS3 and later has particular handshake practices, on seeking client 
certs
over https over the same TCP connection (where client certs are used as a 
user auth
mechanism, per mozilla-https practice) from "known-to-be-intending-
to-be "mozilla-__compatible__clients. And, we saw behaviour difference being
mentioned, when being presented (or not) with a client cert upon request 
handshake
request.

Some of the Microsoft IE team's approach to https for "enhanced mozilla-
compatible" browsers was based in its work on PCT, which had some 
interesting
ideas not present in SSL2/3. Speaking liberally, and non professionally for 
a
paragraph, these ideas got placed into the "usage-profile" of SSL3, as
manifest in IE.Vx-https. This is proper, and per intent. Being compatible 
with
II3+ and mozilla means only that the two "interoperate in practice", not 
that they have
the same usage profile or security target. Credit goes to the web for having
achieved a "subtle" level of security interoperbility, for once! This 
practice
fits web culture, tho perhaps not Internet culture, where we might prefer a
formalized 2818-https, with a single correctness definition.

Ill going to buy your book on SSL/TLS, today; and read it carefully. I'm 
hoping
it lays out a good set of the known rationales for what are lots of subtle
design choices facing designers, at least for those relying on 2818-https, 
RFC 2817
and other of that ilk such as ldap over SSL. I'm really
quite interested in what rationales IETF had, for these latter binding
practices onto TLS, particularly since given modern work is ongoing in
binding application layer protocols (e.g. saml2 profiles to https). I'm
expecting (sincerely) to learn.

Peter.
----- Original Message -----
From: "EKR" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, December 26, 2006 7:52 AM
Subject: Re: [TLS] Comments on TLS identity protection

>
> -Ekr
> 

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