Hi David,
if you're on it, maybe it's worth to consider my question from January
2021 as well.
> If the client follows this guide, it falls-back to use a full handshake.
> If the client doesn't follow this (maybe, the client is not aware of RFC
7627), the server SHOULD aborts.
> Why SHOULD the
I uploaded a draft for the IANA assignments for compressed code points for
the NIST curves:
https://datatracker.ietf.org/doc/draft-cem-compressed-curves/
In it, I elected to not pursue the format to encode the types of keys
specified in draft-jivsov-ecc-compact
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
Filename
Hi all,
In diagnosing an interop issue, I noticed RFC 7627 did not describe the
correct server behavior for EMS very well. Seemingly as a result, some
server implementation has gotten this wrong. I'd like to fix this in the
spec so this doesn't happen again. I think, at minimum, we need to
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : A Flags Extension for TLS 1.3
Author : Yoav Nir
Filename:
The text in the PR has been updated to incorporate Sean and Rich's
suggestions. If there are no more comments I'll merge and close at the end
of the week.
Nick
On Fri, Oct 22, 2021 at 10:05 AM Salz, Rich wrote:
> Made an editorial suggestion at
>
On Mon, Oct 25, 2021 at 05:13:07PM +, Hannes Tschofenig wrote:
> Hi Ilari,
>
> > "If an item is not marked as 'Recommended', it does not necessarily
> > mean that it is flawed; rather, it indicates that the item either
> > has not been through the IETF consensus process, has limited
> >
Hi Ilari,
> "If an item is not marked as 'Recommended', it does not necessarily mean that
> it is flawed; rather, it indicates that the item either has not been through
> the IETF consensus process, has limited applicability, or is intended only
> for specific use cases."
I think the flags
Hi all,
why is the flags extension only defined for TLS 1.3?
There is nothing in this extension that prevents us from using it also in TLS
1.2.
Could we make it also available to TLS 1.2?
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Compact TLS 1.3
Authors : Eric Rescorla
Richard Barnes
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Return Routability Check for DTLS 1.2 and DTLS 1.3
Authors : Hannes Tschofenig
Rich, Hanno, Mohit,
Thanks a lot for your excellent input. We are going to follow your
advice and avoid overloading heartbeat then.
Scope-wise, RRC will focus on path validation and liveliness use cases,
leaving PMTU discovery out, at least for the moment.
cheers,
On Thu, Oct 21, 2021 at 4:45
12 matches
Mail list logo
