Michael D'Errico <mike-l...@pobox.com> wrote:
> 
> Since RFC 8446 obsoletes RFC 5246, this is a serious problem.
> 
> How is this supposed to work?   Sorry but I did not follow the
> development of TLS 1.3.  I felt that I was unwelcome in this
> group by some of the "angry cryptographers" as I call them.

The "Obsoletes" Markers used in TLS documents (rfc4346, rfc5246, rfc8446)
are pure crypto-political bullshit, they are completely non-sensical
with respect to the Editorial meaning of "Obsolete:" in the RFC
document series, as it was explained in rfc2223:

   Obsoletes

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

IPv6 specification(s) can not possibly obsolete IPv4 specifiation(s)
HTTP/2 spec does not obsolete HTTP/1.1 spec (and does not try to)

Example for *correct* obsoletion:

If you want to implement the Simple Mail Transfer Protocol (SMTP),
it will be sufficient that you only ever read and refer to rfc5321
and _never_ look at rfc2821 nor rfc821 at all -- and still can
expect to your implementation of rfc5321 to interop fine with
older implementations there were created based on rfc821 or rfc2821.


The same is impossible for TLSv1.1 (rfc4346), TLSv1.2 (rfc5246)
and TLSv1.3 (rfc8446). An implementor reading only rfc8446 will
be completely unable to interop with TLSv1.0, TLSv1.1 and TLSv1.2
implementations -- and I am not even sure whether TLSv1.3 can
be implemented with rfc8446 alone and never looking at rfc5246.


-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to