[TLS] WGLC for draft-ietf-tls-cached-info-19

Hi Folks, This is the Working Group last call for draft-ietf-tls-cached-info-19. This document has undergone modification since last WGLC so another WGLC is appropriate. This document is a dependency for the DICE working group TLS/DTLS profile. Please send your comments to the TLS list by Septemb

[TLS] Consensus on PR 169 - relax certificate list requirements

It looks like we have good consensus on PR 169 to relax certificate list ordering requirements. I had one question on the revised text. I'm unclear on the final clause in this section: "Because certificate validation requires that trust anchors be distributed independently, a self-signed certifi

Re: [TLS] Consensus on PR 169 - relax certificate list requirements

Thanks Viktor, I missed this part of the discussion. The text looks fine to me as is. Joe On Wed, Aug 26, 2015 at 2:50 PM, Viktor Dukhovni wrote: > On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote: > > > It looks like we have good consensus on PR 169 to relax cert

[TLS] Working Group Last Call for draft-ietf-tls-chacha20-poly1305-00

This is the working group last call for draft-ietf-tls-chacha20-poly1305-00. Please send any comments on the TLS working group list by September 16, 2015. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for PSS support

I looks like we have consensus to move forward with this PR (PSS), please apply the change. I think Russ's suggestion improves the text. Thanks, Joe On Thu, Sep 10, 2015 at 1:18 PM, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/239 > > Based on the WG discussion, I've create

[TLS] Call for consensus to remove anonymous DH

There has been some discussion to remove anonymous DH as described in https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think ekr's message sums up the pros and cons well. I don't think we have consensus on this issue yet. Please respond on this message by Monday, September 21,

Re: [TLS] TLS 1.3 - Support for compression to be removed

The chairs have read through this thread and do not see any new information that would cause the working group to reconsider the decision to remove compression from TLS 1.3. Discussions about clarifying the language and intent of the document are OK. Thanks, J&S On Thu, Oct 8, 2015 at 6:42 PM,

[TLS] Agenda items for Yokohama

Please email the chairs if you have a request for time on the agenda. We expect to spend the meeting time discussing TLS 1.3 and other working group items. You can request time for non-working group items, however we cannot guarantee that there will be time for them. Thanks, J&S _

Re: [TLS] PR#345: IANA Considerations

It looks like we have rough consensus to accept this PR. We can still have discussion on the naming of the categories. We will also have to define the IANA registration policy for changing the "recommended" bit. I'll open an issue for this, I think changing the bit to recommended should require

Re: [TLS] PR for anti-downgrade mechanism

It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2Zr-yflO2nUtiQY. Procedurally, we should document the requirements for TLS 1.2 in a separate draft to

Re: [TLS] PR#345: IANA Considerations

can edit the document > either > way. > > -Ekr > > > On Wed, Nov 25, 2015 at 11:05 AM, Joseph Salowey wrote: > >> It looks like we have rough consensus to accept this PR. We can still >> have discussion on the naming of the categories. We will also have to >> d

[TLS] WGLC for ChaCha20-poly1305 ciphers

draft-ietf-tls-chacha20- poly1305-03 has been submitted incorporating feedback from working group discussions. In particular the construction now matches what is used i

Re: [TLS] WGLC for ChaCha20-poly1305 ciphers

group if there is objection to early code point assignment. Thanks, J&S On Thu, Dec 3, 2015 at 1:16 PM, Joseph Salowey wrote: > draft-ietf-tls-chacha20- > <https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-03> > poly1305-03 > <https://tools.ietf.org/html/draf

[TLS] Early code point assignment for ChaCha20-poly1305 cipher suites

Please respond if you have concerns about early code point assignment for cipher suites in draft-ietf-tls-chacha20-poly1305-04 . Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.i

[TLS] Early code point assignment for draft-ietf-tls-curve25519-01

Please respond if you have concern about early code point assignment for the curves listed in draft-ietf-tls-curve25519-01 . Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mai

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

Hi All, Looks like I jumped too soon on this one. In particular, both the CFRG signature draft and 4492bis need to be updated. Let's hold of on code point assignment until then. Thanks, Joe (crawling back under my rock now) On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov wrote: > > > On 12

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

Any objections to early allocation for X25519 and X448? Are there implementers with code ready to test interop? Thanks, Joe On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith wrote: > Simon Josefsson wrote: > >> Allocating a code point for X25519 could be done and is long overdue >> (first draft S

Re: [TLS] Early code point assignment for ChaCha20-poly1305 cipher suites

We're asking the IESG for early allocation of these code points. ​ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *David Benjamin > *Sent:* Tuesday, January 19, 2016 10:01 AM > *To:* Joseph Salowey ; Brian Smith > *Cc:* Adam Langley ; Simon Josefsson < > si...@josefsson.org>; tls@ietf.org > *Subject:* Re: [TLS] Correction: early c

Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

This document is relevant to the TLS working because it reserves a large portion of the TLS content type space. The values 0-19 and 64-255 cannot be used without checking for conflicts with SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move more encrypted content types which should

[TLS] RSA-PSS in TLS 1.3

We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some hardware implementations some time to move to RSA-PSS. After an off list discussion with a few folks here is a proposal for moving forward. We make RSA-PSS man

[TLS] TLS WG Virtual Interim on ECH

The chairs would like to have an interim to resolve the remaining open issues for ECH. Since we need 2 weeks notice we are targeting the week of September first. Please fill out the following with your available times if you are interested in attending: https://doodle.com/poll/wa4633uafmvdr9hv

[TLS] TLS Interim Meeting for ECH

Thursday, September 3rd, 17:00 - 18:00 UTC This was the best time from the Doodle poll. It was not possible to accommodate everyone's schedules. We will schedule a follow-up meeting in case we need to have additional discussion on issues. Webex details: Meeting link:https: // ietf.webex.com/ie

[TLS] Reminder TLS interim focused on ECH on Thursday

Let the chairs know if you can help out as note taker or jabber scribe: The Transport Layer Security (tls) WG will hold a virtual interim meeting on 2020-09-03 from 10:00 to 11:00 America/Los_Angeles (17:00 to 18:00 UTC). Agenda: ECH Issue Discussion https://github.com/tlswg/draft-ietf-tls-esni/i

[TLS] TLS ECH Interim 2

We had a good meeting on Thursday. Minutes will be posted soon. Since we did not make it through all the issues we want to schedule another interim. Please respond to the following doodle poll by September 8. https://doodle.com/poll/3bneqeyfzkyutb7a Thanks, Joe and Sean __

[TLS] TLS ECH Interim 01 Minutes

The Minutes and Materials for TLS ECH Interim 01 can be found at the following link https://datatracker.ietf.org/meeting/interim-2020-tls-02/session/tls A link to the meeting recording is in the minutes. ___ TLS mailing list TLS@ietf.org https://www.iet

Re: [TLS] TLS ECH Interim 2

The second TLS ECH Interim is scheduled for Monday, Sep 21 2020, 15:00 UTC (8:00 PDT). More details will follow. Cheers, Joe and Sean On Fri, Sep 4, 2020 at 5:45 PM Joseph Salowey wrote: > We had a good meeting on Thursday. Minutes will be posted soon. Since we > did not make it t

[TLS] Details for TLS ECH Interim 2 Monday September 21

TLS ECH Interim 2 - 2020-09-21 15:00 - 16:00 UTC ECH Github Issues List: https://github.com/tlswg/draft-ietf-tls-esni/issues Interim meeting information: https://datatracker.ietf.org/meeting/upcoming https://datatracker.ietf.org/meeting/interim-2020-tls-03/session/tls Webex Link: https://ietf.we

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus wrote: > Hi Ben, > > > > > To be frank, I'm actually surprised that this is even seen as a matter > for > > discussion. > > As developer, I'm surprised, that this discussion now spans a couple of > years, starting on summer 2018 with: > > https://githu

[TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

Based on interest and support expressed at IETF 108, this email starts the call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can be found here: https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00 This adoption call will run until November 30, 2020. Please indic

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

, Sean, Chris and Joe On Mon, Nov 9, 2020 at 7:44 PM Joseph Salowey wrote: > Based on interest and support expressed at IETF 108, this email starts the > call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can be > found here: > > >https://tools.ietf.org/html/d

[TLS] WGLC for "Guidance for External PSK Usage in TLS"

This email starts the working group last call for "Guidance for External PSK Usage in TLS", located here: https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-01 Please review the document and send your comments to the list by December 18, 2020. Note the the GitHub repository for

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

It looks like there is enough interest in the working group to adopt this draft. Authors please submit this as a working group draft: draft-ietf-tls-cross-sni-resumption-00. Thanks, Joe On Mon, Nov 30, 2020 at 7:20 PM Joseph Salowey wrote: > At this point we do not have many responses and

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi Martin, Thanks for taking a look at this, some comments below: On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson wrote: > Hi All, > > Ben asked me to take a look at this draft and I think that the general > gist of Ben's comments need some careful consideration. > > # Commitment Message > > I th

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok wrote: > On Jan 3, 2021, at 10:44 PM, Martin Thomson wrote: > > # Key Schedule > > > > The other thing I observe is the way that this slices up the exporter > output. This was something that old versions of TLS did, but TLS 1.3 did > away with. Though

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M wrote: > Hi Alan, > Cleaning up the email. The current draft says the exporter should be > called once as: > >Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", >Type-Code, 128) > > and then split the 128 i

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok wrote: > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M > wrote: > > > > Hi Alan, > > > > Cleaning up the email. The current draft says the exporter should be > called once as: > > > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", > >>

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

rent EAP methods all loosely based on EAP-TLS. I don't see this usage as too far outside the intended use of the context field (the value should match on both sides) and I think including the type value in the context value would help avoid some potential implementation problems if the key deriv

Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Hello Working Group, We've only had one review in response to the last call so far, I'd like to see a few more reviews of this document before moving it forward. Are there any volunteers who can commit to a review in the near future? Thanks, Joe On Thu, Dec 3, 2020 at 4:51 PM Jose

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M wrote: > Hi Ben, > On 1/29/21 8:32 PM, Benjamin Kaduk wrote: > > Hi Alan, > > I see that the thread is continuing and that perhaps my reply will even > become stale as I write it, but I'm replying to your note instead of the > tip of the thread becau

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan, THanks for this message, comments inline below: On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok wrote: > This is a new message to summarize history, requirements, etc. for > EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and > how the 0x00 commitment message versus

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk wrote: > On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > > DISCUSS: the EAP-TLS draft should also explain that session tickets > may be sent either bef

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk wrote: > Hi Alan, > > I'll second the thanks for putting this together; I think it covers the > important open points. > > I did belatedly remember one more thing that is perhaps not critical, but > would also be good to get an answer for: > > On Fri,

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok wrote: > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > Yes, this is what I have in mind. So, maybe there's never any need for > the server to say "I won't say anything more" after just one round trip? > > I think so, yes. > > That means of c

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok wrote: > On Feb 1, 2021, at 2:32 PM, Joseph Salowey wrote: > > > > > > > > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok > wrote: > > On Feb 1, 2021, at 11:26 AM, Eric Rescorla wrote: > > > Yes, this is wha

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok wrote: > On Feb 1, 2021, at 3:00 PM, Joseph Salowey wrote: > > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require > CloseNotify. > > With TLS 1.2, the server sends TLS Finished to the client *after* it >

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk wrote: > On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote: > > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > > > That's a scenario that I was starting to puzzle over this weekend as > well > > > -- with EAP-Success "completely unauth

Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk wrote: > On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote: > > With Alan's comments, I think we are down to 3 alternatives: > > > > (1a). Use close_notify alert as protected success. > > Use error alerts as protected failure. > > >

Re: [TLS] Comments on draft-friel-tls-eap-dpp-01

On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins wrote: > > Hi Eric, > > On 3/8/21 8:00 AM, Eric Rescorla wrote: > > Taking a step back from the crypto, I'm trying to make sure I > understand the desired security properties. As I understand the > situation: > > - the client has a preconfigured key pa

[TLS] ECH interim Meeting Poll

The chairs would like to have an interim to work on open issues for ECH. We are targeting the week of March 31 (Wednesday - Friday). Please fill out the following with your available times if you are interested in attending: https://doodle.com/poll/24533u56vspp29vp?utm_source=poll&utm_medium=lin

[TLS] TLS Opaque

Hi Folks, We had a presentation on TLS opaque at IETF 110, but we have not had much discussion of this document on the list. The chairs would like to see more discussion on the document before considering it for adoption. There is at least one question on the list that has gone unanswered for so

[TLS] Reminder ECH Interim Thursday 4/1

The Transport Layer Security (tls) WG will hold a virtual interim meeting on 2021-04-01 from 12:00 to 13:00 America/Los_Angeles (19:00 to 20:00 UTC). Agenda: Work on Resolving open ECH Issues https://github.com/tlswg/draft-ietf-tls-esni/issues Information about remote participation:https://ietf.

Re: [TLS] Reminder ECH Interim Thursday 4/1

Also additional meeting information is available here: https://datatracker.ietf.org/meeting/upcoming On Wed, Mar 31, 2021 at 9:03 PM Joseph Salowey wrote: > The Transport Layer Security (tls) WG will hold a virtual interim meeting on > 2021-04-01 from 12:00 to 13:00 America/Los_Angeles

[TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

This is a working group call for adoption of Deprecating Obsolete Key Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 ). There was support for adopting this draft at the IETF 111 meeting. Please review

[TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 ). We had a presentation for this draft at the IETF 110 meeting and since it is a similar topic to the key e

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations are known. No detail is provided and that alone should be > sufficient reason to not adopt. > > > > Rene > > > > On 2021-07-29 5:50 p.m., Joseph Salowey wrote: > >

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

the content to be merged in on the other thread. Cheers, The TLS Chairs On Thu, Jul 29, 2021 at 2:50 PM Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 &g

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

arties has a static key, > whether ecc-based or ff-based (e.g., sni, opaque), for which secure > implementations are known. No detail is provided and that alone should be > sufficient reason to not adopt. > > Rene > > On 2021-07-29 5:50 p.m., Joseph Salowey wrote: > >

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Mon, Aug 30, 2021 at 10:47 AM Salz, Rich wrote: > By “obsolete keyex draft” you mean expired, right? > > > [Joe] I mean this draft - draft-aviram-tls-deprecate-obsolete-kex-00 (the subject of the other adoption call). There were several comments that we should merge the two drafts. Since dra

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

This message is trimmed significantly to focus on the changes made as well as the remaining issue. The plan is to merge these PRs, spin a new version, and pass it to the AD by 6 Sept. Please send in your comments on these PRs by 3 Sept. The following PRs have been submitted to address - For s1 re

Re: [TLS] draft-ietf-tls-subcerts

On Sun, Sep 12, 2021 at 8:29 AM Russ Housley wrote: > What is going on with draft-ietf-tls-subcerts? A WG Last Call was held, > and an issue was raised, but the document has not been updated since the WL > Last Call closed about a year ago? > > [Joe] Hi Russ, There is activity on the document [

[TLS] WGLC for delegated credentials

This is a one week working group last call for draft-ietf-tls-subcerts-11. Please focus on newer text for your review. Although it has been a while since the last call, we are not looking to revisit issues already decided by the working group. Please post your comments to the list by October 1, 20

[TLS] draft-farrell-tls-pemesni-02 status

While we are all supportive of ECH, we are not sure that the PEM file format for ECH I-D (draft-farrell-tls-pemesni-02) is within scope of the TLS WG. The WG has not always but mostly recently stuck to adopting I-Ds that relate to the TLS wire format. SECDISPATCH or UTA or even DNSOP might be a bet

[TLS] Working group adoption of draft-aviram-deprecate-obsolete-kex-01

draft-aviram-deprecate-obsolete-kex-01 has been revised and merged in content from draft-bartle-tls-deprecate-ffdh to address some of the concerns raised in the adoption call. The chairs think this is a good starting point for adoption as a working group item. Authors please submit the draft as dra

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-01.txt

On Fri, Jul 8, 2022 at 12:06 AM Ilari Liusvaara wrote: > On Thu, Jul 07, 2022 at 09:25:15PM -0700, internet-dra...@ietf.org wrote: > > > > 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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

I think the current working group consensus for the policy of the recommended column is reflected in the following statement: Setting a value to "Y" or "D" in the "Recommended" column requires IETF Standards Action [RFC8126 <#RFC8126>]. Any state transition to or from a "Y" or "D" value requires I

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

This update changes the draft to an update of RFC 8447 instead of obsoleting it, populates the 'D' values for some of the entries in the registries and changes the exporter registry from specification required to expert review. Cheers, Joe On Wed, Feb 1, 2023 at 9:15 PM wrote: > > A New Intern

[TLS] Slides reminder

Hi Folks, THe TLS meeting at IETF 118 is quickly approaching. Please propose your slides through the meeting materials tool. Thanks, The Chairs ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

At the TLS meeting at IETF 118 there was significant support for the draft Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 ( https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/01/) This call is to confirm this on the list.

[TLS] Call to Move RFC 8773 from Experimental to Standards Track

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key) was originally published as experimental due to lack of implementations. As part of implementation work for the EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is ongoing impleme

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

The adoption call for this draft has completed. There is sufficient interest in the draft and no objections. Authors, please submit this draft with the file name draft-tls-tls13-pkcs1-00.txt. Cheers, Joe On Mon, Nov 6, 2023 at 9:25 AM Joseph Salowey wrote: > At the TLS meeting at IETF

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

d, Nov 29, 2023 at 11:07 AM Joseph Salowey wrote: > >> The adoption call for this draft has completed. There is sufficient >> interest in the draft and no objections. Authors, please submit this draft >> with the file name draft-tls-tls13-pkcs1-00.txt. >> >> Cheers

[TLS] Completion of Update Call for RFC 8773bis

The working group last call for RFC8773bis has completed (draft-ietf-tls-8773bis). There was general support for moving the document forward and upgrading its status. However, several working group participants raised the concern that formal analysis has not been conducted on this modification to t

Re: [TLS] Completion of Update Call for RFC 8773bis

Yes On Tue, Jan 23, 2024 at 10:15 AM Eric Rescorla wrote: > Joe, > > Does this mean that this draft will be held pending resolution on that > proposal? > > -Ekr > > > > On Tue, Jan 23, 2024 at 7:51 AM Joseph Salowey wrote: > >> The working group last call

[TLS] Working Group Last Call for ECH

This is the working group last call for TLS Encrypted Client Hello [1]. Please indicate if you think the draft is ready to progress to the IESG and send any comments to the list by 31 March 2024. The comments sent by Watson Ladd to the list [2] on 17 February 2024 will be considered last call comm

[TLS] Update on draft-ietf-tls-dnssec-chain-extension

The authors will be posting a new version (-06) that replaces some text that was missed in the previous version that addressed the WGLC comments. The -06 version will be sent to the IESG for publication. Cheers, Joe ___ TLS mailing list TLS@ietf.org htt

[TLS] Publication has been requested for draft-ietf-tls-dnssec-chain-extension-06

Joseph Salowey has requested publication of draft-ietf-tls-dnssec-chain-extension-06 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-exte

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Stephen, In the meeting in Prague there was interest in this problem space, but neither the consensus to accept or reject this work. The authors have revised their proposal to address some of the concerns raised by working group members and are asking to bring the new approach in front of the

Re: [TLS] TLS@IETF101 Agenda Posted

Hi Stephen, It is not accurate to say that there was consensus to stop discussion of this topic in Prague. There are vocal contingents both for an against this topic. We did not have discussion of this draft in Singapore because the authors could not make the meeting due to several issues and we

Re: [TLS] TLS@IETF101 Agenda Posted

The consensus (as judge by the chairs) was that there no clear consensus to shut the discussion down. It was not that work on internal solution is needed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Hi Folks, Some objections were raised late during the review of the draft-ietf-tls-dnssec-chain-extension. The question before the working group is either to publish the document as is or to bring the document back into the working group to address the following issues: - Recommendation of adding

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

we go through this process. Joe On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document a

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters wrote: > > > 4. Re-submit the document for publication and start work on a separate >> extension that supports pinning >> > > While we agree we can move pinning to a separate document, it makes much > less sense for this to become an additional ful

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

When your revisions are ready please post them to the list in OLD and NEW format so the working group can evaluate them. Thanks, Joe On Wed, Apr 18, 2018 at 1:20 PM, Melinda Shore wrote: > On 4/18/18 10:22 AM, Joseph Salowey wrote: > > Concerns have been raised about the trade-offs a

Re: [TLS] Proposed text for dnsssec chain extension draft

To clarify, I asked for exact text to understand better what is being asked for, since it wasn't very clear to me what the scope fo the change is. On Wed, Apr 25, 2018 at 2:51 AM, Melinda Shore wrote: > On 4/25/18 7:33 AM, Viktor Dukhovni wrote: > > Perhaps a concrete proposal will make it > > e

Re: [TLS] Proposed text for dnsssec chain extension draft

This proposal is quite a bit more than just a two byte reserved field. On Wed, Apr 25, 2018 at 8:46 AM, Nico Williams wrote: > On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote: > > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote: > > > On Wed, Apr 25, 2018 at 11:51:58A

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

I agree we should use a different number than 26 for certificate compression. I don't see a problem with assigning 27 and reserving 26 for now. On Wed, May 30, 2018 at 8:13 PM, Adam Langley wrote: > On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton wrote: > > I also delivered an OpenSSL-based TLS

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

Since there is a conflict with deployments with extension code point 26 IANA has now assigned the compress_certificate extension code point 27 from the TLS extensionType values registry. On Wed, May 23, 2018 at 6:23 PM, Sean Turner wrote: > IANA has assigned the following values: > > 1) In the E

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Hi Folks, There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision. Plea

[TLS] Update from side meeting on TLS DNSSEC

A group met this afternoon to discuss the TLS DNSSEC document. I want to thank the participants as I think it was a productive meeting. Here is chairs' summary of some of the important points of the discussion from notes from the meeting. The second section outlines some behavior that we need to

[TLS] WG adoption call: draft-rescorla-tls-esni

The sense of the TLS@IETF102 room was the the WG should adopt https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. But, we need to confirm this on list. If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, the

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

upport adoption of this draft and would be happy to review it. >> >> On Tue, Jul 24, 2018, 22:18 Joseph Salowey wrote: >> >>> >>> The sense of the TLS@IETF102 room was the the WG should adopt >>> https://datatracker.ietf.org/doc/draft-rescorla-tls-esn

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

It looks like we have consensus to adopt this draft as a working group item. Authors, please submit the draft as: draft-ietf-tls-oldversions- deprecate-00.txt On Mon, Aug 20, 2018 at 10:20 AM, Short, Todd < tshort=40akamai@dmarc.ietf.org> wrote: > I support adoption. > -- > -Todd Short > /

Re: [TLS] Interim meeting information

We are having some technical issues getting the meeting started. On Fri, Sep 14, 2018 at 10:03 AM, Richard Barnes wrote: > I am getting "This link to the event is no longer valid" from the below > link, and I hear folks are having PSTN trouble as well. Are there some > different coordinates we

Re: [TLS] Interim meeting information

It should be working now. On Fri, Sep 14, 2018 at 10:05 AM, Daniel Kahn Gillmor wrote: > On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote: > > https://ietf.webex.com/ietf/onstage/g.php?MTID= > e02cf108b5a24e348e10132497d5def9 > > when i visit this, i get a page that says:: > > This l

Re: [TLS] Interim meeting information

You need to use the webex meeting number: 642 489 356 On Fri, Sep 14, 2018 at 10:16 AM, Eric Rescorla wrote: > Still doesn't work for mel > > On Fri, Sep 14, 2018 at 10:13 AM, Joseph Salowey wrote: > >> It should be working now. >> >> On Fri, Sep 14, 20

[TLS] WGLC for draft-ietf-tls-dtls-connection-id

This is the working group last call for the "Connection Identifiers for DTLS 1.2" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. Please review the document and send your comments to the list by 2359 UTC on 30 November 2018. Thanks, Chris, Joe, and Sean

[TLS] WGLC has concluded for draft-ietf-tls-sni-encryption

Several comments were received for draft-ietf-tls-sni-encryption. The chairs will work with the authors to address the comments and revise the draft to submit it to the IESG. The working group has consensus to work on the document, however comments against this consensus will be noted in the docu

Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id

in, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. > Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic > > > From: TLS <mailto:tls-boun...@ietf.org> On Behalf Of Salz, Rich > Sent: Mittwoch, 5.

[TLS] sending draft-ietf-tls-sni-encryption to IESG

WGLC last call completed some time ago and we have a revised draft and shepherd writeup - https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. We'll be sending this draft to the IESG soon. Thanks, Chris, Joe, and Sean ___ TLS mailing list T

  1   2   3   >