RE: Produce material on name-based virtual hosting and TLS

OK. But what effect does the "protocol limitations" have on usable and 
robust security context information (which was also part of what I was 
trying to get clarity on). Did I get the effect right (increase in errors 
on cert processing, so setting user expectations that errors are not a 
problem)? 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




"Hallam-Baker, Phillip" <pbaker@verisign.com> 
03/07/2007 10:39 AM

To
"Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>, 
"public-usable-authentication" <public-usable-authentication@w3.org>
cc
"EKR" <ekr@networkresonance.com>, <beltzner@mozilla.com>
Subject
RE: Produce material on name-based virtual hosting and TLS






It really falls under a category 'protocol limitations that have been 
fixed by subsequent developments which are not yet widely deployed'.
 
 

From: Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com] 
Sent: Wednesday, March 07, 2007 8:03 AM
To: public-usable-authentication
Cc: EKR; Hallam-Baker, Phillip; beltzner@mozilla.com
Subject: Fw: Produce material on name-based virtual hosting and TLS


Since this discussion involves non WG members, I'm moving it to the list 
for public comment.

Thanks for bringing this up, Phil and Eric. I've got a couple of 
reactions. 

As phrased, part of this is more a recommendation. That does not belong in 
the Note, but it's good to start getting public comment (and WG comment) 
on what we want in our recommendations. We'll be setting up an area in our 
wiki soon to start holding these (just as we did to start holding 
potential draft sections of the note). And of course discussions of 
potential recommendations are archived on all the mailing lists. 

I'm trying to recast this to understand the general category of "problems 
with the status quo" this falls under (or if it really is unique). You can 
both help me with that. Would the general category be "technology 
restrictions that undermine consistent and usable deployment of existing 
sources of security context information"? (a bit of a mouthful; I'm sure 
we can cut it down once we understand it.) Or perhaps "error conditions 
are perceived as normal by users", with examples of why enough deployments 
deploy with errors in configuring their security context information that 
users find errors not surprising, which opens up another avenue of attack. 


This might also be related to our discussion of confirmation bias at
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Mar/0037.html

Mike, did you have any concrete ideas on where we should slot that in in 
the Note? 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect

----- Forwarded by Mary Ellen Zurko/Westford/IBM on 03/07/2007 07:53 AM 
-----
"Hallam-Baker, Phillip" <pbaker@verisign.com> 
Sent by: public-wsc-wg-request@w3.org 
03/06/2007 10:41 PM


To
"EKR" <ekr@networkresonance.com> 
cc
<public-wsc-wg@w3.org> 
Subject
RE: Produce material on name-based virtual hosting and TLS









Does the protocol allow the client to state that it supports NBVH? If so 
the transition becomes smooth provided EV capable Web browsers also 
support NBVH as a matter of course. 

> -----Original Message-----
> From: EKR [mailto:ekr@networkresonance.com] 
> Sent: Tuesday, March 06, 2007 6:53 PM
> To: Hallam-Baker, Phillip
> Cc: public-wsc-wg@w3.org
> Subject: Re: Produce material on name-based virtual hosting and TLS 
> 
> Hallam-Baker, Phillip <pbaker@verisign.com> wrote:
> 
> > (cc'd to EKR for comment)
> > 
> > I thinbk we need a section 9.6 as follows
> > 
> > 9.6 Cryptographic protocol limitations
> > 
> > 9.6.1 Layering of HTTP on SSL requires a static IP address 
> per secured 
> > site
> > 
> > IPv4 address space is a finite and increasingly scarce 
> resource. In order to reduce pressure on the IPv4 address 
> space the HTTP/1.1 protocol allows multiple domains to be 
> hosted on a single IP address.
> > 
> > This feature is not fully supported when HTTP is layered on 
> SSL 3.0 or TLS 1.0. The HTTP URI or Host header specifying 
> the virtual domain to connect to is only transmitted after 
> the transport layer security negotiation is complete. This 
> configuration does not allow the server to vary the server 
> certificate presented unless a separate IP address is used per domain.
> > 
> > This restriction is lifted in RFC 4366 S 3.1. Clients that 
> verify that the domain name of the certificate matches the 
> domain name of the site should be encouraged to support this 
> extension.
> 
> 
> This seems pretty correct. It might be nice to mention that 
> servers can't safely use NBVH until client deployment becomes 
> ubiquitous.
> 
> -Ekr
>