Re: [TLS] Implementation survey: Client Certificate URL extension

[Eric Rescorla <ekr at networkresonance.com>]

At Thu, 10 Apr 2008 17:49:17 +0200 (MEST),
Martin Rex wrote:
> 
> Pasi.Eronen at nokia.com wrote:
> > 
> > Martin Rex wrote:
> > > Pasi.Eronen at nokia.com wrote:
> > > > 
> > > > This vulnerability of Client Certificate URL is already described in
> > > > the Security Considerations text in RFC 4366, so it isn't anything
> > > > particularly new.
> > > > 
> > > > In the context of web browsing over TLS, it isn't really different
> > > > than, say, the ability to include IMG URLs pointing to arbitrary
> > > > hosts (not just the one the HTML page came from).
> > > 
> > > It is completely different!
> > > 
> > > The regular HTTP/HTML based attacks attack the client/browser.
> > > 
> > > The certificate extensions and the client-cert-URL extension for TLS
> > > attack the server, and there is no "must visit a hostile website"
> > > involved at all, the server is guaranteed to fall prey to every
> > > attack automatically if it supports/implements such a feature (or
> > > "inherits" this feature from the underlying middleware).
> > 
> > You're quite right, I wasn't thinking clearly -- this is indeed
> > quite different, since it targets the server.
> > 
> > Nevertheless, it is described in RFC 4366 already; do you think
> > there's something more we should add in 4366bis?
> 
> Security Considerations, section 6.3 of rfc4366 already describes the
> problems and implications in quite detail (I wasn't aware of that).
> But maybe that isn't scary enough?  Personally, I feel quite uncomfortable
> with such a dangerous extension in an IETF standard.  *I* can NOT think
> of a safe mode of operation for the client certificate URL extension.
> As soon as the admins enables it, his server is toast.  Do we really need
> to standardize something that is so extremely dangerous?

Too late for that. Plus, it's not like this is the only place this
kind of thing is standardized. Cf. web pages.


> Btw. why should rfc4346bis (TLS 1.2) obsolete rfc4366 (TLS extensions)?
> draft-ietf-tls-rfc4346-bis-09.txt has this in the second line:
>   Obsoletes (if approved): RFC 3268, 4346, 4366
> 
> None of the vital Security Considerations from rfc4366 was merged into
> rfc4346bis, so this appears to be an error.
> There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366.

Together 4346-bis and 4366 bis obsolete 4366.

As far as I know the security considerations in 4346-bis do cover
the security considerations for the extensions mechanism itself
and the extensions described in the document.

-Ekr
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls