Re: [TLS] TLS process thread

[Klaus Hartke <[e-mail]>]

Trevor Perrin wrote:
> As Nikos and Paul pointed out, the charter doesn't mention 5246.  It
> mentions minimizing changes, but only as one goal among several, and
> only "gratuitous" changes.
>
> I think minimizing changes is one of many goals in tension with others
> (minimizing diffs vs minimizing complexity / adding features;
> handshake encryption vs handshake latency; new features vs. ease of
> analysis; merging layers vs. modularity; etc.)  Instead of presuming
> the answer to any of these, or tackling them in isolation, it makes
> more sense to explore such a complex design space through different
> proposals.

To me, it seems a critical question is whether a handshake initiated
by a (D)TLS vNext client to an existing (D)TLS 1.x server is expected
to succeed (without extra round trips, etc.) or not.

If yes, then vNext = 1.3 and there's only so much that can actually be
changed without breaking backwards compatibility. For example (if I
understand it correctly), removing compression basically means that
compression must not be negotiated, not that the
ClientHello.compression_methods field can be removed. Any significant
changes will need to jump through some hoops to remain backwards
compatible, like for example the encapsulation of TLS records in
ClientHello extensions (ugh). I wouldn't be surprised if most things
that can be done could even be done if vNext = 1.2bis.

If no, then vNext = 2.0 really and there's no reason why it shouldn't
be a clean reinvention of Internet transport layer security that
doesn't have to look like TLS 1.2 but nevertheless stands on the
shoulders of the 15+ years of SSL/TLS 1.x experience.

Klaus