Dear UTA contributors, Ad git/github: Duly noted. Thanks for your patience and pointing this out.
Sorry for my delayed reply to this thread; I'm extremely busy at the
moment - as I'm sure most of you are. As promised a few remarks on typos
phrasing/wording and clarification which I have not addressed in my
previous e-mail to this list.
1. (Introduction):
- [...] and their prevalence in implementatios at the time of writing.
^^^^^^^^^^^^^^
typo
- Individual specifications may have stricter requirements related to
one or more aspects of the protocol, and based on their particular
circumstances.
should we rephrase that? e.g. "based on their particular security
requirements".
- [...] When that is the case, implementers MUST adhere to those
^^^^^^^^^^^^
typo
3.2 (Fallback to SSL):
In my opinion this should be a MUST. Clients MUST not fall back to
SSLv3. This is a BCP, no reason to have this security issue stated as
SHOULD NOT. I'm aware that this might break compatibility with legacy
software.
3.4 (Cipher Suites):
- Rationale: Although these cipher suites are not actively subject to
breakage, their useful life is short enough that stronger cipher suites
are desirable.
maybe change the wording of 'their useful life' to e.g. 'their lifespan'.
- Rationale: Although the useful life of such cipher suites is unknown,
it is probably at least several years [...]
I'd also go with 'lifespan' there.
- Given the foregoing considerations [...]
foregone instead of foregoing(?).
3.5. (Public Key Length):
- The most common workaround for these systems is to prefer the "ECDHE"
family of cipher suites instead of the "DH" family, then use longer keys.
I simply do not understand the sentence. Which keys are referred to exactly?
- [...] and might be sufficient for at least the next 10 years.
I'd simply remove the estimate on the lifespan of 2k keys. No one can
say for sure and there's really no reason to estimate.
- Note: The foregoing recommendations are preliminary [...]
foregone instead of foregoing(?).
3.7 (Session resumption):
- ticket keys MUST be changed regularly, e.g. once every week, so as not
to negate the effect of forward secrecy.
That's a bit of nitpicking but in this sentence it's "effect of forward
secrecy" in the next sentence "benefits of forward secrecy" - I'd go for
the latter in both sentences.
4.1 (Cipher Suite Negotiation Details):
- Servers SHOULD prefer this cipher suite (or a similar but stronger
one) whenever it is proposed, even if it is not the first proposal.
"a similar but stronger one" is very vague. I'd either remove it or give
examples of possible cipher suites to be used.
4.2 (Alternative Cipher suites):
- [...] moreover, 1024 bits DH parameters are generally considered
insufficient at this time. [...]
I'd change "bits" to "bit" - "1024 bit DH parameters".
6.2 (Forward Secrecy):
- Should the attacker be able to obtain these long-term keys at some
point later in the future [...]
I'd change this to "at some point later in time".
- Unfortunately, many TLS/DTLS cipher suites were defined that do not
enable PFS, e.g. TLS_RSA_WITH_AES_256_CBC_SHA256. [...]
Would rephrase as "that do not feature PFS". That's not optional in the
case of RSA key transport, it's just not possible the way it's spec'd in
TLS (there is a paper on ephemeral RSA, but I've never gotten around to
read it).
Thanks,
Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
