"Stephen Farrell" <stephen.farr...@cs.tcd.ie>: > (1) Why experimental? Wouldn't this be better as info > and documented as "here's a spec for a thing that's > widely deployed." I fear we may get questions like > "what's the experiment?", "where's this going in > future?" if this aims for experimental, and info may > avoid that esp if we really want people to move to > TLS1.3. I also didn't see list discussion about what > kind of RFC to aim for, but maybe it was discussed at > a meeting or interim? (Apologies if I missed that in > my scan of the list.)
I'm myself torn between "Experimental" and "Informational" (certainly not "Historic" because the spec has not been superseded by a more recent one and is not obsolete for any other reason [ https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow manage to complete TLS 1.3 standardization before this). Taking into account how False Start is actually deployed (and taking into account that we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our I-D is cited in research papers on TLS, "Experimental" sounds right to me: the spec really is part of a research and development effort [ https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational" wouldn't be wrong either. > (2) The write up and some mail list traffic and AGL's > bloggy thing all refer to NPN, but there's no mention of > NPN or ALPN in the draft. What's up with that? (Not > saying that needs to be explained, but I wondered.) The NPN dependency was a design decision for one implementation, but it's not common to clients using False Start. For interoperability, you always have to consider how to deal with what you expect to be deployed *currently* (and NPN support certainly is one good indicator for False Start tolerance, if you don't mind tons of false negatives), but I wouldn't see much value in compiling the minutae of that in this kind of document: it'll go stale quickly. > (3) Why is there no description of the reasons for all > the MUST only use whitelisted <foo> and for the choices > that are whitelisted? Wouldn't omitting that tend to > lead people to use this more badly? Well, I tried to capture the general reasoning in the spec -- but not the detailed reasons for the specific choices suggested, because that again would just go stale quickly. In particular, I think this is an important observation in the I-D: "If heuristically a small list of cipher suites and a single protocol version is found to be sufficient for the majority of TLS handshakes in practice, it could make sense to forego False Start for any handshake that does not match this expected pattern, even if there is no concrete reason to assume a cryptographic weakness." So the whitelists should have algorithms that are actually used in practice and that don't have critical weaknesses, but why exactly those particular algorithms happen to get used in practice is mostly out of scope here. Bodo > That could be done > with some explanatory text and using some of the > references below maybe. Or, if we don't really want new > folks to implement this (do we?) then just saying that > might mean it's ok to not explain the "why." (And then > you could also address #1 above then by issuing this > as an historic RFC too if you wanted.)
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
