On Thu, Sep 04, 2014 at 01:39:15PM +0900, Yutaka OIWA wrote:
> > What you probably want to specify here is ?SHOULD NOT?.
>
> In my opinion, it shall absolutely be "MUST NOT" for
> "generic use cases" for which the document is applicable.
>
> But it's UTA BCP document, and it's very important to
> say "MUST NOT for general applications" here.
[ Repost from tls list earlier today. My cycles for UTA are very
limited, please pardon my jumping in here out of context. Generally
speaking my inclination about improving security is to create
and promote stronger options, without necessarily disabling weaker
options. Even weaker options can be better than having to resort
to cleartext because the minimum standard required to get any
security is too strong or not sufficiently interoperable. ]
I'd like to respond to the UTA draft more broadly.
I am perplexed by the following from the draft's introduction:
The recommendations herein take into consideration the security of
various mechanisms, their technical maturity and interoperability,
and their prevalence in implementations at the time of writing.
These recommendations apply to both TLS and DTLS. TLS 1.3, when it
is standardized and deployed in the field, should resolve the current
vulnerabilities while providing significantly better functionality,
and will very likely obsolete this document.
If the document provides only "general application" guidance, that
does not cover all TLS use-cases, then likely TLS 1.3 will include
features that fall outside the general use-cases, and thus the
document would continue to provide relevant general-case guidelines
even with TLS 1.3 widely deployed.
The introduction then goes on to state:
These are minimum recommendations for the general use of TLS.
Individual specifications may have stricter requirements related to
one or more aspects of the protocol, based on their particular
circumstances. When that is the case, implementers MUST adhere to
those stricter requirements.
What about specifications that might call for less strict requirements?
In section 3.5 I am puzzled by the following text:
If TLS session resumption is used, care ought to be taken to do so
safely. In particular, the resumption information (either session
IDs [RFC5246] or session tickets [RFC5077]) MUST be authenticated and
encrypted to prevent modification or eavesdropping by an attacker.
I am entirely unaware of the practice of encryption and authentication
of session IDs. What is this about? Even session tickets are not
"authenticated", rather they might be vended by a server as part
of an authenticated session. Returning to session IDs, these are just
server-side nonces, what does it mean that they should be authenticated,
and are they in fact (with TLS <= 1.2) even encrypted?
The recommendations for session ticket key rotation are I think
too meek. They seem to be predicated on the notion that such
rotation is some sort of externally managed task, automated via
something akin to a cron job, where weekly rotation is about the
right granularity. I'd like to suggest that session ticket key
rotation SHOULD be a fully automated intrinsic component of the
server application and server keys should not last much longer than
sessions, a matter of minutes or hours not days. Key rotation
should happen transparently while the application is running,
without requiring restarts, and ideally without ever explicitly
writing keys to persistent storage. Yes, this would be an aspirational
part of the BCP, as few applications have this capability at present.
For section 4.1, in light of the scope of section 4, the simplest
solution is to suppress NULL cipher suites when any non-NULL cipher
suites are configured. This avoids accidents, without prohibiting
deliberate NULL-only configurations.
For SMTP, RC4-SHA and RC4-MD5 is the only cipher suites that
interoperate with Exchange 2003 servers, which are still handling
mail for a small, but non-negligible number of domains. In fact
these same servers only work if RC4 is among the first 64 cipher
suites sent by the client, but with TLS 1.2, and all its new cipher
suites that's often not the case. Are we really better off
prohibiting RC4? Would it not suffice for servers to stop preferring
RC4 (as was common with many HTTPS servers), and then stronger
choices are automatically selected except with sites that only
support RC4?
It would be more helpful (and more interoperable) to specify a
short list of "must implement" cipher suites, which SHOULD be
preferred over the legacy ones, than to try to prohibit weaker
cipher suites that are required for interoperability with older
systems. Thus also MUST NOT or SHOULD NOT with EXPORT and 3DES
cipher suites is less useful than promoting more secure alternatives.
The draft in fact recommends four best practice cipher suites which
should be preferred over the NOT RECOMMENDED weaker options.
In section 6.1, the draft refers hostname verification to 6125,
but 6125 contains little useful guidance for application protocols
in which the server hostname is obtained indirectly via typically
unauthenticated DNS SRV or MX records. In such protocols, the
server name is not a viable reference identity. Some mention of
the issue may be appropriate.
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12#section-1.3.2
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
