Having promised a review before August 18, I have three issues I'd like to talk about. But first, thanks for keeping pushing on this. I am not sure it will ever see wide adoption, but we'll surely never find out if we don't try.
## Don't stand out I think the requirement that the browser check the CT log and perform DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I don't expect most browsers to do that most times. Am I missing something? ## CDN integration > If N multiple domains on a CDN are acceptable fronts, then we may > want some way to indicate this without publishing and maintaining N > separate tokens. Those multiple domains will not share TLS keys (or will be under a TLS wildcard), so delegation to a certificate is enough to cover this. I think you can just cut this paragraph, but maybe I don't know something about some sort of CDN? ## Security considerations: DDoS In section 6, I'm glad to see analysis vs the ddos requirements in 2.3. I'm not sure I agree with the quick result: 1) The forwarding server can be used as a reflector. Under some circumstances it should back off. 2) Under CPU load, the forwarding server will presumably start refusing early data (especially early data with TCP Fast Open!). Is it necessary to say anything more here? Or is the ordinary behavior of flaky early data sufficient? Particularly: what should clients do when early data is refused? Try again with this in the main data section? Give up? -Brian _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
