Hi Mikkel,
I suspect I'm misunderstanding something, because it sounds to me like you
are supporting a dedicated "quic_early_data" extension to help decouple QUIC
from TLS. More inline...
On Thu, Jan 07, 2021 at 04:14:05PM +0100, Mikkel Fahnøe Jørgensen wrote:
>
>
> > On 7 Jan 2021, at 07.26,
For what it's worth,
On Thu, Jan 7, 2021 at 9:15 AM Mikkel Fahnøe Jørgensen
wrote:
>
>
> On 7 Jan 2021, at 07.26, Benjamin Kaduk wrote:
>
> It seems like only QUIC internals would have to change, not TLS internals?
>
> My expectation is roughly that, if we were to compare the work needed to go
https://www.nsa.gov/News-Features/Feature-Stories/Article-View/Article/2462345/nsa-releases-eliminating-obsolete-transport-layer-security-tls-protocol-configu/
may be of interest.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/
Hi Martin,
Thanks for the quick response.
On 1/8/21 10:25 AM, Martin Thomson wrote:
> On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
>> Thanks for pointing this out. I think Ben also mentioned this in his
>> review. I am not sure if it is necessary to add the type-code to the
>> label when i
On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
> Thanks for pointing this out. I think Ben also mentioned this in his
> review. I am not sure if it is necessary to add the type-code to the
> label when it is already part of the label string as 'EAP_TLS'. Other
> TLS based EAP methods should
Hi Ben,
On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be
