> The (mis)use of long-term STEKs is not particularly special among such
> practices.
This may be true, but that still doesn’t make it a good idea. We should
probably do *something* about this. J
> The protocol design should avoid setting traps for the unwary.
> If libraries implement "long-term" STEKs, that's a library bug, not a
> protocol issue.
Seems to me that both points are valid and not mutually exclusive. Why don’t we
capture this discussion in the RFC itself? We often provide guidance/alerts for
implementers. Why should this be different? Such a warning would presumably
prevent it from being a trap for the unwary (or unweary, depending on how much
rest they’ve gotten) without requiring a change to the protocol itself.
We could even go so far as to add a “SHOULD NOT” around using STEKs that are
long-lived? That would provide a strong hint to implementers but leave
flexibility for those who need different behavior and understand the risks?
Cheers,
Tim
—
Tim Jackson | Product Security Architect | MobileIron, Inc.
On 5/3/17, 11:29 AM, "Nico Williams" <n...@cryptonector.com> wrote:
On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote:
> > On May 3, 2017, at 12:01 PM, Salz, Rich <rs...@akamai.com> wrote:
> > The protocol design should avoid setting traps for the unwary.
>
> No, that responsibility falls on libraries. STEKs are not a trap for the
> unweary. Libraries that support static session tickets by default can be
> viewed as such a trap. So the onus to fix this is on us (OpenSSL team)
> not the TLS protocol.
A big +1 to this.
I think it would terrible if we couldn't have resumption at all because
one common implementation mishandles old key deletion.
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
