Re: [TLS] I-D on TLS authentication with VC

Hi Andrea thanks for the extra background. How do you plan to deal with the large number of DID methods? Standardization of many of the DID methods has not been finished and they appear to have vastly different security properties, even for the most basic DID methods like did:web and did:key.

Re: [TLS] I-D on TLS authentication with VC

Hi Andrea, Thanks for sharing the info. Could you say a bit more about your IoT use case? Ciao Hannes -Original Message- From: TLS On Behalf Of Andrea Vesco Sent: Donnerstag, 4. April 2024 10:53 To: tls@ietf.org Subject: [TLS] I-D on TLS authentication with VC L. Perugini and I have

Re: [TLS] Key Update for TLS/DTLS 1.3

Hi Scott, thanks for your feedback. Introducing PQC algorithms in the design for this proposal has not been discussed in TSVWG design team and has therefore not been a requirement for me. (Maybe my co-authors see this differently.) I will bring this topic up in the next design team call. In

Re: [TLS] Key Update for TLS/DTLS 1.3

Hi Ilari, thanks for your feedback. A few remarks below. Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara: On Fri, Jan 05, 2024 at 03:11:37PM +, Fries, Steffen wrote: Hi David, In addition to what Hannes stated, the alternative in Appendix B was the result of further thoughts on

Re: [TLS] TLS Suite Naming Conventions

Hi Orie, I am not sure whether the comparison between JOSE/COSE and TLS is appropriate when the latter uses a handshake and the former is a one-shot message (or a payload). In a TLS handshake there are so many things that get negotiated, such as the algorithms and parameters for protecting the

Re: [TLS] Key Update for TLS/DTLS 1.3

Nicely written, Ilari. Additionally, there is this patent for such a key update by John, Magnus and Claudio written for the SCTP context: https://datatracker.ietf.org/ipr/6218/ Ciao Hannes Am 04.01.2024 um 18:37 schrieb Ilari Liusvaara: On Thu, Jan 04, 2024 at 04:26:09PM +, Dennis

Re: [TLS] Key Update for TLS/DTLS 1.3

Hi David, thanks for sharing your thoughts. Here is the approach I had in mind: the application code needs to trigger the TLS/DTLS stack to start the extended key update. For the TLS 1.3 code I wrote, that's the approach I took for the regular TLS 1.3 key update as well. In the use cases I

Re: [TLS] Key Update for TLS/DTLS 1.3

Hi Ilari, thanks again for the super quick feedback. Remarks below: Am 04.01.2024 um 14:53 schrieb Ilari Liusvaara: On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote: Hi all, we have just submitted a draft that extends the key update functionality of TLS/DTLS 1.3. We call

Re: [TLS] Key Update for TLS/DTLS 1.3

Hi Thom thanks for the quick review. Directionality of the extended key updates: I should be more clear in the examples and in the write-up that these key updates can be initiated by both parties. Description about when the keys can be deleted: I will re-review the text again to improve the

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

>From my experience, it is possible to update the firmware on many modern >constrained IoT devices, including the TLS / DTLS stack, today. Of course, >there are a lot of devices out there where updating the firmware involves >physical access by some technician. However, there are a few other

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Hi Rich, that is implied by a "feature freeze". No reason to highlight PQC (even though it is a hype topic right now). Ciao Hannes Am 11.12.2023 um 17:18 schrieb Salz, Rich: * I consider Section 3 "Implications for post-quantum cryptography" misplaced. I suggest to delete the

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

I consider Section 3 "Implications for post-quantum cryptography" misplaced. I suggest to delete the section The motivation for the draft is unrelated to developments with PQC. Ciao Hannes Am 11.12.2023 um 11:59 schrieb Bas Westerbaan: I support adoption, and am happy to review. Best,  

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

FWIW I have been working on synthetic TLS benchmarks as part of work in the Embedded Microprocessor Benchmark Consortium. I presented about the work in SAAG twice: here is the first presentation https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-iot-benchmarking-00 and here is

Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS /QUIC.

Adding to the response: As with all TLS extensions, if endpoint A depends on a feature but endpoint B does not support the feature then the exchange has to be terminated. CIDs are not different from other extensions. It is, however, quite likely that an application will still work without the

[TLS] draft-fossati-tls-attestation-02

Hi all, at the last IETF meeting I gave a presentation about the TLS attestation draft. Based on the feedback we have made several changes: * The design is attestation-technology agnostic. * This version focuses on the background check model and the transfer of evidence from the

Re: [TLS] Securely disabling ECH

Giving someone, other than those managing the endpoints, the ability to disable a security feature like ECH is problematic. If I read your email correctly then I believe that’s what you are suggesting. I hope I am missing something. Ciao Hannes From: TLS On Behalf Of Safe Browsing Sent:

Re: [TLS] Securely disabling ECH

“Authoritative” is not the same as having “a valid TLS certificate for the server”. Everyone can get the certificate of a TLS server. From: TLS On Behalf Of ietf=40dennis-jackson...@dmarc.ietf.org Sent: Monday, October 10, 2022 10:15 AM To: tls@ietf.org Subject: Re: [TLS] Securely disabling

Re: [TLS] SCHC for DTLS

Bob, is this about compressing the DTLS record layer or the DTLS handshake protocol? For the former, I wonder how much is there actually to compress (when using DTLS 1.3)? From: TLS On Behalf Of Eric Rescorla Sent: Friday, May 27, 2022 5:30 PM To: Robert Moskowitz Cc: Subject: Re: [TLS]

Re: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

Hi Sean, Hi all, I think the document should also include a reference to DTLS since there is no reason that sub-certs do not apply to DTLS as well. Ciao Hannes -Original Message- From: TLS On Behalf Of Sean Turner Sent: Wednesday, February 16, 2022 9:26 PM To: TLS List Subject:

Re: [TLS] OCSP in RFC7525bis

, January 20, 2022 3:18 PM To: Hannes Tschofenig ; u...@ietf.org; tls@ietf.org Subject: Re: OCSP in RFC7525bis Hi Hannes, This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends

Re: [TLS] OCSP in RFC7525bis

Hi Yaron, Where do you believe OCSP will be a good fit and why? Ciao Hannes From: TLS On Behalf Of Yaron Sheffer Sent: Wednesday, January 19, 2022 3:57 PM To: u...@ietf.org; tls@ietf.org Subject: [TLS] OCSP in RFC7525bis Hi, RFC 7525 (the TLS BCP) has a section [1] with “weak”

Re: [TLS] Does revocation matter?

Hey Felipe There are three key questions when it comes to revocation checking, namely: * What is the TLS stack being used for? * What would the device do when a revocation check fails? * How are the certificates and trust anchors managed? You mentioned Mbed TLS. It is used for embedded devices.

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

ny easier. Ciao Hannes On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> wrote: The term “obsolete” appears to be used incorrectly when it comes to TLS/DTLS 1.2 used in the IoT environment. It is widely used today and I expect it to be used f

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

lso offers suitable performance. There is a well-tested open source codebase available for TLS/DTLS 1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge the speed at which the market operates. From: John Mattsson Sent: Thursday, November 4, 2021 2:11 PM To: Hannes Tschofe

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

something entirely different for DTLS 1.2? -Original Message- From: Sean Turner Sent: Thursday, November 4, 2021 2:27 PM To: Hannes Tschofenig Cc: TLS List Subject: Re: [TLS] Flags Extension: why only for TLS 1.3? Hannes, Sorry I forgot to answer this, but John pretty much answered

Re: [TLS] TLS Flags and IANA registration policy

Rich, this makes more sense. Maybe the column should say "IETF Consensus" (Y/N) instead of Recommended. In any case, the draft should say what recommended means for the flags values. -Original Message- From: TLS On Behalf Of Salz, Rich Sent: Tuesday, October 26, 2021 3:19 PM To: Ilari

Re: [TLS] TLS Flags and IANA registration policy

Hi Ilari, > "If an item is not marked as 'Recommended', it does not necessarily mean that > it is flawed; rather, it indicates that the item either has not been through > the IETF consensus process, has limited applicability, or is intended only > for specific use cases." I think the flags

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

Hi all, why is the flags extension only defined for TLS 1.3? There is nothing in this extension that prevents us from using it also in TLS 1.2. Could we make it also available to TLS 1.2? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may

[TLS] TLS Flags and IANA registration policy

Hi all, https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags gives guidance on registering values in the TLS Flags namespace. One of the field is the "Recommended" field and it is described as follows: " o Recommended, which is a Y/N value determined in the document defining the

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

I have no problem with the suggestion. A few other observations: 1. FWIW: The reference to [Wang] is incomplete. 2. The references to the other papers use the websites of the authors or project websites. I would use more stable references. 3. Kathleen's affiliation is also outdated. 4. Is

Re: [TLS] What's it called

Depends on the algorithm and its parameters. Here is a recent document talking about AES algorithms limits. https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-02 From: TLS On Behalf Of Tim Bray Sent: Thursday, June 24, 2021 9:13 PM To: Paterson Kenneth Cc: tls@ietf.org; Salz,

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

Hi Sean, Thanks for keeping track of the backlog of drafts. I am still interested to do this work and I contributed to the draft because a generic mechanism for doing the return routability check is better than pushing the responsibility to the application layer. There is always the risk that

Re: [TLS] [Technical Errata Reported] RFC5246 (6572)

Hi Johannes, TLS 1.2 has been obsoleted by TLS 1.3. Prior to this, other specifications have profiles the algorithm choice (see RFC 7525 and RFC 7925). Ciao Hannes -Original Message- From: TLS On Behalf Of RFC Errata System Sent: Wednesday, May 5, 2021 12:21 PM To: t...@dierks.org;

Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Hi Martin, The attack described in Section 9.3.3 of https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a lot of assumptions about the attacker. I am not opposed to adding the recommendation but I want to understand it first since there is also a price to pay for it

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Hi John, [*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew obfuscation! Which one of these is clearer seems like a question of taste, I should think. It's worth noting that because the length prefix is determined by the ceiling, arguably 2^8-1 is clearer. I don’t

Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Hi Francesca, ~ snip ~ 5. - Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? [Hannes] Maybe someone responded already regarding this point. I don't know whether it is good or bad practice to provide all this background in the IANA considerations but the

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Hi John, Hi Ekr, Regarding the presentation language used in the document I have added a clarification to the terminology section, see https://github.com/tlswg/dtls-conn-id/pull/110. I hope this addresses the issue. Ciao Hannes From: Eric Rescorla Sent: Tuesday, April 20, 2021 11:32 PM To:

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

Hi John, Hi Ekr, I hope I correctly understand the essence of your conversation. I am wondering whether a link from the bullet list to the text two paragraphs down will help. Here is my proposal: https://github.com/tlswg/dtls-conn-id/pull/111 Ciao Hannes From: John Scudder Sent: Wednesday,

Re: [TLS] Transport Issues in DTLS 1.3

Hi Bill, > Are there any issues with space-based paths? I know Elon Musk is planning > Internet service via many LEO satellites. > > If we were talking about going to the moon, that would be a 3 second delay. > > Cheers - Bill There are profiles for TLS/DTLS for specific deployment

Re: [TLS] Transport Issues in DTLS 1.3

Hi Martin, the main issue Ekr is bringing up is that the DTLS handshake happens infrequently and it is small in size. The use of DTLS for protecting application traffic is not impacted by this timeout. Ciao Hannes -Original Message- From: Martin Duke Sent: Tuesday, March 30, 2021

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom, I added a few PRs to address your review (see https://github.com/tlswg/dtls-conn-id/pulls). Regarding the zero-length CID I believe the current version in the repo at https://github.com/tlswg/dtls-conn-id might have already address your remark. In general, the zero-length CID in the

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Graham, Deb, * 'Expiry: for the server/client. I suspect this is mostly a 'don't care', except in the case where a certificate *should* be revoked after it is expired (nobody does that, right?). Is this worth addressing? I suspect not.' I agree. * I would imagine that the

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Focusing on one sentence from below: * I've found that the best method to prevent the device from connecting is for the certificate to be revoked, the CRL refreshed and then a re-authentication performed on all active connections. Why would you trigger re-authentication of all

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Nico raised some really good points here. I think it is useful to start with the problem description. It seems that you are concerned that there is a possibility for leakage or compromise of keying material during the lifetime of the session. What could happen? * Long-term keys*, * Some keys

[TLS] draft-friel-tls-eap-dpp-01

Hi all, I have watched the EMU presentation about draft-friel-tls-eap-dpp-01 at the last IETF meeting (see ) https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-dpp-00and, at that time, I was confused about the scope of the proposed work. Having read into the WiFi DPP

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

FWIW the current scheme described in https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable length encoded integers of one to three bytes. We need more than that. I am in favor of the “deterministic” version, if deterministic means no overlaps in the encoded number ranges.

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Hi Ekr, I had a chat with Richard about this and this change makes a lot of sense (particularly since the current cTLS draft only defines the encoding of varints up to 3 bytes). In the work on QUIC did you discuss the ability to make the encoding such that there are no ways to express a

Re: [TLS] The future of external PSK in TLS 1.3

. Ciao Hannes From: Rob Sayre Sent: Wednesday, September 30, 2020 10:20 AM To: Hannes Tschofenig Cc: Watson Ladd ; Blumenthal, Uri - 0553 - MITLL ; tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig mailto:hannes.tschofe

Re: [TLS] The future of external PSK in TLS 1.3

Hi Uri, I would even argue that key management is less challenging for IoT deployments because devices typically talk to a single device management server only. So, the communication patterns are pretty simplistic compared to a generic computing device. RFC 7452 talks about this topic (see the

Re: [TLS] The future of external PSK in TLS 1.3

Hi Watson, through Arm I deal with customers who use microcontrollers that have all sorts of limitations. So, the question is not so much whether these limitations exist but rather whether you care and what exactly these limitations are (CPU processing, RAM, flash memory, energy, networking

Re: [TLS] TLS 1.3 Problem?

Hi Mike, > I felt that I was unwelcome in this group by some of the "angry > cryptographers" as I call them. No reason to worry. Luckily, we don't have any angry cryptographers in this group. On top of what Richard mentioned in his response, take a look at Appendix D of the spec, see

Re: [TLS] The future of external PSK in TLS 1.3

- From: Peter Gutmann Sent: Thursday, September 24, 2020 12:02 PM To: Filippo Valsorda ; Hannes Tschofenig ; Carrick Bartle Cc: tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda writes: >The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/

Re: [TLS] The future of external PSK in TLS 1.3

: Wednesday, September 23, 2020 5:47 PM To: Salz, Rich Cc: Hannes Tschofenig ; Filippo Valsorda ; Carrick Bartle ; tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 There are two different code points involved in TLS 1.3 PSK, and I think there may be some mixup here: 1. Whether

Re: [TLS] The future of external PSK in TLS 1.3

20 3:39 PM To: Hannes Tschofenig ; Carrick Bartle Cc: tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 2020-09-23 13:49 GMT+02:00 Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>: Hi Carrick, you note that SCADA is a pretty specific use case. SCADA sounds s

Re: [TLS] The future of external PSK in TLS 1.3

ision to remove PSK support. That’s good for them. Does this imply that the TLS group also needs to make the same decision? Ciao Hannes From: Carrick Bartle Sent: Monday, September 21, 2020 6:19 PM To: Hannes Tschofenig Cc: Carrick Bartle ; Filippo Valsorda ; tls@ietf.org Subject: Re: [TLS] Th

Re: [TLS] The future of external PSK in TLS 1.3

public keys, and certificates as I noted in my mail to the UTA list: https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/ Ciao Hannes From: Pascal Urien Sent: Monday, September 21, 2020 2:01 PM To: Hannes Tschofenig Cc: Filippo Valsorda ; tls@ietf.org Subject: Re: [TLS

Re: [TLS] The future of external PSK in TLS 1.3

: Monday, September 21, 2020 11:44 AM To: Hannes Tschofenig Cc: Filippo Valsorda ; tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 Hi All Here is an example of PSK+ECDHE for IoT https://tools.ietf.org/html/draft-urien-tls-se-00 uses TLS1.3 server PSK+ECDHE for secure

Re: [TLS] The future of external PSK in TLS 1.3

Hi Filippo, * Indeed, if the SCADA industry has a particular need, they should profile TLS for use in that industry, and not require we change the recommendation for the open Internet. We have an IoT profile for TLS and it talks about the use of PSK, see

Re: [TLS] The future of external PSK in TLS 1.3

Hi Carrick, Can you justify your reasoning? The challenge I have with the work on IoT in the IETF that the preferences for pretty much everything changes on a regular basis. I don't see a problem that requires a change. In fact, I have just posted a mail to the UTA list that gives an overview

Re: [TLS] The future of external PSK in TLS 1.3

John, The use of plain PSK makes a lot of sense because it provides the lowest footprint solution for really constrained systems. Given that the LAKE group wanted to focus on constrained IoT devices makes the decision by the group questionable. As you know, TLS 1.3 merged the handling of PSKs

Re: [TLS] draft-ietf-tls-ticketrequests-05

Hi Ilari, Please see my comments below. -Original Message- From: ilariliusva...@welho.com Sent: Wednesday, July 1, 2020 8:49 PM To: Hannes Tschofenig Cc: Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05 On Wed, Jul 01, 2020 at 04:52:18PM +, Hannes Tschofenig wrote: > Hi To

Re: [TLS] Proposed change in TLS-Flags

iao Hannes Yoav > On 1 Jul 2020, at 19:00, Hannes Tschofenig wrote: > > One question: Wouldn’t you want to register a flag for "Post-Handshake Client > Authentication" in this document? > > Ciao > Hannes > > > From: TLS On Behalf Of Hannes Tschofeni

[TLS] draft-ietf-tls-ticketrequests-05

Hi Tommy, Hi David, Hi Chris, I read through the draft and have a few questions. 1) Is it really necessary for the client to use two values to differentiate the tickets it wants with a new session and with resumption. It feels a bit over-designed. I would just have one value and that alone

Re: [TLS] Proposed change in TLS-Flags

One question: Wouldn’t you want to register a flag for "Post-Handshake Client Authentication" in this document? Ciao Hannes From: TLS On Behalf Of Hannes Tschofenig Sent: Wednesday, July 1, 2020 5:55 PM To: Yoav Nir ; Subject: Re: [TLS] Proposed change in TLS-Flags Yoav,

Re: [TLS] Proposed change in TLS-Flags

Yoav, I looked at the draft and the PR. I am fine with the proposed changes. This is a short and useful draft. Ciao Hannes From: TLS On Behalf Of Yoav Nir Sent: Monday, June 29, 2020 11:34 PM To: Subject: [TLS] Proposed change in TLS-Flags Hi I’ve just submitted the following PR:

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

Hi Joe, Hi draft authors, I reviewed draft-ietf-tls-subcerts-09 and the document is well written and easy to understand. I have only a minor remark regarding the validity time of the delegated credential. In Section 3 you say " In the absence of an application profile standard

Re: [TLS] Banning implicit CIDs in DTLS

I also agree. Even without implicit CIDs we can still put multiple handshake messages into a single record. Hence, there is no performance problem. From: TLS On Behalf Of Richard Barnes Sent: Thursday, May 28, 2020 3:37 PM To: Christopher Wood Cc: TLS@ietf.org Subject: Re: [TLS] Banning

Re: [TLS] consensus call: changing cTLS and ECH to standards track

I have started working on the cTLS implementation and will continue doing so together with my co-worker Hanno. A bit more details: We have re-based the 1.3 implementation* to the development branch of Mbed TLS and we have refactored the code so that we can put a new messaging layer in

Re: [TLS] Choice of Additional Data Computation

Hi Ekr, * And I am proposing removing implicit CIDs That would be a bit unfortunate. When we put multiple DTLS records in a single UDP datagram then the CID in all but the first datagram is redundant*. Ciao Hannes (*): Even if we optimize the CID away with cTLS the question about the

Re: [TLS] Choice of Additional Data Computation

To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Choice of Additional Data Computation Hi Hannes, Hi list, as input for the discussion: https://github.com/tlswg/dtls-conn-id/issues/25 A longer "comment-flow", the conclusion was, the CID is on the wire, so it's in the

[TLS] Choice of Additional Data Computation

Hi all, the thread on the AEAD commutation in DTLS 1.3 and the construction of the additional data raised two interesting questions. I believe those would benefit from a formal analysis or at least a security investigation. Here are the questions: 1. Generic question: Should the

[TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data

Hi Martin, I have a few questions regarding the attack you mentioned below. I would like to understand whether it relates to the topic of how the additional data is constructed and what is included. > Say that a connection spans two network paths. CID A is used on path A; CID > B is used on

Re: [TLS] Efficiency of ACKing scheme

Hi Thomas, Hi Ekr, It seems we need to fix Figure 11 of Section 7.1 of https://www.ietf.org/id/draft-ietf-tls-dtls13-37.html (ACK[1] should actually be ACK[]) It should follow the “empty ACK” description of the last paragraph of

Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS

Thanks for the info, John. I will have a look at this publication. -Original Message- From: John Mattsson Sent: Wednesday, April 8, 2020 3:14 PM To: Hannes Tschofenig ; tls@ietf.org; u...@ietf.org Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS

Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS

Hi John, Thanks for the heads-up. Discussing this aspect in draft-tschofenig-uta-tls13-profile-01 makes sense. I was wondering whether you have been working on an implementation of draft-mattsson-cose-cbor-cert-compress-00 / draft-raza-ace-cbor-certificates-04. Ciao Hannes -Original

Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

nes From: Hanno Becker Sent: Monday, March 30, 2020 8:02 PM To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hannes, > In your example below, the sender of the initial KeyUpdate has to re-send it > because of the lost ACK. In

Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to retaining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or

Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

Hi Jonathan, Thanks for carefully reading the spec and for your feedback. Let me quickly respond to some of your comments. -Original Message- From: TLS On Behalf Of Jonathan Hammell Sent: Friday, March 27, 2020 6:10 PM To: Sean Turner Cc: TLS List Subject: Re: [TLS] 3rd WGLC for

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

John, you reference RFC 7540 and I believe you wanted to refer to RFC 7925 instead. RFC 7925 talks about the Extended Master Secret extension, Signature Algorithm extension, and OCSP stapling. Ciao Hannes -Original Message- From: saag On Behalf Of John Mattsson Sent: Samstag, 5.

[TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

Hi all, working on the DTLS connection id drafts we noticed that there is one security aspect, which could benefit from an extra mitigation technique. The issue is that an on-path adversary could intercept and modify the source IP address (and the source port) of a DTLS datagram. Even if

[TLS] draft-friel-tls-atls-03

Hi all, Owen and I have been working on a new version of ATLS, which you can find here: https://tools.ietf.org/html/draft-friel-tls-atls-03 The plain version (with the DTLS record layer for protecting application data) is used by Cisco and by us in products. We did, however, add extra

Re: [TLS] Elliptic Curve J-PAKE

and they didn’t want to have the user interaction needed by passwords. From: Hugo Krawczyk Sent: Mittwoch, 27. März 2019 03:48 To: Hannes Tschofenig Cc: tls@ietf.org Subject: Re: [TLS] Elliptic Curve J-PAKE Hi Hannes, J-PAKE is a symmetric PAKE. Both parties store the same password. It is not suitable

[TLS] Elliptic Curve J-PAKE

Hi all, in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned that the Thread Group has used the Elliptic Curve J-PAKE for IoT device onboarding. Here is the draft written for TLS 1.2: https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01 The mechanism is described in

[TLS] draft-ietf-tls-dtls-connection-id-04

Hi all, Yesterday I submitted version -04 of the DTLS 1.2 CID draft. On the working group Github issue tracker we spent a long time discussing how the MAC calculation should be changed to include the cid/cid_length information. In version -03 we only provided a description how to use the CID

[TLS] CWTs in TLS

Hi all, I submitted a short document about the use of CBOR Web Tokens (CWTs) in TLS.. The document is quite simple in the sense that it registers a new "certificate type" into an already existing registry. Here is the draft: https://tools.ietf.org/html/draft-tschofenig-tls-cwt-00 At the

Re: [TLS] Enforcing Protocol Invariants

Hi Ryan   reading through your email and the subsequent exchanges I am surprised that you show up right after years of standardization of TLS 1.3. Suggesting ideas at the right time is somewhat important.     Later in your emails you explain what you consider complex in TLS and some of the

Re: [TLS] Are we holding TLS wrong?

I took a quick look at the document and I don't know Babel.    I see that you have two different proposals for securing Babel messages, namely  * DTLS, and  * a custom format offering integrity protection only.    You correctly note in the document that DTLS offers more features. It is an

[TLS] Application Transport LAyer Security (ATLAS)

Hi all, around the last IETF meeting we had a good discussion on the list regarding application layer TLS, as proposed in draft-friel-tls-over-http-00 and various other drafts. For the next IETF meeting we are planning to request a BOF to have a dedicated timeslot allocated. For upfront

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Hannes On 11/07/2017 05:21 PM, Peter Saint-Andre wrote: > On 11/7/17 8:15 AM, Hannes Tschofenig wrote: >> FWIW: I can tell you what the threat model was with the layered TLS work. >> >> Let me give you a very specific example. Imagine a Bluetooth Low Energy >> device th

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

On 11/07/2017 01:20 PM, Salz, Rich wrote: > > ➢ Our work was motivated by the discussions in the IoT groups about > re-inventing the TLS handshake at the application layer. > > Isn’t that what QUIC does (to a good enough approximation)? > I see QUIC more as a new transport

[TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

This is interesting since Mark Baugher and myself have also been working on the use of TLS at the application layer and we did some implementation work with mbed TLS (with TLS 1.3) and OpenSSL. Our work was motivated by the discussions in the IoT groups about re-inventing the TLS handshake at the

Re: [TLS] Preshared Keypairs for (D)TLS 1.2

Hi Tony thanks for sharing your thoughts. It sounds a bit like you want to use public key crypto but without the overhead of certificates. If that's true then you might find https://tools.ietf.org/html/rfc7250 useful. Ciao Hannes On 10/26/2017 05:03 PM, Tony Putman wrote: > Hi all, > >   >

Re: [TLS] Connection ID Draft

I would like to focus on one of the points raised below: > 3.   We have a practical usecase in IoT. The IOT device, like > intelligent water meter, sends one message per day, and goes to sleep. > It wakes up in the second day and sends a message and then goes to > sleep. If it always (or for a

Re: [TLS] Should CCM_8 CSs be Recommended?

CCM_8 is used in the IoT space because some SDOs believed that they need to optimize the transmission overhead. Clearly, this is not meant for general purpose use but rather for IoT only. Is it a good idea to truncate the authentication tag? I don't have an opinion about that but that's what the

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Hi Martin, On 10/10/2017 10:52 AM, Martin Rex wrote: > Nope, none at all. I'm _not_ asking for protocol changes, just that > the TLS handshake continues to end with CCS + HS, and ContentTypes > remain visible. Contents of all handshake messages, and whether > and how that content is protected,

Re: [TLS] draft-ietf-tls-record-limit-01

:48 CEST Hannes Tschofenig wrote: >> Hi Martin, >> >> I have implemented the record size extension into mbed TLS. It can be >> found at https://github.com/ARMmbed/mbedtls/pull/1088 >> >> There is only one problem that remains to be addressed IMHO. This >> e

[TLS] draft-ietf-tls-record-limit-01

Hi Martin, I have implemented the record size extension into mbed TLS. It can be found at https://github.com/ARMmbed/mbedtls/pull/1088 There is only one problem that remains to be addressed IMHO. This extension was developed to address the problem of devices with small RAM. Application

[TLS] draft-ietf-tls-record-limit-00

Hi Martin, In Section 4 you define what is meant by the "maximum size of record" and in TLS 1.3 it refers to the complete length of TLSInnerPlaintext, namely struct { opaque content[TLSPlaintext.length]; ContentType type; uint8 zeros[length_of_padding]; }

[TLS] CoAP, TLS and ALPN

Hi all, I would need your deployment experience with the use of ALPN. Here is the background: With the CoAP over TCP/TLS described in https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09 we are defining how to run CoAP over TCP and TLS. CoAP is a protocol typically used in the Internet of

Re: [TLS] What counts as the same ClientHello?

Hi Noah, Todd, Ilari, the HRR is used for two purposes, namely * to report an error (with the key shares), and * for DoS protection. In both cases it feels excessive to require that the two ClientHellos are the same (with some minor exceptions). I see this as particularly problematic for the

  1   2   >