W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

RE: "Onion model" explained

From: Joseph Hui <Joseph.Hui@exodus.net>
Date: Fri, 12 Jul 2002 14:05:25 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D551D1CA5@SJDCEX01.int.exodus.net>
To: "Pete Wenzel" <pete@seebeyond.com>
Cc: <www-ws-arch@w3.org>

> From: Pete Wenzel [mailto:pete@seebeyond.com]
[snip]
> In TLS, the premaster secret serves as the "challenge" (though not
> exclusively for this purpose), and a correct MAC of a subsequent
> record is the "response". 

If you see the PMS as *the* "challenge," then it's a
very unorthodox interpretation, because in similar vein,
every byte during handshake is *a* challenge; really. 
Failing any of the byte challenges (as a wrong bytes
produces a wrong hash) results in a bad "response."  

[snip]
 
> ... and for generating the MAC secrets.  Thus, if the client and
> server cannot both arrive at the same set of secrets (because server
> could not decrypt premaster secret, because server is not the
> authentic holder of the correct private key...) the result will be a
> MAC failure.

A man in the middle can also temper with the client and/or server
randoms, which will result in the wrong MS in either side or
both sides, or mug with any single byte during handshake
to set off a description_failed or bad_record_mac alert.
So in this context the PMS is no different from any other
single byte in any of the handshake messages.

> > During a TLS handshake, your browser (ala TLS client), after
> > verifying the cert from the TLS server (contained in the
> > handshake:ServerHello message), encrypts it with the TLS
> > server's public key and sends it to the TLS server.
> > The authN proof -- proof is not the most desirable
> > word I would use here, but I use it anyway for the
> > sake of corresponding with your text -- lies in the MAC
> > of all handshake messages, starting from handshake:ClientHello,
> > up to and including the handshake:Finished!  In short, the
> > coup de grace authN is in the MAC, not in the encrypted PMS.
> 
> Sure; but failure to decrypt the premaster secret causes MAC failure,
> so there is a direct relationship between them.  We are saying the
> same thing.  
>(Minor correction: there is no MAC for the first few
> handshake messages.  

No correction needed: I said "the MAC [singular] of all of
handshake messages, ..." not "MACs [plural] of all handshake
messages ..."  It wasn't luck that's kept me out of trouble,
believe me. ;-)

> It is not possible to key the MAC until the MAC
> secrets have been established, which requires the ClientKeyExchange
> message.)

I wouldn't word it this way to my students in TLS;
but it's no biggie, because those who know how TLS
works would know what you meant to say. :-)

Joe Hui
Exodus, a Cable & Wireless service
=======================================================

> 
> --Pete
> Pete Wenzel <pete@seebeyond.com>
> SeeBeyond
> Standards & Product Strategy
> +1-626-471-6311 (US-Pacific)
> 
Received on Friday, 12 July 2002 17:04:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:01 GMT