Re: [TLS] SPKI Fingerprints

at 11:56 AM Viktor Dukhovni wrote: > On Mon, Jun 13, 2022 at 10:42:51AM -0400, Daniel Migault wrote: > > > I sent this question regarding the use of SPKI Fingerprints to the > > add mailing list, but I am also eventually interested to feed backs not > > necessarily restricte

[TLS] SPKI Fingerprints

in RFC7469 (public KEy Pinning extension for HTTP). I am wondering if anyone is aware of implementation considering SPKI Fingerprints for or if such usage is not something we would like to recommend/deprecate. Yours, Daniel -- Daniel Migault Ericsson

Re: [TLS] progressing draft-ietf-tls-md5-sha1-deprecate

/15 > > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/14 > > These are addressed in this PR: > > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/20 > > > > These ought to all be non-controversial, so we will

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

ly and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Heads up on Netdev conf 0x15 - not too late to attend!

On Monday as well there will be an industry perspectives panel on smartnics which will involve 6 vendors and an industry veteran moderating the session. For registration go here: https://netdevconf.info/0x15/virtual.html Yours, Daniel -- Daniel Migault Ericsson

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Hi, Thanks Logan for posting the new version. I am trying to summarize where we are with version 07. I think there is one remaining concern that has not been addressed, though it is not clear to me how we agreed to address it. Yours, Daniel On Tue, May 4, 2021 at 11:17 PM Daniel Migault wrote

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

e text to move this along. Apologies > in advance: this is a long email. Once we settle on the text, I can submit > PRs. > > spt > > > On Sep 14, 2020, at 11:11, Daniel Migault wrote: > > > > Hi Nick, > > > > Thanks for the response and I apologize

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

: > Daniel, > > Thanks for your (and the WG’s) patience on this. Responses in line. > > spt > > > On Apr 9, 2021, at 14:54, Sean Turner wrote: > >> On Jan 22, 2021, at 08:23, Daniel Migault wrote: > >> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron &

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

ay take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >>

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron wrote: > On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault > wrote: > > > > Hi, > > > > I apology for responding so late - I missed the thread. I want this > document to be moved forward but so far I do not

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

can be achieved reasonably. Yours, Daniel On Tue, Oct 27, 2020 at 11:34 PM Sean Turner wrote: > > Please note the comment about Section 3 suggests changing server behavior > from SHOULD NOT to a MUST NOT. > > > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker < >

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

. In some cases specific extensions, cipher suites - not referenced by IANA as recommended - will be needed to address specific corner cases. Yours, Daniel On Tue, Oct 27, 2020 at 11:32 PM Sean Turner wrote: > > > > On Oct 27, 2020, at 10:32, Daniel Migault wrote: > > > >

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

negligible. """ As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a review of impacted IoT protocols if those algorithms are deprecated. """ Yours, Daniel On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker < nore...@ietf.org>

[TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

Reviewer: Daniel Migault Review result: Ready with Nits Hi, I reviewed this document as part of the IoT Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors

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

Hi Ilari, Thanks for the feed back. PLease see my comments inline. Yours, Daniel On Wed, Sep 16, 2020 at 8:29 AM Ilari Liusvaara wrote: > On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote: > > Hi Nick, > > > > Thanks for the response and I apologize fo

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

> https://github.com/tlswg/tls-subcerts/pull/80 > > On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault 40ericsson@dmarc.ietf.org> wrote: > >> Hi, >> >> The draft has a number of nits and errors. Among others: >> >> The related work section mention

Re: [TLS] Adoption call for draft-rescorla-tls-rfc8446-bis

________ >>>> >>>> >>>> TLS mailing list >>>> >>>> >>>> TLS@ietf.org >>>> >>>> >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>>> >>> >>> ___ >>> >>> TLS mailing list >>> >>> TLS@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

etf-tls-subcerts-07.txt >> [Side-by-side Diff] >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt=draft-ietf-tls-subcerts-07.txt >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.iet

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

Hi Joe, Thanks for the feed back, please find my responses inline. Yours, Daniel From: Joseph Salowey Sent: Monday, June 29, 2020 10:01 PM To: Daniel Migault Cc: Salz, Rich ; Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS HI Daniel Some

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

Hi, The draft has a number of nits and errors. Among others: The related work section mentions KEYLESS and subcert being complementary that is KEYLESS can perform the operations associated to the DC and/or those associated to the cert key. I do not think that is correct. KEYLESS does not

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/ > [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/ > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] progressing draft-ietf-tls-ticket-request

-Df9xQy0bocg/ > [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Netdev 0x14 co-located with IETF107

https://netdevconf.info/0x14/news.html?schedule-up [2] https://netdevconf.info/0x14/schedule.html [3] https://netdevconf.info/0x14/registration.html On Thu, Feb 13, 2020 at 8:35 PM Daniel Migault wrote: > Hi, > > This is just to let you know that Netdev 0x14 is back co-locati

[TLS] Netdev 0x14 co-located with IETF107

Hi, This is just to let you know that Netdev 0x14 is back co-locating with IETF 107 in Vancouver. There are several security related talks that may be of interest.. Note: Early bird registration is still open until 17th and that many other talks, sessions, workshops are also happening

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

12:02 AM Eric Rescorla wrote: > > > On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre wrote: > >> On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault > 40ericsson@dmarc.ietf.org> wrote: >> >>> >>> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: >>>

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

On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: > > On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > > > I would make several points here: > > > > > > 1. RFC 8446 explicitly discourages ticket reuse > > >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we

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

On Fri, Jan 31, 2020 at 9:14 PM Stephen Farrell wrote: > > Hiya, > > I have no particular position about this draft but > am curious about 2 things: > > #1 I don't get why it's not possible for postfix to > determine the best way to manage tickets based on the > destination port to which the

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

On Fri, Jan 31, 2020 at 8:16 PM Rob Sayre wrote: > On Fri, Jan 31, 2020 at 5:11 PM Nico Williams > wrote: > >> On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote: >> > On Fri, Jan 31, 2020 at 3:56 PM Nico Williams >> wrote: >> > > Viktor's comment came before the end of WGLC, so the WG

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

I support the proposal from Viktor. It is important to minimize the involved resource and provide the client the ability to explicitly inform the server its policy. As explained above, this mechanism comes with no additional complexity and address a full range of applications. See below my

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

the document. Yours, Daniel [1] https://mailarchive.ietf.org/arch/msg/tls/7Z0p1O2GzN52ztq46KdzpBVX0Hw On Mon, Nov 25, 2019 at 12:04 PM Daniel Migault wrote: > > > On Wed, Nov 20, 2019 at 10:20 PM David Schinazi > wrote: > >> Hi folks, >> >> I've chatted with Daniel and

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

y reading is essentially a replacement for 6lowpan. > Unfortunately, this design decision does not make it a well suited > mechanism for a generic compression mechanism. I am happy to get convinced > otherwise. > > > > Ciao > > Hannes > > > > *From:* TLS *On Beha

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

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

I clearly support the adoption of the work, but it seems important to ensure cTLS integrates or remains in line with the work on compression that has been accomplished at the IETF - SCHC defined in lpwan might be a starting point. It also seems important to me that cTLS defines mechanisms that

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

Hi, Just to followup the discussion. I support Viktor,'s proposal as it provides the ability to the client to specify what it wants rather than let the server guess. What I am wondering is whether we are catching all possible client "policies" or whether we should consider some additional

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

Daniel On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario wrote: > On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote: > > Hi Hubert, > > > > On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario wrote: > > > >> On Thursday, 14 November 2019 18:18:5

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

ber 2019 17:19:55 CET, Daniel Migault wrote: > > Hi Chris, > > > > Thanks for the responses, please see my comments inline. > > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood > > wrote: > >

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

. On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood wrote: > On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote: > > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > > > If tickets are sent right after the server Finished, before the the > > > clie

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

M, Daniel Migault wrote: > > Hi Chris, > > > > Thanks for the responses, please see my comments inline. > > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood > wrote: > > > On Thu, Nov 14, 2019, at 7:50 AM, Dan

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

Hi Chris, Thanks for the responses, please see my comments inline. Yours, Daniel On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood wrote: > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > > Hi, > > > > The current version is clearer than the previo

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

> ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

her Wood wrote: > > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario > wrote: > > > > > On Wednesday, 2 October 2019 22:42:32 CES

Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

Hi, For clarity to the WG I am summarizing the discussion of the "lesson learnt from deprecation" thread. There is in my opinion a consensus that the current text does not emphasize enough that TLS 1.3 is the current version of TLS. There is also a consensus that the current draft limits the

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

Hi Hubert, I agree. Yours, Daniel On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario wrote: > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migaul

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

On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is correct, > >

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

Hi, Please see my comments. Yours, Daniel On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote: > Hi Daniel, > > Please see inline below. > > On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > > Hi, > > > > Please find some comments on the draft. >

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

g" >> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation >> >> So I agree with Kathleen's conclusion: not to change the goals of the >> current document. But there are changes that I think are necessary (and >> thanks to Daniel and John

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Hi, Maybe I am missing the point, but I do not see any reasons to not explicitly recommend adoption of the latest version (i.e. TLS 1.3). While the document deprecates old version, providing explicitly the status of the non deprecated versions seems to me in scope of the document. As such,

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

ocused. > > On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote: > > My understanding of deprecating of TLS1.0 TLS 1.1 is that: > > a) new software do not use these versions > > b) existing software stop supporting these versions. > > That differs from my perspecti

Re: [TLS] [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Hi, My understanding of deprecating of TLS1.0 TLS 1.1 is that: a) new software do not use these versions b) existing software stop supporting these versions. I am not sure how likely a new software is to use TLS 1.0 or TLS 1.1 with TLS 1.2 and TLS 1.3 being widely deployed. It seems also a

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Thanks for raising this discussion John, we have been struggling with this in curdle as well and ipsecme. This is also a topic that I believe would be useful to improve the security. One aspect is that some implementers go to the IANA pages and believe that everything on the pages is acceptable.

Re: [TLS] The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state "Call For Adoption By WG Issued"

I support the adoption of the draft. Yours, Daniel On Wed, Jul 24, 2019 at 9:42 AM IETF Secretariat < ietf-secretariat-re...@ietf.org> wrote: > > The TLS WG has placed draft-lvelvindron-tls-md5-sha1-deprecate in state > Call For Adoption By WG Issued (entered by Sean Turner) > > The document is

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

On Tue, May 14, 2019 at 2:27 PM Hubert Kario wrote: > On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote: > > section 2: > > > > I am wondering whether SHOULD NOT could be replaced by MUST NOT. On the > > one hand, deprecation should be smooth, but on th

Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

Hi, Please find some comments. Yours, Daniel Introduction I would suggest a reference to rfc6194 for sha1 digest as well as for hmac-sha1. I believe more text in the introduction may be needed to expose how the document impacts TLS 1.2. Typically, the impacted structure is HashAlgorithm,

Re: [TLS] RFC8446 Fig3

is complete, as > this doesn't show the supported_versions or signature_schemes extension > either, but the omission is probably not great in this case, since the PSK > modes are highly relevant. > > On Fri, May 3, 2019, at 10:30, Daniel Migault wrote: > > Hi, > > > > This

[TLS] RFC8446 Fig3

Hi, This might have already been mentioned on the list, but unless I misinterpreter something it seems to me that the second handshake of figure 3 is missing psk_key_exchange_modes extension. Yours, Daniel Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK

Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

I believe the doc is fine as it is. Yours, Daniel On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni wrote: > > On Apr 12, 2019, at 7:28 PM, Christopher Wood > wrote: > > > > This is the working group last call for the "Deprecating TLSv1.0 and > TLSv1.1” draft available at: > > > > >

[TLS] netdev0x13 - ietf related topics

Hi, Please find among many others some IETF related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues. Early bird registration is open until February 20. Netdev 0x13 will be held at Hotel Grandium in Prague,

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

I support the adoption as well, we need it for lurk. Yours, Daniel On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich wrote: > I support adoption and I am sure OpenSSL will implement, or I will do it > and make a PR. > > ___ > TLS mailing list > TLS@ietf.org >

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

I support the adoption. Yours, Daniel On Sat, Aug 18, 2018 at 7:53 AM, Ira McDonald wrote: > I support adoption. > > - Ira > > > On Fri, Aug 17, 2018 at 1:32 PM, Sean Turner wrote: > >> At the TLS@IETF102 session, there seemed to be some interest in adopting >>

Re: [TLS] Enforcing Protocol Invariants

hould hopefully be more resilient to > this sort of misbehavior. On the flip side, it is more work to maintain and > only implementations that update sufficiently frequently can participate, > whereas, in theory, anyone could deploy the original GREASE. > > On Wed, Jun 13, 2018 a

Re: [TLS] Enforcing Protocol Invariants

I also support something is being done in this direction. I like the idea of taking ephemeral non allocated code points. What is not so clear to me is how GREASE prevents a buggy implementations from behaving correctly for GREASE allocated code points, while remaining buggy for the other

Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

IESG approval seems also fine to me. Hopefully ciphers may not be used at the time they are deprecated. Yours, Daniel On Wed, Nov 22, 2017 at 12:13 PM, Sean Turner wrote: > Funny I never thought about going down, but I guess we should ;) I think > the premise we want here is

Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

Hi Eric, Thank you for reviewing the document. Given your second comment, I suspect you are reading the version 04 while the current version is version 05 [1]. I believe your comments have been addressed in the version 05.However let me know if you have other concerns. Regarding TLS1.3. we were

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

Mattsson <john.matts...@ericsson.com>; Daniel Migault <daniel.miga...@ericsson.com> Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-05.txt A new version of I-D, draft-ietf-tls-ecdhe-psk-aead-05.txt has been successfully submitted by Daniel Migault and posted

Re: [TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Thanks Spencer for your review. Actually the scope has always been TLS1.2 only. I confirm version 05 have addressed Erik's comments. Yours, Daniel On Wed, May 24, 2017 at 4:03 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > On Wed, May 24, 2017 at 4:49 PM, Spencer Dawkins >

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

>From your response I understand you do not request changes. Yours, Daniel On Wed, May 24, 2017 at 4:24 PM, Martin Thomson wrote: > On 25 May 2017 at 07:14, Joseph Salowey wrote: > > [Joe] It seems that a reasonable interpretation of the text is that

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

SHA256 and TLS_AES_128_CCM_SHA256 are used to support > equivalent functionality in TLS 1.3 [TLS 1.3]." > > Thanks, > > Joe > > > On Wed, May 24, 2017 at 7:04 AM, Daniel Migault < > daniel.miga...@ericsson.com> wrote: > >> Hi Martin, >> >> T

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

would like to see. """ 3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites The cipher suites defined in this document are based on the AES-GCM and AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_1

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

ng those defined in this document, SHOULD NOT be negotiated in TLS versions prior to 1.2. """ On Tue, May 23, 2017 at 10:48 PM, Adam Roach <a...@nostrum.com> wrote: > On 5/23/17 9:33 PM, Daniel Migault wrote: > >> The current version does not consider

Re: [TLS] Ben Campbell's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Hi, Thanks for your review. I believe version 05 address Eric comments.. Yours, Daniel On Tue, May 23, 2017 at 6:12 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tls-ecdhe-psk-aead-04: No Objection > > When responding, please

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

re-sending with the version 05 but removing the diff to be under the 100 KB limit. Yours, Daniel On Tue, May 23, 2017 at 9:28 PM, Daniel Migault <daniel.miga...@ericsson.com > wrote: > Hi Eric, > > Thank you for the feed backs. The version 05 contains all text changes you > a

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

, May 23, 2017 at 7:10 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 24 May 2017 at 08:04, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > So I have propose a fall back to the latest version. However, if we agree > > this is a better approach, I am

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Thank you for the clarifying text. I have added it on my local copy. Yours, Daniel On Mon, May 22, 2017 at 1:35 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > Sorry for the slow reply. > > On Fri, May 19, 2017 at 12:58:07PM -0400, Daniel Migault wrote: > > Thank you, > >

Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Hi, So I have propose a fall back to the latest version. However, if we agree this is a better approach, I am fine adding it to the document. Yours, Daniel On Tue, May 23, 2017 at 3:34 PM, Martin Rex wrote: > Adam Roach wrote: > > draft-ietf-tls-ecdhe-psk-aead-04: No Objection >

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

Hi Eric, Thank you for your reviews. Please see my responses inline. If you agree with the text I will update the draft. Yours, Daniel On Mon, May 22, 2017 at 10:11 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for >

Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

stinct properties. > > s/pre-master/ECDHE shared secret/? > > -Ben > > > On 05/19/2017 03:18 PM, Daniel Migault wrote: > > Hi, > > Thank you to all reviewers for their feed backs. Please find the latest > version, which as far as I know includes all commen

[TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt

@ietf.org [mailto:internet-dra...@ietf.org] Sent: Friday, May 19, 2017 4:03 PM To: John Mattsson <john.matts...@ericsson.com>; Daniel Migault <daniel.miga...@ericsson.com>; tls-cha...@ietf.org Subject: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt A new version of

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

and TLS1.1 MUST NOT be used with these ciphersuites, so maybe the SHOULD NOT in the last sentence is not quite what is intended.) On Fri, May 19, 2017 at 12:27 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > On Fri, May 19, 2017 at 11:55:35AM -0400, Daniel Migault wrote: > >

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Hi Martin, Thank you for the proposed text. It was very clear and I took it entirely, just changing s/TLSv1/TLS 1/. Yours, Daniel The current text is as follows: The cipher suites defined in this document MUST NOT be negotiated for any version of (D)TLS other than TLS 1.2. TLS version

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Hi Benjamin and Dave, Thanks for the clarification. Considering also Roman' s and Ben' s comments the section is built as follow. 1) Limit cipher suites to TLS1.2, 2) explain how TLS1.3 and higher version negotiate them 3) bring all explanation foe the previous versions. Yours, Daniel The text

Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

Hi Benjamin, Thank you for the review. Please find my comments inline and let me know if you agree with the proposed text. I believe the only point not addressed concerns the addition of CCM-256 which has been remove after discussion during the WGLC. Thanks you for the review, Yours, Daniel On

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

Thanks for the feed backs. I have found two occurrences of perfect forward secrecy which have been changed to forward secrecy. Yours, Daniel On Thu, May 18, 2017 at 5:51 PM, Viktor Dukhovni wrote: > > > On May 18, 2017, at 5:30 PM, Eric Rescorla wrote: >

Re: [TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard

Hi Simon, Thank you for the review. I believe we have addressed your comments in our version 04. Please see my comments inline. Yours, Daniel -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Simon Friedberger Sent: Thursday, May 04, 2017 5:59 PM To:

Re: [TLS] Genart last call review of draft-ietf-tls-ecdhe-psk-aead-03

Hi Dan, Thank you for your reviews and comments. I believe the following text provides more explanation on how the provided cipher suites are negotiated by TLS1.3 as well as why point codes defined in the document does not apply to TLS1.3. Feel free to let me know if that address your concern

Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

7:46 AM To: Daniel Migault <daniel.miga...@ericsson.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02 Hi Daniel, Thank you, please publish version 3 and I'll kick off last call. You could update the TLS version to 20 a

Re: [TLS] AD review of draft-ietf-tls-ecdhe-psk-aead-02

Hi Kathleen, Thank you for the review. I have proceeded to the update of my local copy. The text is: """ The cipher suite numbers listed in the last column are numbers used for cipher suite interoperability testing and it's suggested that IANA use these values for assignment. """ Other nits

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

Hi, I am in favor of adoption of the draft. This is an important issue we need to address. Yours, Daniel On Wed, Apr 12, 2017 at 3:31 PM, Sean Turner wrote: > All, > > At our IETF 98 session, there was support in the room to adopt > draft-rescorla-tls-subcerts [0]. We need to

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

> > Joe > > > On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault < > daniel.miga...@ericsson.com> wrote: > >> Hi, >> >> Thank you for the review and comments received. Given the discussion our >> understanding was that the consensus was to remove CCM-256

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

Hi, Thank you for the review and comments received. Given the discussion our understanding was that the consensus was to remove CCM-256 so that suites defined by the document apply both for TLS1.2 as well as for TLS1.3. The draft available on github [1

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

I have a small preference for TLS 1.3. On Tue, Nov 22, 2016 at 10:04 AM, Scott Schmit wrote: > On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else.

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

, Martin Thomson <martin.thom...@gmail.com> wrote: > On 8 November 2016 at 21:08, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > TLS enable curve negotiation but not for code point. This makes > restrictions > > on code points hard to implement.

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

done. Thanks for the review! Yours Daniel On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote: > > Hi, > > > > The current draft is only considering TLS1.

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

Mavrogiannopoulos <n...@redhat.com> wrote: > On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > > > Regarding Niko, my understanding is that the WG preferred not to have > > the definition of profiles in this document. I am not sure you wanted > >

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

Hi, The current draft is only considering TLS1.2. TLS1.3 is only mentioned for advocating AEAD. Do you think we should add text that details how to proceed with TLS1.3 ? If so what do you think of the following text ? Comments are welcome! Yours, Daniel The assigned code points are only

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

Hi, My understanding is that the updated version should not introduce any profile. Am I correct ? BR, Daniel On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.miga...@ericsson.com > wrote: > Hi, > > I am not very clear on how to update the text of the draft. The proble

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

D0,0x03}; > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04}; > > > Russ > > > On Oct 17, 2016, at 12:03 PM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi, > > I am not clear what the consensus is for the f

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

Hi, I am not very clear on how to update the text of the draft. The problem seems to me that code point restriction are hard to implement. As a result, the session is aborted with - insufficient_security(71) or equivalent - when the code point does not match the security strength. I am encline to

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

Hi, I am not clear what the consensus is for the following points. Is there any consensus for requesting the following ones? BR, Daniel TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x01}; TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD; 0xTBD} {0xD0,0x02};

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

I support the adoption of the draft. On Mon, Apr 25, 2016 at 1:53 PM, Salz, Rich wrote: > I support adoption. > > -- > Senior Architect, Akamai Technologies > IM: richs...@jabber.at Twitter: RichSalz > > > ___ > TLS mailing list >

Re: [TLS] New Version Notification for draft-cairns-tls-session-key-interface-01.txt

Cairns; John Mattsson; Daniel Migault; Robert Skog Subject: New Version Notification for draft-cairns-tls-session-key-interface-01.txt A new version of I-D, draft-cairns-tls-session-key-interface-01.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name

  1   2   >