[Emu] Re: Call for adoption: draft-reddy-emu-pqc-eap-tls-03 (Ends 2026-05-12)

[tirumal reddy <[e-mail]>]

On Wed, 29 Apr 2026 at 11:53, Eliot Lear <[e-mail]> wrote:

> Hi Tiru
> On 29.04.2026 08:01, tirumal reddy wrote:
>
> On Tue, 28 Apr 2026 at 20:43, Eliot Lear <[e-mail]> wrote:
>
>> Tiru,
>>
>> The reason I asked both questions is that EAP-TLS in particular is
>> implemented on some 802.15.4 networks that can be lossy, low bandwidth,
>> with low MTU.  I think it's a good idea to have at least some feel for what
>> we're in for with very large keys/certs.
>>
> Valid point.  The handshake size impact in constrained networks like
> 802.15.4 comes from both large PQC certificates and large PQC KEM public
> keys, particularly with PQ/T hybrid schemes. The EST pre-fetching
> optimization discussed in this draft and the optimizations discussed in
> ietf-uta-pqc-app, including certificate chain optimization and optimizing
> ClientHello for Hybrid Key Exchange in TLS Handshake would help reduce this
> overhead. Implementation experience in these environments would be helpful.
>
> Ok, I see what your intent is.  *I *don't think the draft is properly
> structured.  There are numerous ways to get certificates into devices, and
> EST is only one of them.  In fact, specifically with TEAP certificates are
> delivered via TEAP.  The draft should focus on changes required (if any) to
> deliver PQC and to reduce the hello/handshake sizes.  How the intermediate
> certificates are configured is separate.  We are already starting work on
> TEAPv2.  There is already an implementation in hostap.  It would not be
> difficult to add the same level of functionality there.  However, I am not
> yet convinced that this is the correct optimization, and would prefer that
> we give just a bit more thought... yeah, to PLANTS to see if we can adopt
> that work in some way here. The challenge is the circular connectivity
> dependency, but if you're talking about pre-fetching here, that might
> provide alternatives there.
>
The draft is structured around three distinct concerns: PQC key exchange
for long-term confidentiality, PQ authentication, and handshake size
reduction. The EST integration in Section 5 is one proposed optimization
for reducing handshake overhead by pre-fetching intermediate certificates.
I agree that there are other mechanisms for certificate delivery.
The circular connectivity dependency challenge in PLANTS could be addressed
using EST, where the EST server acts as the transparency service, and
devices periodically fetch updated landmarks from it similar to how
browsers periodically fetch updated landmarks from the transparency service
in WebPKI. I am open to discussing PLANTS integration in the draft if there
is interest from the WG.

Cheers,
-Tiru

Eliot
>
>
> -Tiru
>
>> Eliot
>> On 28.04.2026 15:27, tirumal reddy wrote:
>>
>> On Tue, 28 Apr 2026 at 17:12, Eliot Lear <[e-mail]> wrote:
>>
>>> Hi Peter and colleagues,
>>>
>>> Has anyone created a test implementation with hostap to see if there are
>>> any ill effects from large key sizes?  Also, I would like to understand the
>>> relationship of this work, if any, to PLANTS.
>>>
>> No, the draft does not discuss merkle-tree certificates. PLANTS targets
>> WebPKI. While Merkle-tree certificates would help reduce PQC certificate
>> sizes in EAP deployments, their applicability in this context requires
>> further analysis.
>>
>> -Tiru
>>
>>> Eliot
>>> On 28.04.2026 12:33, Peter Yee wrote:
>>>
>>> I've issued a WG call for adoption on draft-reddy-emu-pqc-eap-tls and would really like to get opinions on whether this work ought to be adopted. The document is fairly short and the only normative section covers additions to EST (RFC 7030) for optimization purposes by allowing the retrieval of intermediate portions of EAP client and EAP server certificate chains to obviate needing to pass them in-band in the TLS handshake. That part runs 2 pages.
>>>
>>> Please take a look and send your comments for or against adoption to the mailing list by May 12th.
>>>
>>> Thank you in advance.
>>>
>>> 		-Peter
>>>
>>> On 4/28/26, 11:24 AM, "Peter Yee via Datatracker" <[e-mail]> <[e-mail]> wrote:
>>>
>>> This message starts a emu WG Call for Adoption of:
>>> draft-reddy-emu-pqc-eap-tls-03
>>>
>>> This Working Group Call for Adoption ends on 2026-05-12
>>>
>>> Abstract:
>>> This document proposes enhancements to TLS-based EAP methods,
>>> including the Extensible Authentication Protocol with Transport Layer
>>> Security (EAP-TLS), EAP Tunneled TLS (EAP-TTLS), Protected EAP
>>> (PEAP), and EAP Tunnel Method (TEAP), to incorporate post-quantum
>>> cryptographic mechanisms. It also addresses challenges related to
>>> large certificate sizes and long certificate chains, as identified in
>>> [RFC9191], and provides recommendations for integrating PQC
>>> algorithms into TLS-based EAP deployments.
>>>
>>> Please reply to this message and indicate whether or not you support adoption
>>> of this Internet-Draft by the emu WG. Comments to explain your preference are
>>> greatly appreciated. Please reply to all recipients of this message and
>>> include this message in your response.
>>>
>>> Authors, and WG participants in general, are reminded of the Intellectual
>>> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
>>> Appropriate IPR disclosures required for full conformance with the provisions
>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>>> Sanctions available for application to violators of IETF IPR Policy can be
>>> found at [3].
>>>
>>> Thank you.
>>> [1] https://datatracker.ietf.org/doc/bcp78/
>>> [2] https://datatracker.ietf.org/doc/bcp79/
>>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>>
>>> The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-reddy-emu-pqc-eap-tls/
>>>
>>> There is also an HTML version available at:https://www.ietf.org/archive/id/draft-reddy-emu-pqc-eap-tls-03.html
>>>
>>> A diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-reddy-emu-pqc-eap-tls-03
>>>
>>>
>>>
>>> _______________________________________________
>>> Emu mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> Emu mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>