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

Yngve Nysaeter Pettersen wrote:
> 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).

Didn't know that - its further along than I thought from the sounds
of it.

> Revocation checking is a reqirement in EV validation.

Sure. The point is that our current text on that could be read as
saying that the status_check extension wasn't a good way to do
revocation checking. So we might want to allow for use of the
status_check extension when we talk about what's not "Relaxed
Path Validation." We don't have a term for that now other than
3280's Basic Path Validation, so maybe we need a new definition.

S.

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

Received on Wednesday, 7 May 2008 14:01:42 UTC