On Fri, Mar 06, 2020 at 08:35:07AM +1100, Martin Thomson wrote:
> On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> > .... unless both parties agree. It takes two to agree.
>
> RFC 8446 says:
> Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
> a ticket allows passive observers to correlate different connections.
>
> Are you arguing that there are exceptions that justify not respecting
> the "SHOULD NOT", or that the "SHOULD NOT" is too strong? Because no
> one is violating any specifications when they reuse tickets, just
> recommendations.
Good question.
RFC2119 is very clear about what "SHOULD NOT" means, and that is
different from "MUST NOT":
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
> (In other words, I don't understand the strength and vehemence of the
> arguments being used.)
Well, suppose the RFC said PFS is a SHOULD, not a MUST, but we became
certain that PFS should be REQUIRED (same as MUST). We could start
rejecting proposals that preclude that change to the RFC, and we could
go update the RFC.
If we liken ticket non-reuse to PFS, then the vehemence of opposition
we're seeing to any ticket reuse makes sense even though RFC8446 says
"SHOULD NOT" reuse tickets rather than "MUST NOT".
It is fair to boil this down to just a question of how strongly we do /
should feel about ticket reuse.
It would not be fair to exclude SMTP as an application from
consideration of whether ticket reuse ever makes sense. SMTP does not
use early data, and SMTP between MTAs does not present the kind of
client tracking concerns that HTTP user-agents do. SMTP is precisely
the sort of "particular circumstance" that RFC2119's description of
"SHOULD NOT" is about.
Nico
--
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
