On 8 Mar 2014, at 17:25, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 8 March 2014 16:19, Jim Schaad <ietf@augustcellars.com> wrote:
>> There is a major requirement for renegotiation for protection of the client
>> credentials that is being used in various EAP methods as well.  HTTP is not
>> the only use of this.
> 
> I'd be interested in learning whether a similar mechanism would suffice for you.
> 
> Nonetheless, this is a decision that is being made for HTTP.
> Presumably EAP could continue to use renegotiation.
> 
> I recommend you explain your use case for renegotiation, since it's at
> risk in TLS 1.3.

Btw, I have a use case for renegotiation that I would like to check here.
The WebID over TLS spec needs it as things stand at present:

http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence

It's all a question of politeness: of when one should ask a client for its identity.
We need to be able to allow a well behaved site to respect people's desire for anonymity
as long as possible.
	On many sites most pages may not need client authentication at all, and only a few 
pages (which may only be accessible after a longer browse through the site) may require it. Not
having client authentication renegotiation would require the client to authenticate to the 
site before even having seen the first page. This would be akin to not allowing someone 
into a shop before they showed their ID. It may be fine in a war/military situation, but not in a 
commercial  environment. In all shops I know of one allows people to browse what is available
without bothering them for their identity. Allowing a client to browser information is what
is going to allow the client to make a decision as to the value of revealing her identity.

Also some pages MUST NOT have client authentication. For the WebID protocol this would
be the WebID profile page. Having client authentication on that page could result in an
infinite loop, since servers can be clients too in that spec. Consider what would happen
in step 6 of the spec without renegotiation:
  If Alice's server was required to authenticate to get Bob's profile, and used the WebID
enabled certificate of Alice, then Bob's server would need to authenticate Alice. This would
require it to get Alice's profile. But if that also required authentication we'd be back at 
step 6 of the diagram mentioned above, and there would be deadlock.
 

----

But perhaps with "Client Authentication Request Extension for (D)TLS" [1] mentioned earlier in this
thread the HTTP2.0 spec could be updated to allow the server in a 401 to express it's capacity
to accept TLS authentication too - perhaps even WebID certificate authentication. 
In which case browsers would be able to offer that option to their end users.

-----

Perhaps this would also solve the current problem with the need for servers to be set up in WANT or NEED 
mode (which is also a problem of politeness) and which I think is tied to 
section 7.4.6 of RFC5246 [2]. If a server is in WANT mode and asks the client for a certificate,
but the client does not wish to authenticate, then the server can continue - by for example politely
returning an HTTP 401 and a human readable error message, or by redirecting to another page 
( a login page with username-password for example ). In NEED mode the server breaks down the connection
in an ugly way - since the error handling of TLS is much less advanced than that of HTTP.
I have not yet worked out why some clients - such as curl or Opera ) only send a certificate when 
the server is in NEED mode, and not in WANT mode. ( please let me know ).

But again with "Client Authentication Request Extension for DTLS" that could be left to the HTTP
layer to ask the client for authentication, and so perhaps that problem would go away too...

Henry


[1] http://datatracker.ietf.org/doc/draft-thomson-tls-care/
[2] http://tools.ietf.org/html/rfc5246#page-55

7.4.6.  Client Certificate

   When this message will be sent:

      This is the first message the client can send after receiving a
      ServerHelloDone message.  This message is only sent if the server
      requests a certificate.  If no suitable certificate is available,
      the client MUST send a certificate message containing no
      certificates.  That is, the certificate_list structure has a
      length of zero.  If the client does not send any certificates, the
      server MAY at its discretion either continue the handshake without
      client authentication, or respond with a fatal handshake_failure
      alert.  Also, if some aspect of the certificate chain was
      unacceptable (e.g., it was not signed by a known, trusted CA), the
      server MAY at its discretion either continue the handshake
      (considering the client unauthenticated) or send a fatal alert.


> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/