Subject: [TLS] Comments on TLS identity protection

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 12:41:53 -0800

I've reviewed both draft-hajjeh-tls-identity-protection-00
and draft-urien-badra-eap-tls-identity-protection-01. Extensive
reviews below but the executive summary is that i think these
proposals are poorly motivated and do not believe they should
be adopted by the TLS WG.

-Ekr

Comments on: draft-hajjeh-tls-identity-protection-00

BACKGROUND
The TLS handshake occurs in the clear. Thus, any observer can
determine the credentials used by the client or server to authenticate
themselves. This document describes an "identity protection" mode for
TLS designed to hide the client's certificate.

GENERAL COMMENTS
I don't understand what the motivation for this mode is. I appreciate
that it was an advertised feature of IPsec, but TLS doesn't 
need to replicate every feature of IPsec. In particular, since
certificate-based client authentication is actually fairly
rare, it's not clear that *privacy* of that client authentication
is really a big consideration.

The good news is that TLS has a very simple mechanism for achieving
this: do an ordinary TLS handshake without client authentication
and then do an immediate re-handshake with client auth. As the 
authors observe, this is slower (two sets of crypto computations
and 4 RTTs) than a specialized identity protection mode. However,
it is available now and as far as I can tell is rarely done.
I don't find the argument that there is a large demand for this
feature if it were only 50% faster particularly persuasive.
Rather, this seems like a premature optimization.

As a secondary consideration, this mechanism provides imperfect
privacy guarantees. Although the Certificate is hidden, the
CertificateVerify is not. As a consequence, if an attacker
ever obtains a client's certificate it can do trial verification
to determine whether a new handshake uses that certificate.

In order for the identity protection to be protected against
MITM attack, the server cert needs to be verified prior to
sending the Certificate message. Because the question of whether
this is the correct certificate is outside of TLS, in many TLS
stacks the handshake completes prior to checking the server
hostname. That won't work here.

DETAILED COMMENTS
S 1.

   Client identity protection may also be done through a EDH exchange 
   before establishing an ordinary handshake with identity information 
   [RESCORLA]. This wouldn't however be secure enough against active 
   attackers and wouldn't be favorable for some environments (e.g. 
   mobile), due to the additional cryptographic computations. 

It's important to be clear about "secure enough". The active
attack here discloses the client's certificate. It does not
result in compromise of the connection.

S 2.
   If the server selects one of the ciphersuites defined in this 
   document, the client MUST encrypt its certificate using the 
   symmetric algorithm selected by the server from the list in 
   ClientHello.cipher_suites and a key derived from the 
   SecurityParameters.master_secret (see section 3 for the key 
   computation). 

This is underspecified. How is the encryption process
performed?

S 3.
This changes the TLS state machine. In TLS the ClientKeyExchange
precedes the Certificate message.

   The identity_protection_key is set to the low order bits of the 
   key_block, and its length is set appropriately to 
   ServerHello.cipher_suite.

"low-order bits"? And what about the next extension which wants
the "low-order bits". You need to specify complete slicing and
dicing instructions.

Comments on: draft-urien-badra-eap-tls-identity-protection-01

NOTE:
This document is somehow related to draft-hajjeh-tls-identity-protection-00.
See the review for that document.

GENERAL COMMENTS
I don't understand what the relationship of this document is to
draft-hajjeh-tls-identity-protection-00, which seems to
be similar. See my comments on that document for why I don't
think this work is adequately motivated.

I note that this mechanism has the same partial information
leakage problem as described in that document.

I note that this document talks about EAP-TLS but it clearly
is a modification to TLS.

DETAILED COMMENTS
S 5.
The "Implicit" mode creates a situation in which two implementations
both of which would be willing to do client auth without encryption
of the Certificate can't communicate because the client insists
on encrypting. That's not really an acceptable situation.

S 6.
Notified mode implies a change to TLS behavior (And the Certificate
reading state machine) from some mechanism that's not detectable
or negotiable inside TLS. That doesn't seem acceptable either.

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 13:04:07 -0800

Martin Rex <[email-masked]> writes:

> Eric Rescorla wrote:
> It is not as rare as you might think.  It is actually the
> default in Microsoft's IIS with some configurations that
> IIS only requests SSL client authentication after
> having seen the request (URL).  It might be a side-effect
> of NOT requiring SSL client authentication on the root/home
> page of the webserver and only for certain areas/paths.

Good point. 

However, as you say in most cases the request for client auth
is contingent upon seeing the request and so a rehandshake is
required here in any case. A one-pass protocol wouldn't work
here.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Dec 2006 22:15:01 +0100 (MET)

> required here in any case. A one-pass protocol wouldn't work

Correct.

I had the same thought but completely failed to point this out.

In the not uncommon case with IIS renegotiating after having
evaluated the HTTP(S)-request, the one-pass protocol can not
be used.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Dec 2006 22:00:29 +0100 (MET)

-Martin

---

From: [email-masked]
Date: Tue, 19 Dec 2006 23:32:38 +0100 (CET)

Hi Eric,

Thank you for your review, please find comments in-line.

Note: my comments concern the draft-hajjeh-tls-identity-protection-00,
since the second document proposes the same feature but by using, among
others, a TLS extension.

> is really a big consideration.

In EAP-TLS, an implementation of TLS for Wireless LAN and later for WiMAX,
the client is authenticated based on the certificate's use. This is the
initial motivation of this work.

> to determine whether a new handshake uses that certificate.

OK. in this case, CertificateVerify should be symmetrically encrypted too.

> hostname. That won't work here.

Could you clarify that please? I didn't get the point regarding the server
cert which is sent in cleartext.

> result in compromise of the connection.

Right, I will modify the text with regard to your remark.

> This is underspecified. How is the encryption process

The following text will be added:

If a stream cipher is chosen, then the peer's certificate is encrypted
with the derived key, without any padding byte.

If a block cipher is selected, then padding bytes are added to force the
length of the certificate message to be an integral multiple of the bloc
cipher's length.

> precedes the Certificate message.

Right. The following sequence replaces the sequence used by the actual
version of the document. It is true that the server must read the
ClientKeyExchange before the Certificate. Is that a big change to the TLS
machine-state?
                                              ....
                              <--------       ServerHelloDone
        {Certificate}
         ClientKeyExchange
         CertificateVerify
        [ChangeCipherSpec]
         Finished             -------->       ....

> the "low-order bits". You need to specify complete slicing and

OK.
TLS notes that P_hash can be iterated as many times as is necessary to
produce the required quantity of data.

Then, both the client and the server derive the identity_protection_key as
follow:

       client_write_MAC_secret[SecurityParameters.hash_size]
       server_write_MAC_secret[SecurityParameters.hash_size]
       client_write_key[SecurityParameters.key_material_length]
       server_write_key[SecurityParameters.key_material_length]
       client_write_IV[SecurityParameters.IV_size]
       server_write_IV[SecurityParameters.IV_size]
       identity_protection_key[SecurityParameters.key_material_length]

> on encrypting. That's not really an acceptable situation.

Agree.

> or negotiable inside TLS. That doesn't seem acceptable either.

Idem for S 3.

Best regards,
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 14:36:43 -0800

> initial motivation of this work.

Yes, but I don't think this really explains why the certificate
needs to be kept secret or why the double handshake technique isn't
good enough.

> cert which is sent in cleartext.

The attacker performs a MITM attack with a valid certificate.
The TLS implementation completes the handshake and then prompts
the application to verify the certificate's identity against
the intended identity. This fails, but by this time the client
has already provided his certificate.

-Ekr

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 19 Dec 2006 15:41:57 -0700

On every renegotiation, does the server have to reauthenticate itself
(present its certificate again)?  Or can the credential on the client
side be cached to avoid that duplication?

-Kyle H

-- 

-Kyle H

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 14:44:39 -0800

> side be cached to avoid that duplication?

I don't think I understand the question.

1. You do a regular handshake with no client auth.
2. The server initiates a rehandshake with client auth. This has
   to be a full handshake with a new key exchange.

Any future resumptions of the second session can be done out
of cache.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Dec 2006 00:07:03 +0100 (MET)

> Any future resumptions of the second session can be done out

When the server-requested renegotiation is application triggered,
as in the Microsoft IIS case, then the server better caches the
result along with the SSL session.

Microsoft IIS has a silly (performance-wasting) bug, where a client that
does either not have a client cert or does not show one (and requiring
the application to perform application level client authentication)
is continously forced through the renegotiation when the client
tries to resume the session from the session cache on a new connection.

-Martin

---

From: [email-masked]
Date: Wed, 20 Dec 2006 00:12:13 +0100 (CET)

Hi Eric,

> needs to be kept secret or why the double handshake technique isn't

IMHO, WiMAX and Wireless Networks operators that use TLS based-certificate
have interests in providing alike GSM and UMTS modele for identity hiding.

I CCed Joe Salowey who could have more arguments regarding the certificate
hiding in WLAN and WiMAX using TLS.

> has already provided his certificate.

Thank you. It is clear for me now. However, sentences will be added to the
Security Considerations, in order for the client to check its
understanding of the server hostname against the server's identity as
presented in the server Certificate message.

Best regards,
Badra

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 11:28:11 +0100

Hi Eric,

IMHO, double handshake technique isn't good enough to many environments, 
especially in performance-constrained environments. In addition:

- As you cited in your early mail, double handshake needs two sets of 
crypto computations and 4 RTTs. The number of RTT significantly 
increases when using TLS over EAP or UDP. Moreover, the client and the 
server need to encrypt/decrypt the whole messages of the second handshake.

- Double handshake reduces the server performance by a factor of 2 or 3 
at least.

- In the case where the client has no certificate and the server isn't 
configured to accept connexions from unauthenticated clients, we can't 
stop the TLS negotiation early. So the server is overloaded for nothing: 
the first handshake is already done and the sever doesn't receive a 
certificate from the client. In the ciphersuites approach, the server 
and the client can detect such configuration early during the hello phase.

- With double handshake, the "privacy" and "no privacy" cannot be 
implemented together. I mean TLS servers aren't so smart to do that 
without external configuration and that the client cannot set or 
negotiate "privacy" with a given server.

- Configuration cost.

Best regards,
Badra

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 12:49:13 +0200

I agree with many of Eric's comments.

TLS can already hide the client certificates, but this mechanism 
is not widely used. This draft proposes an optimization to the 
hiding mechanism that requires a smaller number of roundtrips and 
less computation. 

However, it seems that the reasons why the existing feature is
not used have nothing to do with poor performance. And if the
existing mechanism doesn't have a performance problem, optimizing
it would be premature (and thus "root of all evil" :-).

Best regards,
Pasi

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 12:14:37 +0100

> it would be premature (and thus "root of all evil" :-).

Hi Pasi,

Other reasons are included in my last mail for why double handshake 
isn't good enough, optimization is one of them.

Best regards,
Badra

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 13:49:41 +0200

badra wrote:

> Other reasons are included in my last mail for why double 
> handshake isn't good enough, optimization is one of them.

I don't think any of the "reasons" lead to the conclusion that 
"double handshake isn't good enough"; let me explain why:

> In the case where the client has no certificate and the server isn't
> configured to accept connexions from unauthenticated clients, we
> can't stop the TLS negotiation early. So the server is overloaded
> for nothing: the first handshake is already done and the sever
> doesn't receive a certificate from the client. In the ciphersuites
> approach, the server and the client can detect such configuration
> early during the hello phase.

And why would anyone care about this? (Note that your proposal doesn't
help against intentional denial-of-service attacks either, only
accidental misconfiguration.)

> negotiate "privacy" with a given server.

See draft-simon-emu-rfc2716bis Section 2.7 for how a "smart" TLS
server can support both clients that support privacy and those that
don't. 

> - Configuration cost.

What configuration? A TLS server that supports both privacy and no
privacy doesn't need any configuration options to do so (it does
need the code to do double handshake, but new code would be required
for your proposal as well). A TLS client might concievably have 
configuration option "require privacy", but this applies to your 
proposal as well.

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 20 Dec 2006 13:36:40 +0100

> evaluated the HTTP(S)-request, [...]

This, by the way, applies not only to IIS servers.  The Apache HTTP
server with mod_ssl can also be configured to request client
certificates only for specific requests, which of course is achieved
through a renegotiation.  This approach is reasonable not only for
HTTP applications: An SMTP server supporting TLS might perform
certificate-based client authentication only when used as a mail
relay, and finish without attempting client authentication if
a connection only involves local mail delivery.

Bodo

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 14:15:07 +0100

Hi Pasi,

> accidental misconfiguration.)

does no one care about his server consuming amounts of CPU to do, among 
others, two sets of crypto-computations for nothing?
I didn't say the proposal helps againt MITM. I said double handshake 
raises security considerations regarding MITM, when the proposal does't 
raise new security considerations.

> configuration option "require privacy", but this applies to your 

Many mechanisms can be designed to add client privacy to TLS, but the 
question arises: which one is more efficient and preferment? Haven't 
many documents been originally approved for easy deployment and 
optimization reasons?

Best regards,
Badra

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 15:26:46 +0200

[email-masked] wrote:

> does no one care about his server consuming amounts of CPU to do,
> among others, two sets of crypto-computations for nothing?  

If the extra computations occur only in very rare situations, 
it's perfectly reasonable not to care about it (at least 
sufficiently to spend the $$$ for designing, implementing, 
testing, deploying, etc. a new mechanism).

> Many mechanisms can be designed to add client privacy to TLS, but
> the question arises: which one is more efficient and preferment?

My point was that we *already* have one mechanism for client privacy
in TLS. Thus IMHO the right question to ask is *NOT* which one is 
more efficient and preferred, but rather is the existing mechanism 
so bad that we should spend effort in adding *another* one?

> Haven't many documents been originally approved for easy 
> deployment and optimization reasons?

I think deployment-wise, double handshake has the advantage that
it's already specified and implemented.

Best regards,
Pasi

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 15:08:28 +0100

Hi Pasi,

[email-masked] a écrit :
> it's perfectly reasonable not to care about it 

I disagree. Anybody can connect to your server at any time and doing 
uncompleted double handshake. It is not  a rare situation.

> (at least 

How much :). The proposed changes are minimal.

> so bad that we should spend effort in adding *another* one?

I tried to explain why double handshake is not good in terms of 
optimization and security consideration.

Well, I know your opinion regarding the double handshake since 
Montreal's meeting when you said "it would the same end result as adding 
a couple of roundtrips".
Note that double handshake at this time was not described in 
draft-simon-emu-rfc2716bis-03 and it has been added by August 2006, one 
month after Montreal meeting and three months after 
draft-urien-badra-eap-tls-identity-protection :)

> it's already specified and implemented.

Any link to test the implementation, please?

Best regards,
Badra

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 16:32:35 +0200

badra wrote:
> I disagree. Anybody can connect to your server at any time and 
> doing uncompleted double handshake. It is not a rare situation.

Do you have any data to back that claim? The fact that anybody can
connect at any time does not automatically imply that lots of people
are connecting all the time! 

(And in particular, lots of people without client certificates 
connecting all the time to servers that always require client
authentication, and without malicious intent to DoS the server.)

> > (at least sufficiently to spend the $$$ for designing, 
> > implementing,  testing, deploying, etc. a new mechanism).
> 

To get widespread deployment, several TLS implementations would 
have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, 
JSSE, GnuTLS, etc. Getting any change, no matter how "minimal", 
to them is not easy.

> > I think deployment-wise, double handshake has the advantage 
> > that it's already specified and implemented.
> 

Pick your favorite TLS implementation! There are at least
couple of dozen of them (though probably not all of them
support renegotiation). 

Some of my favourites (which seem to support renegotiation)
are http://www.openssl.org/ and http://www.gnutls.org/ -- but no 
doubt there are other ones that are equally good.

Best regards,
Pasi

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 16:41:22 +0100

[email-masked] a écrit :
> Do you have any data to back that claim? 

No, unfortunately.

> The fact that anybody can
> (And in particular, lots of people without client certificates connecting all the time to servers that always require client
But the "anybody" that can connect at any time will be able to establish 
several "double handshake" in parallel; especially when TLS is used over 
EAP or UDP (I don't have data but maybe Eric).

My point is that double handshake will increase complexity and will not 
help in reducing TLS server overload factor, especially when legitimate 
clients that don't have certificates are trying to connect. Their number 
is not actually important.

> JSSE, GnuTLS, etc. Getting any change, no matter how "minimal", 

I don't see the point here. Any TLS feature will require updating TLS 
implementations.

Best regards,
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Dec 2006 08:08:08 -0800

badra <[email-masked]> writes:
>> are connecting all the time! (And in particular, lots of people
>> without client certificates connecting all the time to servers that
>> always require client
> But the "anybody" that can connect at any time will be able to
> establish several "double handshake" in parallel; especially when TLS
> is used over EAP or UDP (I don't have data but maybe Eric).
>
> My point is that double handshake will increase complexity and will
> not help in reducing TLS server overload factor, especially when
> legitimate clients that don't have certificates are trying to
> connect. Their number is not actually important.

Wait, there are two issues here:

1. General server load in the absence of malicious behavior.
   As Pasi points out, there's no evidence that the double
   handshake technique is widely enough used to cause this
   to be a problem.

2. Enabling DoS attacks. There are lots of ways to DoS a
   TLS server, and since this only doubles server load, 
   I don't think it's much of an amplifier.

>> To get widespread deployment, several TLS implementations would have
>> to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, JSSE,
>> GnuTLS, etc. Getting any change, no matter how "minimal", to them is
>> not easy.
>>
>

Right, which is why it's a good idea to avoid making changes unless
we have to.

-Ekr

---

From: badra <[email-masked]>
Date: Wed, 20 Dec 2006 17:21:13 +0100

> Right, which is why it's a good idea to avoid making changes unless

OK Eric, but extending and changing TLS are two different jobs for me:)

Besr regards,
Badra

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Dec 2006 17:40:55 +0100 (MET)

> I don't see the point here. Any TLS feature will require updating TLS 

The point is, that by using renegotiation (=double handshake)
to protect the client identity, no code changes are necessary,
this should already work with most of the installed base,
even with many/most pure SSLv3 client implementations.

-Martin

---

From: Badra <[email-masked]>
Date: Wed, 20 Dec 2006 18:43:33 +0100

> even with many/most pure SSLv3 client implementations.

I think we can stop argumanting on the (to be extended) code :)

Best regards,
Badra

---

From: <[email-masked]>
Date: Tue, 26 Dec 2006 10:14:49 -0800

Normally, client auth is not allowed on a PKI-class ciphersuite, if the 
server has not performed server auth. (In a mix of PKIand non-pki 
ciphersuites -during a change-ciher-spec between the two - things are 
admittedly more ambiguous.)

On a PKI-class limited renegotiation case (or a session resumption case), 
server auth is implied, of course - assuming both enc and mac ciphers 
mechanism are not NULL.

For SSL3 using the RSA ciphersuites, one can ask for client auth on 
handshake#2, without having provided server cert chain on that second 
'shake; server auth being established in the TLS resumed session (and 
renewed Connection) state.

(I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or either of 
those stds with their "RFC updates" demands) being entirely different beasts 
to SSL3.)

What https requires - and then what SLS3/TLSx.y+upd. requires   - are of 
course different things. By virtue of its definition, https or other "SSL 
application" gets to set  what the usage profile and the cert requirements 
are for an SSL/TLS layer 4.51 port. "Usage profile" includes: constraints on 
cert contents, cert chains rules,root certs, TLS transport handling, 
handling of cleartext and SSLtext data upon TLS upgrade/downgrade events 
(LDAP, HTTP1.1). By analogy, the implementor of https gets to set rules 
like: (1) client cert always requires a new handshake, even on the same TLS 
Transport connection (2) new server auth via certs is also required, on that 
second round

---

From: <[email-masked]>
Date: Tue, 26 Dec 2006 10:34:33 -0800

> tries to resume the session from the session cache on a new connection.

This is not a bug. It is an explicitly permitted state within the SSL v3 
conformance/state. Upon request, a client MAY send a client cert. What 
happens if it doesn't, is server policy.

The handshake protocol affects session state. Session resumption (a poorly 
named procedure) affects connection state, only.

Where a client cert is used for user auth purpose(in e.g. https) we have a 
situation that is different to a client cert being used to merely 
authenticate an T-connect peer. Whether the user app intended a previous 
user auth to be applied to a new connection is not specified in the 
"designers" rendition of the https protocol. That is, its up to the 
implementation of https, by intent. The implementation of Netscape-https is 
very different to that of IE-https (and MSFT's wininet.dll's default 
https,for wininet consumers that are not IE)

By definition http over SSL is https. Nothing more is stated. each https 
designer specifies their own "usage profile". Netscape-browsers have their 
concept for sharing hypermedia-state across TLSconnections, client side, and 
assured OS have theirs. Its that simple. There is no right or wrong, bug or 
not-bug.

---

From: EKR <[email-masked]>
Date: Tue, 26 Dec 2006 07:52:57 -0800

<[email-masked]> 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.

-Ekr

---

From: EKR <[email-masked]>
Date: Tue, 26 Dec 2006 07:51:40 -0800

-Ekr

---

From: EKR <[email-masked]>
Date: Tue, 26 Dec 2006 07:51:40 -0800

<[email-masked]> writes:

> Normally, client auth is not allowed on a PKI-class ciphersuite, if
> the server has not performed server auth. (In a mix of PKIand non-pki
> On a PKI-class limited renegotiation case (or a session resumption
> case), server auth is implied, of course - assuming both enc and mac
> ciphers mechanism are not NULL.

There's no way in TLS to currently have a NULL MAC algorithm.
I doubt there is lilkely to be one soon.

> renewed Connection) state.

I don't believe that this is correct. The state machines for the
two handshakes aren't really related. What language leads you
to believe that this is OK.

> (I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or
> either of those stds with their "RFC updates" demands) being entirely
> different beasts to SSL3.)

I doubt the language has changed substantially in this respect. I
don't recall the WG clarifying this text.

-Ekr

bscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

<[email-masked]> writes:

> Normally, client auth is not allowed on a PKI-class ciphersuite, if
> the server has not performed server auth. (In a mix of PKIand non-pki
> On a PKI-class limited renegotiation case (or a session resumption
> case), server auth is implied, of course - assuming both enc and mac
> ciphers mechanism are not NULL.

There's no way in TLS to currently have a NULL MAC algorithm.
I doubt there is lilkely to be one soon.

> renewed Connection) state.

I don't believe that this is correct. The state machines for the
two handshakes aren't really related. What language leads you
to believe that this is OK.

> (I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or
> either of those stds with their "RFC updates" demands) being entirely
> different beasts to SSL3.)

I doubt the language has changed substantially in this respect. I
don't recall the WG clarifying this text.

-Ekr

---

From: <[email-masked]>
Date: Wed, 27 Dec 2006 07:35:37 -0800

> 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.

---

From: <[email-masked]>
Date: Wed, 27 Dec 2006 08:30:23 -0800

----- Original Message -----
From: "EKR" <[email-masked]>
To: <[email-masked]>
Cc: "Bodo Moeller" <[email-masked]>; "Martin Rex" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, December 26, 2006 7:51 AM
Subject: Re: [TLS] Comments on TLS identity protection

> I doubt there is lilkely to be one soon.

There was no way for a client to directly control the encryption keys/IVs of
a connection, until Fortezza_dms defined itself a way in its
ciphersuite/serverkeyexchange! Clearly, we cannot say the SSL
architecture denied that practice, or akin practices someone
defines local for a (weird) MAC regime!

We should learn to say "IETF standardized/endorsed ciphersuites don't...". 
TLS
has clearly evolved, as a defined term, under the tutelage of IETF. We
now understand that an "IETF-Conforming TLS implementation"
may process local cipersuites, and its necessarily associated key agreement
mechanisms, opaque handers, custom types, ephemeral handling. This
is a consequent of  standardizing  the very means of denoting local
ciphersuites - an excellent  IETF move, if I may deliver an architectural 
compliment.

> to believe that this is OK.

Perhaps its my mental model at fault; this is not uncommon! (And I
known I'm pushing the envelope, here; repeating questionable reasoning
used - and previously challenged - 10 years ago, in a similar debate.
I'm only interesting in RSA optimization, remember. And, I'm not
interested in hobbling RSA, to be only used in modes
equivalent to the limits facing other PKC schemes. And,
lots of multi-key/multi-phase RSA computational variants
exist, awaiting exploitation by designers of local ciphersuites.)

Anyhows, Session Handshakes create pool(s) of TEKs/IKs/MEKs... using PKC 
algs,
with centralized cache and cache protocols based off of sessionid and 
closure
rules (per TLS and per app) that only influence connections that are yet to 
be
active. Connections spawn off of these entries, by embodiment-specific means 
(perhaps
each NIC uses an IEEE protocol to talk to the common session cache on the 
local or
remote master switch in the subnet/vlan's STP, overcoming its vlan 
partioning sandbox
that otherwise limits access to the particular session cache instance shared
by all entities on the (tunneled) vlan)

I see each such entry as being an "instance-factory pattern"; several
runs of the truncated hello->final protocol on some bearer may each then 
renew the
random components of the connection state(s), per connection duplication of 
an
active session. Perhaps the http flows within may be pipelined, which 
includes how TLSconnections
and per-connection TLS messages are mapped to bearer(s). This is 
particularly
relevant if there is natural  parallelism or streaming protocols in effect 
(e.g classical
HTML page resolution where inline DHTML duplicates the active session to 
strongly
name the address(es) resolved for relative URLs subordinate to that page).

Now, for given cached session state (created by shake#1), and the connection
stated with "renewed random values" are the two handshakes not linked by 
values
used in the final protocol of the duplication session?

Particularly, where we are are using unique TLS transports for each TLS 
COnnection, don't we
need to rely on "inter-handshake linkage" using cryptographic strength - 
such that a client
auth done on one TCP connection is carried forward onto the TLS Connection 
duplicated from
its parent that as in turn communicated a different TCP (but still active) 
connection?

(This seemed to be one of the areas in SRP that they had not quite got 
correct, yet.)

And, then turning the argument around, doesn't the same reasoning apply for 
server auth?
> -Ekr

Some fun in 2818, also, (half-)reasoning by analogy:-

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
   in the middle attacks.  In special cases, it may be appropriate for
   the client to simply ignore the server's identity, but it must be
   understood that this leaves the connection open to active attack.

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Dec 2006 17:58:58 +0100 (MET)

> happens if it doesn't, is server policy.

In my terminology it is a design flaw of Microsoft's IIS, and one
that can hardly be overlooked if the functionality is tested at
least once before shipping.

It might be the result of two things:

(a) IIS being stateless for independent connections

(b) the underlying SSL/TLS engine lacking to memorize/cache the
    answer on a (previous) client certificate and making this
    attribute available/visible for the application.

I don't know if any of the existing SSL/TLS stacks memorizes/caches
this meta-information along with the SSL session and make it available
to (stateless) applications, so that they do not bother clients over
and over with pointless renegotiations.

MSIE caches the answer on the client certificate request at the
application level on the client side and automatically applies
it without asking the user.  Netscape/Mozilla/Opera don't do
that and show popups for parallel/new connections (or even
every embedded object if no persistent connections are used).

-Martin