ietf
[Top] [All Lists]

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

2007-05-21 22:53:32
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf