Re: [TLS] Verify data in the RI extension?

[Eric Rescorla <[e-mail]>]

At Fri, 27 Nov 2009 16:23:36 +0100 (MET),
Martin Rex wrote:
> 
> [e-mail] wrote:
> > 
> > For simplicity, the current draft is already very simple, and IMHO
> > it's not clear that continuing to tweak it has a positive return
> > on investment, considering it delays the publication. 
> 
> We should _not_ rush it out.
> 
> The message that I'm getting from people doing maintenance of
> old installed base is that it is not easy for them to make
> an assessment about TLS extension RI.  The spec is from a high
> level view.  For implementations that don't support TLS extensions,
> you can only find out and what it means in terms of code changes
> when you try to implement it--not from that draft.

Hmm... This doesn't seem that hard to work out.

In any case, I'd certainly be willing to add a non-normative appendix
describing the minimal code changes necessary.


> It should _not_ be a question how beautiful the solution is and how well it
> fits into new implementations, but primarily, that it fits equally
> well even the oldest implementations around, and that it is easy
> for them to implement, otherwise we are not going to see the
> widespread adoption that we need.

I'm not sure I buy this: the vast majority of TLS implementations run
one of a small number of stacks (SChannel, OpenSSL, NSS). The pace of
adoption is going to be primarily driven by (1) how fast those stacks
implement this new functionality and (2) the base (very slow) rate at
which people upgrade their stacks [Res03]. Whether or not a stack that
has <1% of the market upgrades only has a very small impact on
how widespread deployment is.

This isn't to say that we shouldn't be concerned with whether
what we do can be incorporated into old systems, but I don't
really agree that easy incorporation into such systems ought
to be our highest design priority.

-Ekr


[Res03] E. Rescorla, "Security Holes... Who cares?", Proceedings of
the 12th USENIX Security Symposium, August 2003.