Skip to main content

Last Call Review of draft-ietf-uta-rfc7525bis-09

Request Review of draft-ietf-uta-rfc7525bis
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-07-11
Requested 2022-05-16
Authors Yaron Sheffer , Peter Saint-Andre , Thomas Fossati
I-D last updated 2022-07-08
Completed reviews Secdir Last Call review of -07 by Benjamin Kaduk (diff)
Artart Last Call review of -09 by Cullen Fluffy Jennings (diff)
Genart Last Call review of -07 by Tim Evens (diff)
Secdir Telechat review of -09 by Benjamin Kaduk (diff)
Tsvart Telechat review of -09 by Magnus Westerlund (diff)
Assignment Reviewer Cullen Fluffy Jennings
State Completed
Request Last Call review on draft-ietf-uta-rfc7525bis by ART Area Review Team Assigned
Posted at
Reviewed revision 09 (document currently at 11)
Result Almost ready
Completed 2022-07-08

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,, 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 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