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

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2009 12:48:37 +0200

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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 13:02:06 +0200

On 29 jul 2009, at 12:48, Lars Eggert wrote:

> 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.

First of all, I'd like to see some operational experience with TCP-AO.  
Don't throw away your old shoes until you know whether the new ones fit.

Second, it's not like TCP-MD5 isn't being used. As such, "historic"  
wouldn't apply. "Deprecated", maybe.

Third, why is it exactly that we can't simply move from MD5 to IPsec  
to protect BGP sessions??

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2009 13:13:56 +0200

Hi,

> Don't throw away your old shoes until you know whether the new ones  

so are you saying we should *neither* obsolete TCP-MD5 *nor* move it  
to Historic?

> wouldn't apply. "Deprecated", maybe.

There is no way to express this for an RFC. There are two options: "A  
obsoletes B", which is indicated in the document header, and "A is  
reclassified as Historic" in the RFC Editor database.

> to protect BGP sessions??

I refer you to the extensive discussion that happened when draft- 
bonica was first presented to the WG, which I have no interest in  
rehashing.

Lars

---

From: David Borman <[email-masked]>
Date: Wed, 29 Jul 2009 13:26:10 +0200

> obsoleted by TCP-AO and/or if it should be reclassified as Historic.

1) TCP-AO should obsolete TCP-MD5.  That was the whole point of this  
exercise of creating TCP-AO.

2) Whether or not TCP-MD5 is moved to historic is a separate issue.   
If people are concerned about marking it historic at this point in  
time, then don't.  We can always come back in a year or two after TCP- 
AO has been deployed, and then mark TCP-MD5 historic.

As long as it is clear that TCP-AO obsoletes TCP-MD5, then I don't  
think it matters that much if/when TCP-MD5 is moved to historic.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jul 2009 04:44:54 -0700

Iljitsch van Beijnum wrote:
> Third, why is it exactly that we can't simply move from MD5 to IPsec to
> protect BGP sessions??

This is addressed in the TCP-AO document:

- ---

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-AO is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case to support some routing protocols, or in cases
   where keys need to be tightly coordinated with individual transport
   sessions [Be07].

- ---

   This document differs from an IPsec/IKE solution in that TCP-AO as
   follows [RFC4301][RFC4306]:

   o  TCP-AO does not support dynamic parameter negotiation.

   o  TCP-AO uses TCP's socket pair (source address, destination
      address, source port, destination port) as a security parameter
      index, rather than using a separate field as an index (IPsec's
      SPI).

   o  TCP-AO forces a change of computed MACs when a connection
      restarts, even when reusing a TCP socket pair (IP addresses and
      port numbers) [Be07].

   o  TCP-AO does not support encryption.

   o  TCP-AO does not authenticate ICMP messages (some ICMP messages may
      be authenticated when using IPsec, depending on the
      configuration).

- ---

See also the Security Considerations section.