Re: [Uta] Artart last call review of draft-ietf-uta-rfc7525bis-09

[Peter Saint-Andre <[e-mail]>]

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