Re: ACTION-417: investigate completeness of error handling wrt TLS extensions

On Wed, 07 May 2008 15:18:11 +0200, Stephen Farrell  
<stephen.farrell@cs.tcd.ie> wrote:

>
>
> So, I've taken a look but don't yet have specific text to suggest
> for xit. Maybe put this on a call agenda, or consider it at the
> f2f.
>
> TLS 1.2 [1] allows for extension handling and defines 1 extension
> (signature algs) that I think we can ignore.
>
> TLSEXT [2] is a draft that specifies a bunch of existing extensions,
> two of which we might, or might not, want to mention. I've no idea
> of how widespread adoption of any of these extensions might
> prove to be - but I don't think they're used much (or at all) today.

TLS Extension support is new, and there have been substantial  
interoperability problems, which actually forced Opera to disable (by  
preference) both TLS 1.1 and extension support throughout the 8.x version,  
and it was only possible to enable it in 9.x because we added a feature  
testing system with fallbacks.

At present, as I understand it, IE7 on Vista support the servername  
extension, I think beta versions of FF supports it.

With respect to the certificate status extension, it should work in Opera  
9.26 and later, and it is possible that Windows 2008 supports it on the  
client side (I know it does on the server side).

Revocation checking is a reqirement in EV validation.

> In general, TLS extension handling is initiated by clients, and
> servers are to ignore unknown extensions, so I guess introduction
> of new extensions ought be something we can safely ignore in most
> cases.
>
> The two extensions we might want to mention are:
>
> - status_request: a client can ask the server to include an OCSP
> response for the server's cert as part of the handshake. I guess
> we might want to allow for this as an alternative to the status
> checking defined in 3280 that we insist upon for AA certs. (*)
> [I think this extension may be intended mainly for EAP/TLS so
> perhaps we don't need to bother with it?]
>
> - server_name: this allows a client to indicate to the server the
> DNS name for which it wants the server to present a certificate
> in order to better support virtual servers of various kinds. I
> think (not quite sure though) that if the client does use this
> extension and the server responds with a cert that doesn't match,
> then the client should barf the session, for any type of cert.
> We currently say "When the URL corresponding to the transaction at hand
> does not match the certificate presented, and a validated certificate
> is used, then error signalling of level danger(6.4.4 Danger Messages)
> MUST be used."
>
> Be no harm if someone else took a peek at [2] as well to see if
> I've missed something.
>
> Cheers,
> Stephen.
>
> (*) In passing, I noticed that we say "When certificate status checks
> are attempted, but fail due to network errors or related error
> conditions,..." I think that'd be clearer as "When certificate status
> checks are attempted, but where the check fails, (i.e. does not
> produce an answer as to certificate status), due to network errors or
> related error conditions,..." The current wording might be mis-read
> to say that an actually revoked non-AA cert (check "failed") only leads
> to a warning/caution message and not a danger message.
>
>
> [1] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-10.txt
> [2] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-02.txt
>



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 7 May 2008 13:31:33 UTC