To have impact on actually deployments, this documents need to be clear in explaining why it makes the recommendations it makes. For the most part it does do this but I am reviewing it from the point of view of will it be compelling in helping improve security or will people just ignore it. 

Section 1, para that starts "The recommendations herein take into consideration"... I think this paragraph needs to be scoped to the scope in the applicability section because otherwise it seems unlikely to be true. I do not think people looked at prevalence in implementations of embedded systems TLS - if they did, that should be document. It would be good to actually document what was found with HTTPS / Web numbers. Overall, I think the introduction should be scope the work along lines of applicability section. 

On the "No TLS 1.1" ... of course I agree with this but the rational is not very compelling for people current running this. I think it would really help improve getting rid of this if people pointed out that 1.1 only had only SHA1 and the issues with that. These issues have been made worse by the crypto community developing very high speed hardware for SHA like hashes. 

Section 3.4 - the information in this section is very useful but seems like it should be put in it's own RFC that updates TLS 1.3 

On ESNI in section 3.7. My view is the statement "this information leak is closed by use of TLS Encrypted Client Hello." is false. The traffic patters to most websites along with IP even when fronted very often reveal exactly that information. Often the unencrypted OSCP data on port 80 promptly following the ESNI packet reveals more than one would hope. I think there should be clear discussion about how using this causes schools in some jurisdictions to be legally required to have to install monitoring software on computers owned and administered by the student and how this is really bad for privacy. There are clear cases where ESNI makes sense, but there are others where the IETF in trying to help privacy, is actually making the situation worse. 

Section 4.1 

No NULL. I think this should be scoped to no NULL by default and no NULL in production but that NULL MAY be used in testing. (other parts of the draft sugest that is ok in testing). Let me explain why I think this. If you can't use NULL in testing, what people often do is form an alternative channel where they report all the encrypted data over a channel meant for metrics or logging. Now if a law enforcement ask for that channel to be used to get data off a production system, the operator clearly has the technical capability to do it and it is much harder to say no that if the technical capability did not exist. While one can argue that the LE could ask for a null cipher, that is at least easily observable and generally would impact many users not just the target and can also be used to to object to a court order. I think the argument that production servers will accidentally enable NULL is statically less likely than production servers will accidentally publish their private key on the web.  

The "SHOULD NOT negotiate cipher suites based on RSA" could use a bit or word smithing here. What you mean is should not do things that do not have PFS but use of RSA (along with a PFS scheme) is fine. This made my head explode when I first read it. I think the intent is fine but that the current words are wrong - I would strongly argue that "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" is a crypto suited "based on RSA".

Given the requirements for crypto agility, I think this there should be at least one MTI algorithm that does not rely on EC. Pinning all your hopes on a single algorithm surely is not the best security advice the IETF can provide. If a EC did have a problem, clearly we would want something already build and deployed that we could switch too. 

The draft does not say MUST not use SHA1 (other than in certs) but I think you should provide clear guidance on if this is a MUST not or SHOULD not and why. (referring to the depreciation documents would be fine). This is one of the issues that often comes up when trying to make performance trade offs and it seem weird, given the rest of the advice in this draft, that this is missing. 

On the topic of forward security ... this draft does not really provide much information about the gains of doing this. Yes, I understand but you are trying to convince others. Many people argue for short lived single transaction HTTPS flows that are common in reporting metrics, this does not buy you much and most the compromises that would reveal a session key would like still end up revealing all the info. I'm not arguing you should not have PFS, I am trying to say that this document is not very convincing on the cases that PFS helps in and the cases it does not. The draft would be improved by a section that discussed the practical attacks this protects from and the ones that it does not. If my whole machine has been root'd - PFS does not help much. 


In section 4.2.1, the draft should provide more information about why it recommends the two curves it recommends. I do not see how we get interoperability by putting theses at a SHOULD level instead of a MUST. I think the drat should also discuss curves that SHOULD NOT be used. 


End of section 4.5. For RSA certs it has MUST be 2048 bit. This seems right for 112 bit security min which seems fine but given how many other places in the spec we add a SHOULD for 128 bit security, would it make sense to add a SHOULD do 3072 bit RSA?


I don't think BCP is the appropriate status for this. I think it should be PS. It explicitly says that is not trying to change existent advice in existing RFC and theses will need other RFC to "modernize" them. I note that www.google.com, www.apple.com, www.mozialla.org all offer TLS 1.0 and 1.1 when I checked from Vancouver on July 8. Please note I did a total half ass job of checking so if I am just wrong about this, please correct me. Theses people are not clueless about TLS and there is significant down side that is not discussed here. I have seen the issues that come up when Cisco turned off TLS 1.0 and 1.1for www.cisco.com. The authors of protocol version X+1 tend to believe that turning off all versions before X is the right thing to do so people can get the benefits of all the new shiny stuff in X+1, but in many case the test and review cycle shows that a slower roll out is needed. I see no evidence of any discussion of how that will work out for things that use HTTP but are not browsers.