Hi Cullen, thanks for the review and my apologies about the delayed
reply. Comments inline.
On 7/8/22 8:18 AM, Cullen Jennings via Datatracker wrote:
Reviewer: Cullen Jennings
Review result: Almost Ready
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.
Well, RFC 7525 is referenced by 100+ RFCs, but that might be pro forma.
The question is whether implementers and service providers are paying
attention, and we don't have any data on that. But we definitely agree
on the goal.
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.
The immediately prior paragraph does have a forward pointer to the
applicability section.
I do think this statement is accurate:
The recommendations herein take into consideration the security of
various mechanisms, their technical maturity and interoperability,
and their prevalence in implementations at the time of writing.
Thomas Fossati can vouch for the "prevalence" claim better than I can,
but we have definitely looked at which features are actually available
in implementations as opposed to just wishing those features were
supported. One example of many that I find in my email history is
extended master secret (RFC 7627).
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.
Good point. This is all in RFC 8996, but a brief summary might be helpful.
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
Hmm. Our intent with this document is certainly not to create protocols.
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.
We could say "you should strongly consider using ESNI when available if
appropriate for your situation and taking into account all relevant
considerations described in the ESNI spec" but it seems that the ESNI
spec ought to be the one that covers this topic in depth.
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).
This document is all about deployment in production to provide services
over the Internet. Don't we already have some wording to this effect?
Nevertheless, this document does not discourage software from
implementing NULL cipher suites, since they can be useful for
testing and debugging.
What would you change there?
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".
I see your point. we'll look into wordsmithing this.
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 authors will discuss this and reply again.
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.
Huh, I thought we had text along those lines. We'll check into it.
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.
We'll discuss among the authors once Yaron is back online.
If my whole machine has been root'd - PFS does not help much.
Naturally. :-)
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.
Another topic for the authors to discuss and bring back to this thread.
I think
the drat should also discuss curves that SHOULD NOT be used.
That could be a long list...
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?
That's possible, let us have a think about it.
I don't think BCP is the appropriate status for this. I think it should be PS.
I strongly disagree, given the history of this document in RFC 7525 and
how it is referenced by 100+ RFCs.
Peter
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
