On Mon, 21 May 2007, Jeffrey Hutzelman wrote:
...
It seems to me that specs should _not_ explicitly specify which TLS version
to support, and should instead refer to an STD number. Applications don't
generally specify which verisons of IP or TCP to use, and TLS is at a similar
level of abstraction -- except that the situation is not as painful, because
using a different version of IP means you have to use completely different
names, whereas using a different version of TLS does not.
We expect application protocols that require TLS to specify a mandatory-
-to-implement ciphersuite to guarantee interoperability between clients
and servers. How is the TLS version any different? A client that only
supports TLS 1.0 will fail at handshake time if the server only supports
TLS 1.1. Therefore, if interoperability is the goal, requiring support
for a specific version is necessary.
While there are some potential library versioning issues for TLS, the fact
that the protocol has version negotiation built in means the likely result
is everyone will support old versions for longer than we all wish: how
many clients send still send SSLv2-compatible handshake messages, even
when using doing in-protocol upgrade (ala STARTTLS) where both ends are
required to implement TLS?
(This contrasts with the real versioning issues for Unicode libraries,
where the lack of backwards compatibility with the normalization output of
earlier versions has been an issue.)
The TLS/SSL version/cipher-suite negotiation has its own risks, of course.
If an earlier version and/or offered cipher-suite is catastrophically
broken or just Too Weak, then the client cannot safely offer them. So, if
the goal of the MtI requirement is security, then the spec needs to
require a minimum version from servers *and* that clients not offer an
earlier version, no?
Back to your comment, I'm not sure what you mean by "have to use
completely different names". A name in DNS can have both A and AAAA
records, as demonstrated by www.ietf.org. Code using getaddrinfo() may
automatically try both, though the order they are returned in is an
implementation detail. (That it's not clear whether getaddrinfo() is
responsible for ordering them is probably another strike against it on
Keith's list.)
As for calling out a specific version of IP, there was recently a thread
in the discussion around RFC 2821bis (821ter?) regarding whether it should
have some normative wording against sending messages whose envelope sender
("bounce address") can only be reached using IPv6**, as delivery failure
notices might not be returnable. I believe the only conclusions reached
were "don't tie to IP revisions in this doc" and "yuck".
Philip Guenther
Sendmail, Inc.
** That is, where the envelope sender address's domain either has MX
records that point to hosts that only have AAAA records, or which has no
MX or A records but does have one or more AAAA records.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf