[tcpm] status of TCP-MD5 after TCP-AO publication

[Lars Eggert <[e-mail]>]

Hi,

at the meeting, the question came up which status TCP-MD5 should have  
after TCP-AO is published. Specifically, whether it should be  
obsoleted by TCP-AO and/or if it should be reclassified as Historic. A  
related issue I came across while trying to form an opinion of the  
former issue is if the publication of TCP-AO means that we can lift  
the Standards Variance for TCP-MD5 introduced by RFC4728. (I'm CC'ing  
the IESG because of this latter point, because that Standards Variance  
came from the SEC and RTG areas.)

I looked at some other cases related to MD5 to see how we handled  
obsoleting or making things Historic in the past, with regards to TCP- 
MD5.

Example 1 is RFC2537 "RSA/MD5 KEYs and SIGs in the Domain Name System  
(DNS)", which is obsoleted by RFC3110 "RSA/SHA-1 SIGs and RSA KEYs in  
the Domain Name System (DNS)", but *not* moved to Historic. (Note that  
this change replaces MD5 by SHA1, i.e., isn't wire-compatible, similar  
to how moving from TCP-MD5 to TCP-AO isn't
wire-compatible, so that is apparently OK.)

Example 2 is RFC2082, which is also obsoleted (but not made Historic)  
by RFC4822 and also replaces MD5 with another algorithm that affects  
wire-compatibility.

So there is precedent for TCP-AO to obsolete TCP-MD5, which is also  
what the -AO draft currently contains.

Now, on the topic of moving TCP-MD5 to Historic, RFC2026 says that  
even when one spec obsoletes another, there may be cases where the  
obsoleted spec is kept at its original level (i.e., not made Historic)  
to honor the requirements of an installed base, if there is one. (See  
PS below for the actual text.) I believe that TCP-MD5 will still  
remain widely deployed initially even after TCP-AO is published, and  
so moving it to Historic is not something we should aim for at this  
time. Agreed?

Finally, on whether the publication of TCP-AO means that we can lift  
the Standards Variance for TCP-MD5 introduced by RFC4728, I'd be  
really interested in hearing your feedback.

Thanks,
Lars

PS: To save you all some scrolling, RFC2026 says this about Historic  
RFCs:

    4.2.4  Historic

    A specification that has been superseded by a more recent
    specification or is for any other reason considered to be obsolete  
is
    assigned to the "Historic" level.  (Purists have suggested that the
    word should be "Historical"; however, at this point the use of
    "Historic" is historical.)

and later

    6.3  Revising a Standard

    A new version of an established Internet Standard must progress
    through the full Internet standardization process as if it were a
    completely new specification.  Once the new version has reached the
    Standard level, it will usually replace the previous version, which
    will be moved to Historic status.  However, in some cases both
    versions may remain as Internet Standards to honor the requirements
    of an installed base.  In this situation, the relationship between
    the previous and the new versions must be explicitly stated in the
    text of the new version or in another appropriate document (e.g., an
    Applicability Statement; see section 3.2).

    6.4  Retiring a Standard

    As the technology changes and matures, it is possible for a new
    Standard specification to be so clearly superior technically that  
one
    or more existing standards track specifications for the same  
function
    should be retired.  In this case, or when it is felt for some other
    reason that an existing standards track specification should be
    retired, the IESG shall approve a change of status of the old
    specification(s) to Historic.  This recommendation shall be issued
    with the same Last-Call and notification procedures used for any
    other standards action.  A request to retire an existing standard  
can
    originate from a Working Group, an Area Director or some other
    interested party.