Re: [TLS] DTLS RRC and heartbeat

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

[TLS] I-D Action: draft-ietf-tls-dtls-rrc-01.txt

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

[TLS] I-D Action: draft-ietf-tls-ctls-04.txt

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

[TLS] Flags Extension: why only for TLS 1.3?

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 al

Re: [TLS] TLS Flags and IANA registration policy

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 dra

Re: [TLS] TLS Flags and IANA registration policy

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 > > applic

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

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 > https://github.com/tlswg/tls-exported-authentica

[TLS] I-D Action: draft-ietf-tls-tlsflags-07.txt

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: draft-ietf-tls-tlsflags-0

[TLS] Spec issue with RFC 7627 (EMS) and resumption

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 replace

[TLS] I-D Action: draft-ietf-tls-rfc8446bis-03.txt

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

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

Here's some possible replacement text for that paragraph: """ In some deployments, a legacy client or server may be exposed to a session using extended master secret. For example, a group of servers sharing a ticket encryption key may be in the process of enabling this extension. If such a session

Re: [TLS] Point Compression

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

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

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

Re: [TLS] Point Compression

Do we have evidence that "02 " or "03 " is more widespread than for NIST curves? I haven't seen "02 " or "03 " in deployed products in TLS / X.509 at all. So, I feel that for TLS space the slate is clean regarding compression. X25519 uses one coordinate, which is simiiar to doing for NIST curves.