[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

[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

[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 ___ 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

[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

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

Re: [TLS] PR#345: IANA Considerations

or the MTI list. I can edit the document > either > way. > > -Ekr > > > On Wed, Nov 25, 2015 at 11:05 AM, Joseph Salowey <j...@salowey.net> wrote: > >> It looks like we have rough consensus to accept this PR. We can still >> have discussion on the naming of

Re: [TLS] WGLC for ChaCha20-poly1305 ciphers

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

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

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

[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

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

[TLS] Additional Agenda topics

Please let the chairs know if you have an addition topic you wish to get on the agenda. We can't guarantee that there will be time as TLS 1.3 work takes precedence right now. Thanks, Joe On Tue, Mar 22, 2016 at 11:53 AM, Sean Turner wrote: > Thanks for the getting this out. >

Re: [TLS] Simplifying signature algorithm negotiation

No objection, it looks good. I don't see any objections on the list so I say merge it. On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote: > It sounds like we have general consensus here. Does anyone object to my > merging > this PR? > > -Ekr > > > On Thu, Mar 17, 2016 at

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

d type is not going to >>> get accidentally read & misinterpreted by anything. >>> >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 >>> https://tools.ietf.org/html/rfc5764#section-5.1.2 >>> >>> https://tools.ietf.org/html/d

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

On Wed, Mar 2, 2016 at 2:22 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Wed, Mar 02, 2016 at 02:08:28PM -0800, Joseph Salowey wrote: > > Reserving large portions of other protocols number spaces is not a good > way > > to do things. This will quickly be

[TLS] Actions and issues from the IETF 95 TLS meeting

Below are some of the more significant issues discussed at the meeting in Buenos Aires: 1. Adopt David Benjamin's signature and hash algorithm negotiation structure that ties both together. New code points to define signature algorithm, curve and hash as a unit. - PR incorporated into draft -

[TLS] Draft minutes from IETF 95

Thanks to Jim Schaad for taking minutes during our two sessions. A draft is available on the IETF website at: https://www.ietf.org/proceedings/95/minutes/minutes-95-tls Corrections welcome. Thanks, Joe ___ TLS mailing list TLS@ietf.org

Re: [TLS] Updated text in regards to draft-ietf-avtcore-rfc5764-mux-fixes

Hi Magnus, The revision addresses the comments I had. If anyone else still has concerns please respond this week. Thanks, Joe On Mon, May 16, 2016 at 2:51 AM, Magnus Westerlund < magnus.westerl...@ericsson.com> wrote: > TLS WG, > (Cc AVTCORE WG) > > When AVTCORE run a WG last call earlier

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

On Sun, May 15, 2016 at 11:43 AM, Rick van Rein wrote: > Hi, > > > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean > "number > > used once", and secondly nonce re-use in AES-GCM doesn't just result in > > "catastrophic failure of it's authenticity", it

Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

The discussion on the list supports the consensus in the IETF 95 meeting to remove DHE-based 0-RTT modes. The mode should be removed from the draft. Cheers, J On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > All, > > To make sure we’ve got a clear way forward coming out

Re: [TLS] judging consensus on keys used in handshake and data messages

We would like to have all comments in on this by Friday, July 7, 2016. Also, to clarify, Hugo's interpretation is correct: Option 1 - use the same key for protecting both *post*-handshake and applications messages. On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk wrote:

Re: [TLS] RSA-PSS in TLS 1.3

I don't think we ever call consensus on this topic. It looks like there is rough consensus to move forward with RSA-PSS as the MUST implement algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5. During the discussion it also seemed that it is realistic that we may want to add

[TLS] Agenda for TLS at IETF 96 Posted

I just posted an agenda for the Berlin meeting ( https://www.ietf.org/proceedings/96/agenda/agenda-96-tls) Our main focus for the meeting will be TLS 1.3, but I am hopeful that we will have time for some other topics. The specific details of the 1.3 topics will likely change as we get closer to

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

The difference between what is defined in 1.3 and this document is the 256 bit CCM cipher suites. The document does not specify cipher suites for TLS 1.3. Is it important for TLS 1.3 to have support for these cipher suites? If it is then we either need to add the cipher suites to this document

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

TLS 1.3 currently has AES-256-GCM and ChaCha20-Poly1305 as 256-bit ciphers. AES-CCM ciphers are more oriented towards an IOT niche where CCM is implemented for lower layer protocols. I'm not sure if there are implementations of AES-256-CCM or AES-256-CCM_8 in use. Joe On Fri, Feb 24, 2017 at

[TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

Here are the open issues for draft-ietf-tls-ecdhe-psk-aead 1. Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of SHA384 like the other 256 bit cipher suites? (From Russ Housley) 2. Since the security considerations mention passwords (human chosen secrets) it should mention

Re: [TLS] PR for new negotiation syntax

Hi Folks, There was significant support for this approach in Berlin so if you have concerns with this approach please post them to the list by Monday, August 8, 2016. Thanks, S On Wed, Aug 3, 2016 at 8:30 AM, Eric Rescorla wrote: > Folks, > > As promised, I've written a PR

Re: [TLS] Finished stuffing

Hi Folks, The chairs want to make sure this gets some proper review. Please respond with comments by Friday so we can make some progress on this issue. Thanks, J On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin wrote: > I think this is a good idea. It's kind of weird,

Re: [TLS] SHA-3 in SignatureScheme

While there seems to be some support for adding SHA-3 to TLS, we're not seeing enough support to add it as part of TLS 1.3. Individual drafts that specify ciphers suites can always be separately considered though. Cheers, J On Fri, Sep 9, 2016 at 4:30 AM, Martin Thomson

Re: [TLS] Version negotiation, take two

It looks like we have enough consensus to move to an extension based version negotiation mechanism so we're asking the author to merge in this pull request. We can have further refinement of the details, but its important for us to get a complete view of the spec at this point. Cheers, J On

[TLS] Working Group Last Call for draft-ietf-tls-tls13-18

This is a working group last call announcement for draft-ietf-tls-tls13-18, to run through November 20. If possible, we would like to receive comments on the list by November 13 so they can be discussed at the meeting in Seoul. We hope to address any substantive issues raised during that process

Re: [TLS] PR#634: Registry for TLS protocol version ID

It doesn't look like we have enough consensus to adopt this proposal. Thanks, J On Sun, Oct 16, 2016 at 6:03 PM, Eric Rescorla wrote: > Chairs: Can you advise on the disposition of this? > > -Ekr > > > On Wed, Oct 12, 2016 at 6:10 PM, Martin Thomson >

Re: [TLS] Deprecating alert levels

It does not look like we have sufficient consensus to adopt this PR. While there is some support for simplifying alerts by removing the alert level, the current discussion raises some issues about the general approach. 1. Is it appropriate for all unknown alerts to be treated as fatal? (the

[TLS] Early code-point assignment request for draft-davidben-tls-grease-01

We have received a request for early code-point assignment of values for draft-davidben-tls-grease-01. Please respond to this list of you have concerns about these assignments by October 28, 2016. Thanks, J ___ TLS mailing list TLS@ietf.org

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Thanks to all those that participated in the list discussion, it was a very popular topic. On the list and in the meeting, TLS 1.3 had more support than any other option so we believe there is rough consensus to leave the name of the protocol as TLS 1.3. Thanks, J On Sat, Dec 3, 2016 at 10:15

[TLS] Interest in draft-sullivan-tls-exported-authentication

There seemed to be support for draft-sullivan-tls-exported-authentication ( https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00) in Seoul. Since there has not been much discussion of this draft on the list we are giving the working group a chance to review the draft before

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

Does you implementation allow a PSK to be used along with certificate based authentication? On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin wrote: > It's possible I'm misunderstanding your message here (I'm a little > confused by the mention of combining normal

[TLS] TLS SAAG report for IETF98

The TLS working group met on Tuesday morning. The main topic was discussion of WGLC issues of TLS 1.3. We continue to work on issues and plan on having a draft -20 that will go to the IESG. We had updates on DTLS, DNSSEC chain extension, certificate compression and delegated credentials.

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

ret construction in this document are >based on [RFC4279]. The elliptic curve parameters used in in the >Diffie-Hellman parameters are negotiated using extensions defined in >[I-D.ietf-tls-rfc4492bis]. > “”” > > [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/

[TLS] IETF-98 Minutes

Draft meeting minutes are now available in the draft proceedings: https://www.ietf.org/proceedings/98/minutes/minutes-98-tls-00.txt Let me know if you have an additions/corrections. Thanks, Joe ___ TLS mailing list TLS@ietf.org

[TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

Hey Folks, At the IETF 98 meeting in Chicago there was support in the room to adopt draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback on adopting this draft form the list. Please respond if you support the draft and are willing to review it. If you object to its adoption,

[TLS] Agenda items for TLS at IETF-98

The TLS WG is scheduled to meet at 9:00-11:30 in the Tuesday Morning session. Please send in requests for agenda time to the chairs. We will be giving priority to any remaining open TLS 1.3 issues and drafts discussed on the list. Cheers, J ___ TLS

[TLS] SAAG TLS working group report

TLS met on Monday afternoon and Wednesday morning. For TLS 1.3, the document has completed second working group last call. There are ongoing measurements to resolve the last open issue which we believe should complete in 1-2 months. Work on DTLS is going well and we expect it to go to the IESG

[TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04. Please send you comments to the list by July 12, 2017. Thanks, J ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

The chairs are forwarding this document to our AD to progress towards publication. Cheers, Joe On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey <j...@salowey.net> wrote: > Hi Daniel, > > Please submit a revised draft with the changes below. > > Thanks, > > Joe >

[TLS] WG Call for Adoption of draft-rescorla-tls-subcerts continued

In the previous call for adoption there were some issues raised that needed more discussion. The summary sent to the list [1] and subsequent discussions indicate support for the approach outlined in this draft. Therefore we would like to continue the call for adoption. If you have concerns

Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

, 2017 at 9:29 PM, Joseph Salowey <j...@salowey.net> wrote: > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback on adopting this draft form the list. Please res

Re: [TLS] Closing on 0-RTT

Hi Ekr, Discussion on this topic is dying down, can you post a PR so we can see the proposed text. There is still some discussion on the API thread so there may be some additional modifications coming in that area. On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

Hi Daniel, Thanks for putting this revision together. The original text in draft 4 went beyond the scope of what should be in the document (I was too hasty in my review of the document and discussion on the list). Your current proposal is an improvement, but it still discusses behavior that

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

On Wed, May 24, 2017 at 1:13 PM, Martin Thomson wrote: > On 25 May 2017 at 00:04, Daniel Migault > wrote: > > > B) It is not true as TLS1.3 enables these cipher suites to be negotiated > > with TLS1.3. > > You can't negotiate the new suites

Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04

Hi Dan and Alissa, There has been some churn in the text of the document due to my oversight when sending the document to the IESG. The proposed new text provided below show should also resolve your comment. Please let me know if you see any issues with this approach. Thanks, Joe Replacing

Re: [TLS] WG adoption call: SNI Encryption

The working has expressed consensus to work on the problem of SNI encryption. More work is needed to determine the technical approach to SNI encryption. The chairs believe there is enough interest and energy to adopt this draft and continue work within the working group instead of asking the

Re: [TLS] Should CCM_8 CSs be Recommended?

The current editor's copy of the draft has the following text about the recommended column: The instructions in this document add a recommended column to many of the TLS registries to indicate parameters that are generally recommended for implementations to support. Adding a recommended parameter

[TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates

ekr proposed a PR (#47) for draft-ietf-tls-iana-registry-updates that clarified the specification required rules to include Internet Drafts. I believe this is not the intent and we should close the issue. I think the intent of specification required is to allow a community that needs a code

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

I'm not sure what use cases you are targeting, but this type of solution can be dangerous for application security. Most application security models assume that TLS will provide both confidentiality and authenticity. Breaking confidentiality will often expose vulnerabilities that can result in

Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

understand. > > --Richard > > > On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <j...@salowey.net> wrote: > >> I'm not sure what use cases you are targeting, but this type of solution >> can be dangerous for application security. Most application security m

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Dear TLS WG, The chairs have been following the recent vigorous discussion on draft-rhrd-tls-tls13-visibility and we'd like to say a few words about process and how we intend to move forward. First, we would like to clarify that this discussion isn't delaying TLS 1.3. We've been holding final

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

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

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.

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,

[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

[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-extension

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

I support 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-rescorl

[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,

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

[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

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

through this process. Joe On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey <j...@salowey.net> 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

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

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 <melinda.sh...@nomountain.net > wrote: > On 4/18/18 10:22 AM, Joseph Salowey wrote: > > Concerns h

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

[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

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

ergericht: 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. Deze

[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

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

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, 2018 at

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

[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

[TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04

We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris

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

This is a working group last call for draft-ietf-tls-dtls-connection-id-03. The last working group last call resulted in some issues. The authors worked with the reviewers to publish a new draft to address these issue. Please focus your review on the changes since the previous last call. You

[TLS] Publication has been requested for draft-ietf-tls-sni-encryption-04

Joseph Salowey has requested publication of draft-ietf-tls-sni-encryption-04 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ ___ TLS mailing

[TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/.. Please review the document and send your comments to the list by

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Thanks to everyone that replied to this last call. In summary, there is support to move the draft forward with the minor editorial changes discussed on the list. We’ll start the process of moving this along to the IESG for publication. Thanks, Joe, Sean, and Chris

Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

The last call has come and gone without any comment. Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it. Also indicate if you have any plans to implement the draft. On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey wrote

Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer

This call for adoption has completed with positive response for adoption. Please submit the draft as a working group draft - draft-ietf-tls-external-psk-importer-00.txt. On Mon, Apr 8, 2019 at 5:57 PM Sean Turner wrote: > At TLS@IETF104, there was consensus in the room to adopt >

[TLS] Regarding the reference to SM ciphers

Hi Folks, It is in the hands of the designated experts and not the working group at large to determine what is an acceptable reference. Because of this we're asking participants to limit their discussion on this particular aspect of this topic. The registry policy for cipher suites is

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

This the working group last call for draft-ietf-tls-dtls-connection-id-06. The diff between the version that was last called (-03) and the current version can be found here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-06.txt=draft-ietf-tls-dtls-connection-id-03 Please

Re: [TLS] TLS CCS message

On Sun, Dec 15, 2019 at 8:28 PM ratheesh wrote: > Hi List, > > i have two questions: > > 1. As per TLS 1.2 RFC, CCS message is 1 byte with value 1. This should be > encrypted with current cipher algorithm. My questions: when i captured > packet, i could see that packet is not encrypted ( i

[TLS] Presentations Slides for IETF 106

As a reminder presentations for non-working group items must be sent to the chairs (tls-cha...@ietf.org) today. Failing to do this may result in your presentation being removed from the agenda. Presentation guidelines can be found at:

[TLS] Call for Adoption: draft-stebila-tls-hybrid-design

The authors of "Hybrid Key Exchange" have asked for adoption of their draft as a WG item. Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 28 February 2020. Please include any additional information that is helpful in

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

constraints except that the document MUST be evaluated for potential incompatibilities with NIST competition entries before WGLC. Thanks, Chris, Joe, and Sean On Thu, Feb 13, 2020 at 9:12 AM Joseph Salowey wrote: > The authors of "Hybrid Key Exchange" have asked for adoption of

[TLS] WGLC for draft-ietf-tls-external-psk-importer

Hi Folks, This is the working group last call for the "Importing External PSKs" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. Please review the document and send your comments to the list by 2359 UTC on 6 March 2020. Note the the GH repo for this

Re: [TLS] 3GPP forbids support of MD5, SHA-1, non-AEAD, and non-PFS in TLS

Hi Folks. This isn't a topic for this working group list. Please take the discussion elsewhere. Thanks, Joe On Sun, Mar 8, 2020 at 12:41 PM Tony Rutkowski wrote: > Hi Stephen, > > Amusing attempt to rewrite history. Your disagreement means nothing, > fortunately, and folks can claim FUD

Re: [TLS] Virtual TLS Interim Meeting

On Tue, Mar 24, 2020 at 7:54 PM Joseph Salowey wrote: > The chairs think it would be good to schedule a virtual TLS interim > focused on ECHO and also have a readout from the PSK design team. We have > some dates that the IESG has recommended for us. The proposal is: > >

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

by Jonathan. If no objections are raised to the new text in the PR the authors should incorporate the PR and submit a revision on Friday April 3. Thanks, Sean and Joe On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey wrote: > Hi Folks, > > This is the working group last call for the &

[TLS] Virtual TLS Interim Meeting

The chairs think it would be good to schedule a virtual TLS interim focused on ECHO and also have a readout from the PSK design team. We have some dates that the IESG has recommended for us. The proposal is: 1900 - 2100 UTC April 27 Please use the following form to let us know if you

[TLS] TLS Virtual Interim on 4/27

The TLS virtual interim will take place on 2020-04-27 19:00 - 21:00 UTC. You can find more information on the IETF upcoming meeting page [1]. The chairs are looking for volunteers for notetaker and jabber scribe. Please let us know if you will be able to help with these tasks. [1]

[TLS] April Vitrual TLS Interim Scheduled

The April TLS interim virtual meeting is scheduled for 2020-04-27 19:00 - 21:00 UTC More details will follow shortly. Agenda is available here: https://datatracker.ietf.org/meeting/interim-2020-tls-01/session/tls Cheers, Sean, Joe and Chris ___ TLS

  1   2   >