[TLS] Re: Review of draft-ietf-tls-extended-key-update-13

[tirumal reddy <[e-mail]>]

Hi Ilari,

EKU is not something a TLS stack would enable transparently. It targets
long-lived sessions and needs explicit configuration, including a
policy for when to trigger it (for example, at a fixed interval or
after a certain amount of data). That configuration may be done by the
operator, to get PCS for all applications on a device, or by an
application that needs it. In the first case the application may not
be aware of EKU, which favours option 1, as in the current draft.

To address the risk of an application silently getting no PCS for
exported keying material, implementations can warn when the legacy
exporter is used on a connection where EKU was negotiated.

That said, I do not think option 2 has worse security properties.
Applications that do not use exported keying material are not affected
by option 2, and enabling EKU requires explicit configuration under
both options. Applications that use exported keying material need to
use the new exporter interface to get PCS under either option, so
option 2 does not tie the application any closer to the TLS stack.

Thanks,
-Tiru


On Tue, 29 Sept 2026 at 22:03, Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Sep 29, 2026 at 05:56:21PM +0530, tirumal reddy wrote:
> >
> > The draft discusses option 1. Both options work for an application that
> > wants PCS and uses TLS exporter: it enables EKU and use the new exporter
> > interface.
> >
> > Option 1 has a drawback that an application may, by mistake, continue
> > to use the legacy exporter and silently get no PCS for exported keying
> > material.
>
> This is unlikely to be a mistake, but one of the endpoint applications
> just does not support EKU.
>
>
> > With option 2, any use of the legacy exporter fails, so the mistake is
> > caught early. This does not affect existing applications, since none of
> > them negotiate EKU today. It also removes the need for a
> > separate initial exporter secret, which simplifies the draft.
>
> Option 2 does not catch the mistake. If one of the endpoints does not
> enable EKU, it will not be used at all, and the other endpoint still
> has to decide if to proceed or abort.
>
> How long you think it will take until enough application instances are
> updated? One still sometimes sees servers or clients that do not
> support secure renegotiation, despite the RFC being over 16 years old,
> and being very simple TLS-only change.
>
>
> The security properties are strictly worse.
>
> - Applications that do no use exported keying material get no PCS unless
>   applications at both ends are updated.
>
> - Applications that do use exported keying material need applications
>   at both ends updated anyway to get PCS.
>
>
> And then, option 2 ties application very close to TLS stack, so the
> application attack surface (likely much larger) gets mixed in to the
> TLS attack surface. This makes compromise much more likely.
>
>
>
>
> -Ilari
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>