Re: [TLS] 4492 ECDH_anon

On Jul 22, 2015, at 13:12, Yoav Nir ynir.i...@gmail.com wrote: I’d like to hear from the chairs if it’s OK to rename stuff in the IANA registry. It is fine to rename stuff in the registries. As Dave pointed out we just did that in the FFDHE draft. Just make sure to put the instructions

Re: [TLS] Fall '15 TLS Interim

a WebEx session so that people can dial-in. spt On Aug 17, 2015, at 19:37, Sean Turner (via Doodle) mai...@doodle.com wrote: Hi there, Sean Turner (turn...@ieca.com) invites you to participate in the Doodle poll Fall '15 TLS Interim. This is a doodle poll

Re: [TLS] draft-shore-tls-dnssec-chain-extension

Melinda, As chair, I really appreciate you holding off. spt > On Oct 29, 2015, at 11:27, Melinda Shore wrote: > > Hi, all: > > We haven't been pushing on this because we recognize that getting > TLS 1.3 published is top priority, but we've got a new version >

Re: [TLS] TLS 1.3 - Just ditch compression

My bad there were some messages sitting in the moderator queue that I let go. spt > On Nov 02, 2015, at 10:01, Dave Garrett wrote: > > On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote: >> I thought we already decided to remove compression from TLS 1.3. > >

[TLS] IETF 94 - TLS agenda

I’ve uploaded the agenda: https://www.ietf.org/proceedings/94/agenda/agenda-94-tls I’ll post slides as I get them. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New curves work and TLS

On Oct 17, 2015, at 08:30, Ilari Liusvaara wrote: > Okay, did a review of draft-ietf-tls-curve25519 (since it still > doesn't seem to have been WGLC'd): Note that draft-ietf-tls-curve25519 is getting merged into draft-ietf-tls-rfc4492bis. Note that the cfrg-curves

Re: [TLS] '15 TLS Fall Interim Minutes

On Sep 22, 2015, at 19:27, Sean Turner <s...@sn3rd.com> wrote: > I’ve gone ahead and posted the minutes/list of decisions to: > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > spt Revised minutes posted t

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

On Sep 02, 2015, at 11:20, Julien ÉLIE wrote: > Hi Rich, > >>> Maybe a new RFC obsoleting RFC 4642 (which could at the same time >>> become a standard instead of a proposed standard)? >> >> Is there any reason why NNTP cannot just use the UTA specifications? > > When

Re: [TLS] reminder (Re: '15 TLS Fall Interim Logistics)

I’ve also uploaded a draft agenda: http://ietf.org/meeting/interim/proceedings.html As per usual, this interim is going to focus on TLS 1.3 related issues. spt On Sep 15, 2015, at 15:09, Sean Turner <s...@sn3rd.com> wrote: > In case you’re planning on attending the f2f meeting

Re: [TLS] RFC 7627 on Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension

Thanks to all who helped to get this published. spt On Sep 16, 2015, at 13:44, rfc-edi...@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > >RFC 7627 > >Title: Transport Layer Security (TLS) Session >

Re: [TLS] '15 TLS Fall Interim Minutes

>> ## Data transfer limitation per connection (issue 125/4) >> >> After quibbling with the math a bit, we need to specify how good we >> think the current ciphers are numbers. > > Parse error. Does this mean something like "how much data current > ciphers can safely encrypt”? It does. I’ll

[TLS] '15 TLS Fall Interim Minutes

I’ve gone ahead and posted the minutes/list of decisions to: https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Fall Interim webex/jabber details

Please note that I sent two webex invites one for each day and that they have different meeting #s but the same pwd: Monday: https://mailarchive.ietf.org/arch/msg/tls/2wD0hlicN7oaBbWO8qKqtXAhfos Tuesday: https://mailarchive.ietf.org/arch/msg/tls/mP16zjy9h7eH2y02WTEnTqDKey4 We’re starting at 9

[TLS] '15 TLS WG interim materials

I’ve uploaded the slides I’ve received to: https://www.ietf.org/proceedings/interim/2015/09/21/tls/proceedings.html spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Early code point assignments for 25519/448 curves

All, We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will go in the "Supported Groups" Registry: // ECDH functions. ecdh_x25519 ecdh_x448 // Signature curves. eddsa_ed25519 eddsa_ed448 These points will be included in the following 2 (two)

[TLS] adopted: draft-shore-tls-dnssec-chain-extension

It appears that we’ve got enough consensus/interest to adopt draft-shore-tls-dnssec-chain-extension based on this thread: https://mailarchive.ietf.org/arch/msg/tls/ymEtvciDKGgI2JrGP6wlV7XWy7I We're hoping that we can maintain focus and get this extension published quickly. Authors, If

[TLS] adopted: draft-mattsson-tls-ecdhe-psk-aead

I appears that we’ve got enough consensus/interest to adopt draft-mattsson-tls-ecdhe-psk-aead based on this thread: https://mailarchive.ietf.org/arch/msg/tls/JuC5Fba5PSsPenRvLGIUdYuFYeI Note that this draft will be published using new the IANA registrations rules we’ve discussed so it’ll

Re: [TLS] adopted: draft-mattsson-tls-ecdhe-psk-aead

On May 27, 2016, at 17:59, Henrik Grubbström <gru...@gmail.com> wrote: > > On Fri, May 27, 2016 at 4:55 PM, Sean Turner <s...@sn3rd.com> wrote: >> I appears that we’ve got enough consensus/interest to adopt >> draft-mattsson-tls-ecdhe-psk-aead

Re: [TLS] RFC 7905 on ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)

Congrats to all involved! spt > On Jun 22, 2016, at 18:33, rfc-edi...@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > >RFC 7905 > >Title: ChaCha20-Poly1305 Cipher Suites for >Transport Layer Security

[TLS] WG Status of draft-ietf-tls-pwd

All, draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late 2013. It was parked by the WG chairs because there was no consensus to move the document forward during WGLC [2][3]. However, circumstances have changed namely the publication of Dragonfly Key Exchange RFC [4] and

[TLS] TLS1.3 status/expectations

At the TRON workshop [0], we (Joe and Sean) were asked to provide our views about the status and timeline for TLS 1.3; we wanted to share the same information with the WG. Before that though, we want to thank the researchers for the time they put into analyzing the protocol as well as the TRON

[TLS] WGLC for draft-ietf-tls-falsestart

All, This is the working group last call for the "False Start" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/. Please review the document and send your comments to the list by 5 February 2016. Thanks, J ___ TLS

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

All, Andrey sent this message at the chairs' request to make sure that we adequately discussed the issue, which we discussed at the last IETF meeting (https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf). spt > On Jan 21, 2016, at 21:25, Andrey Jivsov wrote: >

[TLS] ecdh_x25519 and ecdh_x448 code points

All, After completing the early code point assignment process, IANA has added the following values to the Supported Groups Registry: 29 ecdh_x25519 30 ecdh_x448 You can see the entries here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 spt

[TLS] ChaCha20 Poly1305 code points

All, IANA has assigned code points for draft-ietf-tls-chacha20-poly1305. They can be found in the following registry: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 Authors, Feel free to update your draft to reflect just the assigned numbers, which

[TLS] Fwd: Publication has been requested for draft-ietf-tls-chacha20-poly1305-04

FYI … > Begin forwarded message: > > From: "Sean Turner" <s...@sn3rd.com> > Subject: Publication has been requested for > draft-ietf-tls-chacha20-poly1305-04 > Date: March 10, 2016 at 17:08:27 GMT+9 > To: <stephen.farr...@cs.tcd.ie> > Cc: "Sea

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

-wap-wep/ [8] I’m sure this rule has been broken at some point in the past, but it’s not one I’m advocating that we break it on a regular basis. > Yoav > >> On 30 Mar 2016, at 4:53 AM, Sean Turner <s...@sn3rd.com> wrote: >> >> Hi! >> >> In Yokohama, w

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

On Mar 30, 2016, at 11:33, Benjamin Kaduk wrote: > > I support this plan (with the expectation that the IANA "specification > required" rules take precedence over the informal text in this mail > about a "stable, publicly available, peer reviewed reference document", > as Yoav

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

On Apr 06, 2016, at 12:21, Aaron Zauner <a...@azet.org> wrote: > > Hi, > >> On 30 Mar 2016, at 03:53, Sean Turner <s...@sn3rd.com> wrote: >> >> Hi! >> >> In Yokohama, we discussed changing the IANA registry assignment rules for >&

Re: [TLS] Asymmetric TLS

With my chair hat on, I won’t comment one way or the other on whether this should be done, but we have gone down this path before. As I recall, the proposal was pretty resoundingly rejected. But, what I will say as chair is that this would most definitely require a charter change for the WG.

Re: [TLS] I-D ACTION:draft-ietf-tls-tls13-12.txt

Thanks for the getting this out. Obviously, what’s changed and what’s still outstanding is going to be the lion share of our discussions in BA. spt > On Mar 22, 2016, at 13:16, internet-dra...@ietf.org wrote: > > A new Internet-Draft is available from the on-line Internet-Drafts >

Re: [TLS] Include Speck block cipher?

If we’re going to get into the cryptanalysis of SPECK then this thread should move off the TLS list and possibly to the CFRG list. spt > On Mar 21, 2016, at 10:07, Efthymios Iosifides wrote: > > >I don't see any compelling argument for the inclusion of SPECK? Not only >

Re: [TLS] Cached Info

On Mar 09, 2016, at 09:16, Hannes Tschofenig wrote: …snip > - > > In a nutshell, while I do not believe that the attack described is > realistic I am sensitive to the problem of creating brittle code. > > If it is OK for the working group then I

[TLS] Fwd: Publication has been requested for draft-ietf-tls-falsestart-01

FYI > Begin forwarded message: > > From: "Sean Turner" <s...@sn3rd.com> > Subject: Publication has been requested for draft-ietf-tls-falsestart-01 > Date: March 21, 2016 at 10:42:10 EDT > To: <stephen.farr...@cs.tcd.ie> > Cc: "Sean Turner"

Re: [TLS] AD review of draft-ietf-tls-falsestart-01

On Mar 24, 2016, at 05:56, Stephen Farrell wrote: > > > Hiya, > > Thanks for the speedy response... > > Again #3 below is what I care about, the other stuff isn't > a big deal. > > On 24/03/16 00:38, Bodo Moeller wrote: >> "Stephen Farrell"

[TLS] Call for consensus: Removing 0-RTT client auth

All, To make sure we’ve got a clear way forward coming out of our BA sessions, we need to make sure there’s consensus on a couple of outstanding issues. So... It seems that there is a clear consensus not to support 0-RTT client authentication in TLS 1.3 at this time. If you think 0-RTT

[TLS] call for consensus: changes to IANA registry rules for cipher suites

Hi! In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry. This change is motivated by

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

I got the dates wrong. They should both have been 20160510. spt > On Apr 25, 2016, at 08:12, Sean Turner <s...@sn3rd.com> wrote: > > All, > > draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 > [0], and the authors have been biding their ti

[TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

All, draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed for TLS1.3. We need to get these officially registered so the chairs would like to hear whether there is WG support for adopting draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you: - Support

Re: [TLS] Updated TLS Cached Info Document

On May 12, 2016, at 10:40, Stephen Farrell wrote: > > > Thanks Hannes. > > This document was already approved by the IESG and we were > just waiting on this particular change to be made. AFAIK, > this change, while affecting the bits on the wire, is ok > with those

Re: [TLS] QUIC BoF for Berlin

On May 12, 2016, at 15:05, Ted Hardie wrote: > > The IETF mailing list for discussion of this proposal has been set up at > q...@ietf.org. To subscribe via the web: https://www.ietf.org/mailman/listinfo/quic spt ___ TLS mailing

Re: [TLS] confirming AUTH48 changes to draft-ietf-tls-cached-info

The consensus of the WG is to not make the changes to the referred to by this msg. Hannes, Please respond to the RFC Editor to complete AUTH48 processing of this draft. J > On Jul 06, 2016, at 13:45, Sean Turner <s...@sn3rd.com> wrote: > > Anirudh noted [0] that existing

Re: [TLS] Keeping TLS extension points working

David, Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to make via the IANA considerations section. They enforce the registry policy established when we (the IETF/TLS WG) originally established the registry; the available policies are found in RFC 5226 (and there’s some

Re: [TLS] RFC 7924 on Transport Layer Security (TLS) Cached Information Extension

Congrats to all involved! spt > On Jul 19, 2016, at 10:01, rfc-edi...@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > >RFC 7924 > >Title: Transport Layer Security (TLS) Cached >Information Extension

[TLS] confirming AUTH48 changes to draft-ietf-tls-cached-info

Anirudh noted [0] that existing implementation practices in TLS stacks may lead to additional complexity when implementing TLS cached info on the server side. The main issue is that the server needs to prepare the ServerHello (and list the CachedInfo extension) saying which payloads will

[TLS] Reminders

Hi, Just wanted to remind everybody that we’ve got two non-TLS1.3 items we’re looking for WG input on: - Before 12 July, we’d like to know your thoughts about progressing draft-ietf-tls-pwd (Watson and ekr responded): https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 -

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

> On Jul 10, 2016, at 03:36, g_e_montene...@yahoo.com wrote: > > Hi, > > I'm curious as to the relationship between this TLS WG draft and the DICE > profile for IoT (currently in Auth48): > https://tools.ietf.org/html/draft-ietf-dice-profile > > The dice profile uses two TLS ciphershuites >

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

I think I can take this bit: On Jul 10, 2016, at 06:51, Peter Dettman wrote: > > I'm also curious whether there is a precedent in other RFCs for an > explicit minimum curve bits, or perhaps a de facto implementer's rule? I’d be happy to be wrong here. but to my

[TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

All, We've received a request for early IANA assignments for the 6 cipher suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/. Please respond before August 23rd if you have concerns about early code point assignment for these cipher suites. J

[TLS] Issues and PRs for draft-ietf-tls-iana-registry-updates

I submitted a PR to address some editorial issues: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/5 I also created an issue/PR that adds a “recommended" column for exporters; its another registry that could use it. I followed the same model as the CS registry, namely put a

Re: [TLS] GREASE and TLS 1.3

> On Jan 18, 2017, at 17:49, David Benjamin wrote: > > Do people agree with this plan? Looks like we got general agreement this is a good approach to follow. spt ___ TLS mailing list TLS@ietf.org

Re: [TLS] Adding an additional step to exporters

So this isn’t entirely novel right I mean we did something similar wrt other key schedules? spt > On Feb 23, 2017, at 23:30, Martin Thomson wrote: > > https://github.com/tlswg/tls13-spec/pull/882 contains the longer description. > > In short, the existence of an

[TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

All, We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”. As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to: a) Close these two PRs and go

[TLS] Closing out the final issue in 4492bis

All, The changes made to draft-ietf-tls-rfc4492bis-11 addressed the WGLC comments, but we were waiting to hear from the CFRG wrt whether to use contexts. It appears that the CFRG thread discussing the use of context for TLS1.3 has wound down [0] and it appears that the consensus is: “no to

Re: [TLS] IANA Alert registry does not include ALPN alert

Will do. Might not make the -00 version but we can add it as an issue to fix in -01. spt > On Aug 26, 2016, at 10:41, Eric Rescorla wrote: > > I believe the chairs are preparing an IANA update RFC. We can cram it in > there. > > -Ekr > > > On Fri, Aug 26, 2016 at 7:27 AM,

Re: [TLS] PR#625: Change alert requirements

All, The chairs would like to get some eyes on this PR by this Friday (Sept 9th) so that we can draw it to close. Thanks, J > On Sep 05, 2016, at 14:02, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/625 > > Currently the TLS spec requires

Re: [TLS] Version negotiation, take two

All, There appears to be an emerging consensus here to adopt the change proposed by this PR. Please indicate whether you are unwilling (and why) to accept this change by September 16th. J > On Sep 08, 2016, at 12:04, David Benjamin wrote: > > Hi folks, > > I’d like

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

There appears to be no consensus to adopt the change proposed by this PR. The small condolence here is that the name+semantics for this extension has been changed once before and if the extension really needs to be renamed in 5-7 years we’ve got precedence for doing so. spt > On Aug 29, 2016,

[TLS] closing KeyUpdate

The discussion about KeyUpdate-related changes has trailed off so it is time to begin to bring the discussion to a close. It appears that there as if there is support to land https://github.com/tlswg/tls13-spec/pull/61. But, there’s still some discussion about how to add both P3 and P4 [0].

Re: [TLS] [Editorial Errata Reported] RFC6066 (4817)

Looks like this one can safely be accepted. spt > On Oct 03, 2016, at 13:47, RFC Errata System > wrote: > > The following errata report has been submitted for RFC6066, > "Transport Layer Security (TLS) Extensions: Extension Definitions". > >

Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3

All, It’s time to put this one to bed. ekr’s going to put back user_mapping for Andrei/MS, but we’re going to ban/orphan the client_authz and server_authz extensions. If it turns out that there’s some need to later unban/unorphan them, then somebody can write a draft that specifies how

Re: [TLS] Proposed Change to Certificate message (#654)

I’m not seeing objections to this PR so please let us know by Friday (7 October) whether you see any issues with what’s been proposed. spt > On Sep 22, 2016, at 20:42, Nick Sullivan wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/654 > > Hello, > > I'd

Re: [TLS] PR#625: Change alert requirements

Thanks for the discussion. We’re going to ask ekr to merge this one (obviously dealing with the additional input provided during the discussion). J > On Sep 06, 2016, at 17:33, Sean Turner <s...@sn3rd.com> wrote: > > All, > > The chairs would like to get some eyes on t

[TLS] Fwd: New Version Notification for draft-sandj-tls-iana-registry-updates-00.txt

-sandj-tls-iana-registry-updates-00.txt > Date: September 07, 2016 at 14:10:25 EDT > To: "Joe Salowey" <j...@salowey.net>, "Sean Turner" <s...@sn3rd.com>, > <none-cha...@ietf.org>, "Joseph A. Salowey" <j...@salowey.net> > > > A n

Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

This looks correct, but I’d change the “type” to editorial. Unless anybody disagrees with by next Monday, I’ll ask Stephen to accept this. I’ve also submitted an issue in the 4492bis github repo to get this fixed in the new draft. I’d submit a PR, but I’m still digging out from being absent

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

Any more thoughts on these? spt > On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) > wrote: > > Hi Ben, > > On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote: > > The next step is for someone to write proposed text that would be more > > clear. > > Maybe you

Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

Although the mistake in RFC4492 is clearly a typo, I > think it does affect the technical meaning. So I would prefer to leave the > type as technical. > > > [1] https://www.rfc-editor.org/errata-definitions/ > > Best, > > Xiaoyin > > > From: TLS <tls-boun.

Re: [TLS] [Editorial Errata Reported] RFC5246 (4750)

And there’s the link to that issue: https://github.com/tlswg/tls13-spec/issues/587 spt > On Aug 24, 2016, at 15:45, Sean Turner <s...@sn3rd.com> wrote: > > I created an issue for this in the tls13 repo so that we can settle on > whether or not we need to change. > > s

Re: [TLS] COSIC's look on TLS 1.3

I let this message through the moderator queue despite the link to the blog; next time please send your comments directly to the list. Note that I wouldn’t necessarily expect anybody to pick up your points for you; PRs are welcome though. spt > On Nov 08, 2016, at 20:25, Roel Peeters

Re: [TLS] Call for agenda items @ IETF 97

The final IETF 97 agenda is out: https://datatracker.ietf.org/meeting/97/agenda.html Please note that there are TWO tls sessions: 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 2. Friday @ 09:30-1130 in Grand Ballroom 2 spt > On Oct 18, 2016, at 14:07, Sean Turner <s...@sn3rd.com&

Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

Note that I hope that we don’t need to present in Korea. My opinion is that this process mumbo jumbo is important (to some), but I don’t think it should occupy the group’s f2f time. But, it still needs review so please do and provide comments either here or via a PR. spt > On Oct 22, 2016,

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

gt; > > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-boun...@ietf.org > > on behalf of martin.thom...@gmail.com> wrote: > > > >>Looking at those emails, I am prompted to wonder if anyone can justify > >>the existence of a ciphersuite with a

[TLS] Call for agenda items @ IETF 97

The preliminary IETF 97 agenda is out: https://datatracker.ietf.org/meeting/97/agenda.html. We’re currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. Please send in agenda requests. But, please note that TLS 1.3-related issues and WG drafts will be given a priority during the

Re: [TLS] draft-ietf-tls-tls-13-17 posted

> On Oct 21, 2016, at 07:39, Eric Rescorla wrote: > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara > wrote: > On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote: > > Folks, > > > > I have just uploaded draft-ietf-tls-tls13-17. > >

Re: [TLS] I-D Action: draft-sandj-tls-iana-registry-updates-01.txt

> On Oct 20, 2016, at 19:04, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 21 October 2016 at 05:15, Sean Turner <s...@sn3rd.com> wrote: >> 1) I’d like to add something along the line of the following as a warning at >> the top of the cider suite

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

>> - Section 1 >> "This is illustrated in the following table, based on [Lenstra_Verheul], >> which gives approximate comparable key sizes for symmetric- and >> asymmetric-key cryptosystems based on the best-known algorithms for >> attacking them." >> >> The key sizes for DH/DSA/RSA does not

Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard

Seeing no objections I’ll get this process underway. spt > On Nov 15, 2016, at 20:10, Sean Turner <s...@sn3rd.com> wrote: > > Note that Russ pointed out during the meeting that even though we can use > this process a new RFC # will be minted at the end of the process. >

[TLS] WGLC for draft-ietf-tls-rfc4492bis

All, This is a working group last call for the “4492bis to Standards Track" draft available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/. Please review the document and send your comments to the list by 9 December 2016. Note that we are particularly interesting in the issue

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

At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. The consensus in the room was to leave it as is, i.e., TLS1.3, and to not

[TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead

This is the working group last call for the "ECDHE_PSK with AES-GCM and AES-CCM CSs for TLS" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/. Please review the document and send your comments to the list by 9 December 2016. Thanks, J

Re: [TLS] Call for agenda items @ IETF 97

New version uploaded v6 is now the current version. spt > On Nov 18, 2016, at 08:13, Sean Turner <s...@sn3rd.com> wrote: > > I’ve uploaded the slides for Friday as well as a revised WG Chair Slide deck > (version 5), which reflects the revised agenda based on presentations

Re: [TLS] Call for agenda items @ IETF 97

I’ve uploaded the slides for Friday as well as a revised WG Chair Slide deck (version 5), which reflects the revised agenda based on presentations that got moved to Wednesday. spt > On Nov 15, 2016, at 08:20, Sean Turner <s...@sn3rd.com> wrote: > > Please note that I’ve

[TLS] housekeeping: uplift RFC 5289 to Proposed Standard

This email addresses the "Uplifting” bullet on slide 6 of the chair slides (https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-slides-00.pdf); this is entirely procedural (i.e., there’s really no technical ). The cipher suite registry's new "WG recommended” column's “Y"

[TLS] TLS sessions' agenda uploaded

I’ve uploaded the agenda and chair slides: https://datatracker.ietf.org/meeting/97/agenda.html Since we’ve got two sessions and the second session conflicts with tcpinc, if we end up getting through the presentations scheduled for Wednesday we’ll pull the Friday presentations forward in this

Re: [TLS] TLS sessions' agenda uploaded

(aka PR#612) Example Handshake Traces for TLS 1.3 DTLS spt > On Nov 14, 2016, at 07:39, Sean Turner <s...@sn3rd.com> wrote: > > I’ve uploaded the agenda and chair slides: > https://datatracker.ietf.org/meeting/97/agenda.html > > Since we’ve got two sessions and the

Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard

Note that Russ pointed out during the meeting that even though we can use this process a new RFC # will be minted at the end of the process. spt > On Nov 14, 2016, at 10:36, Sean Turner <s...@sn3rd.com> wrote: > > This email addresses the "Uplifting” bullet on slide 6

Re: [TLS] Call for agenda items @ IETF 97

for the Example Handshake Traces in TLS 1.3 agenda item. spt > On Oct 24, 2016, at 00:13, Sean Turner <s...@sn3rd.com> wrote: > > The final IETF 97 agenda is out: > https://datatracker.ietf.org/meeting/97/agenda.html > > Please note that there are TWO tls sessions: &g

[TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

Please note that this draft is related to the agenda item: - TLS Visibility Inside the Data Center spt > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt > Date: November 14, 2016 at 15:36:49 GMT+9 > To:

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt

Yoav thanks for continuing to push this. We’ll update the status slides once we kick off the next steps. spt > On Oct 29, 2016, at 16:04, Yoav Nir wrote: > > Hi. > > This is mostly a maintenance version. I’ve updated references and removed > some TBDs for ideas that

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

The concern here is that people won’t review it until the end and that is definitely not what we want. I’d really like get the most out of our f2f meeting in Seoul so pretty please people review it before Seoul. spt > On Oct 27, 2016, at 07:07, Salz, Rich wrote: > > So

[TLS] IETF 97 - draft TLS agenda

I’ve uploaded a draft agenda: https://www.ietf.org/proceedings/97/agenda/agenda-97-tls-00.txt I’ll post slides as I get them; I’ll take pdf, ppt/pptx, and links to gSlides and the earlier I get them the better. spt ___ TLS mailing list TLS@ietf.org

Re: [TLS] how close are we?

> On Oct 11, 2016, at 23:21, Peter Gutmann wrote: > > Xiaoyin Liu writes: > >> Not directly related to Rich's question, but will we settle the "TLS 1.3 -> >> TLS 2.0" >> discussion (PR #612) before WGLC? Or has this already been closed as

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

Al, David Garrett has generated PR#634 (https://github.com/tlswg/tls13-spec/pull/634) to "explicitly [rename] the protocol version fields as IDs and defines a registry for all values, as they're really just arbitrary codepoints at this point.” Note that there are no bits on the wire changes

[TLS] PR #672: Finished Stuffing/PSK Binder

All, We’re looking to land PR#672 (aka Finished Stuffing/PSK Binder): https://github.com/tlswg/tls13-spec/pull/672 It looks there’s been some discussion, but that the issues have been largely resolved. Please send any comments you have by Friday (10/14) so that we can address them. Barring

[TLS] WG adoption call: draft-thomson-tls-tls13-vectors

All, There’s been some interest on the list and more in Seoul to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS WG item. We marked the draft as a "Candidate for WG Adoption” in the datatracker, but now it’s time to officially do the WG call for adoption. So,

[TLS] WG adoption call: draft-davidben-tls-grease

All, There’s been some interest on the list in http://datatracker.ietf.org/doc/draft-davidben-tls-grease/ (aka Applying Generate Random Extensions And Sustain Extensibility to TLS Extensibility). We’d like to determine whether there’s enough interest to adopt the draft as a WG item. So, if

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

Just a reminder that this WGLC will close on Friday December 9th. spt > On Nov 18, 2016, at 18:55, Sean Turner <s...@sn3rd.com> wrote: > > All, > > This is a working group last call for the “4492bis to Standards Track" draft > available @ http://datatracke

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

At this point I don’t think it’s December 2nd anywhere in the world, so it’s time to close this thread. Joe and I will take a couple of days to review the 130+ messages. spt > On Nov 17, 2016, at 21:12, Sean Turner <s...@sn3rd.com> wrote: > > At IETF 97, the chairs le

Re: [TLS] adopted: draft-thomson-tls-tls13-vectors

ssues can be opened here: > https://github.com/tlswg/draft-ietf-tls-tls13-vectors > > The editor's copy is here: > https://tlswg.github.io/draft-ietf-tls-tls13-vectors/ > > On 4 January 2017 at 00:59, Sean Turner <s...@sn3rd.com> wrote: >> I appears that we’ve got en

[TLS] adopted: draft-thomson-tls-tls13-vectors

I appears that we’ve got enough consensus/interest to adopt draft-thomson-tls-tls13-vectors based on this thread: https://mailarchive.ietf.org/arch/msg/tls/LOS06OPDeLOrdtE8QoBLXEHO51s Martin, Please submit draft-ietf-tls-tls13-vectors at your earliest convenience. I’ll set up a tlswg repo in

  1   2   3   4   5   6   >