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

Hi, I'd go further - ISTM an argument for a re-design that just doesn't have the privacy problem. (And maybe come back to the TLS WG after that's done.) The "privacy problem" may disappear, if the DLT is part of that "IoT deployment" and is not considered as an external component. Anyway,

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

Hi, On that basis, I'd consider this a bad idea that ought not be pursued, and certainly not by the TLS WG. for me this sounds more like an argument for a "recommended (for general use-cases) n". Or does the TLS group focus on Web only and I missed that? best regards Achim

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

Hi Andrea, > to avoid the only option available today: That wonders me. I think, what is more in question is the comparison of the new certficate type with the two currently used ones (x509 and Raw Public Key). Reading your link, my first impression is, that this is pretty similar to x509 but

Re: [TLS] dispatching DTLS 1.2 errata

Hi Sean, Hi List, > Errata on obsolete RFCs should be considered according to whether the error persists in the obsoleting RFC. ... If it does not, it should be Rejected with an explanation that the error is corrected in the obsoleting RFC (cited by number). I'm not sure, but I guess, that

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

Hi Peter, with or without "freeze", I guess it will be not too easy to get enough interest for required discussions and reviews to change or fix TLS 1.2. On the other side, if there is enough interest for a special future 1.2 topic, I also don't get it, why that should be blocked with an

Re: [TLS] Hardware friendly packet/record format negotiation

Hi Boris, > (1) In my experience, DTLS packages mainly contain a single application data records, not more. So that limitation should not cause too much pain. > The purpose of this format is to be used in closed networks, such as high performance computing clusters > (2) If your network is

Re: [TLS] Question about DTLS for the "no new features" draft

(My guess is that most would-be DTLS 1.3 implementors are off working on QUIC; that’s certainly the case of OpenSSL.) My guess is that many companies, which have been interested in secure IoT device communication, are now focus on AI and not QUIC. For hobby developers it maybe a little too

Re: [TLS] Question about DTLS for the "no new features" draft

I don't have a complete overview, but AFAIK: - wolfSSL (C) has DTLS 1.3 - mbedTLS (C) for now doesn't support it - pion/dtls (GO) for now doesn't support it - Eclipse/tinydtls (C) doesn't support it - Eclipse/Californium (Java) doesn't support it best regards Achim Am 06.08.23 um 17:01

Re: [TLS] Servers sending CA names

One purpose additional to the already mentioned selection of the "right" client certificate may be to truncate the sent client certificate path at such a CA certificate, though that certificate is already available at the server. If x509 is used at all for IoT, such a truncation may reduce the

[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

Too fast. Very sorry, it is already linked to that thread. Weitergeleitete Nachricht Betreff: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis Datum: Wed, 5 Apr 2023 10:47:11 +0200 Von: Achim Kraus An: Martin Thomson , tls@ietf.org Let me try

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

Let me try to link this thread to the similar question raised during the implementation of RPK in openssl. https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ My personal "favorite interpretation" of RFC5246 7.4.6. Client Certificate is to stick to that definition there

Re: [TLS] TLS 1.2, RFC7250 RPK and (not sending) client certificates?

My interpretation of RFC5246, 7.4.6 Client Certificate https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6 "If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero."

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

Hi Viktor, using a compression format comes with savings, but in my experience, one of the other issues, which comes with pain for constraint IoT, is the amount of "parameters" sent in the ClientHello. For DTLS 1.2, that's even sent twice, if a HelloVerifyRequest is used. A macro to enable the

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

Hi John, > I don't think RFC 8422 applies here. maybe, if one of that authors are reading the list, we can get an statement, what the intention of was. A RFC7250 handshake takes about 1500 bytes "on the wire". Saving 32 bytes twice is not that great improvement. If someone want to be "better

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

Hello Viktor, > Thanks to Todd Short, RFC7250 raw public keys should be available in > OpenSSL ~3.2. Applications that use unauthenticated opportunistic TLS, Sounds great. Especially for IoT/constraint use-cases that's a real benefit. Just in the case, someone is interested, I asked a couple

Re: [TLS] Profile ID in CTLSServerPlaintext

I don't follow LwM2M, but DTLS-SRTP already handles this case.  See: https://www.rfc-editor.org/rfc/rfc5763#section-5 If you're aware of cases where this design does not correctly handle the situation, please surface them... -Ekr RFC 5763

Re: [TLS] Profile ID in CTLSServerPlaintext

18:52 schrieb Eric Rescorla: On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus mailto:achimkr...@gmx.net>> wrote:  > 2. A single server serving multiple clients, where the clients share an  > address. Not sure, if "address" is just the ip-address or

Re: [TLS] Profile ID in CTLSServerPlaintext

s at different times or later traffic that's supported. best regards Achim Am 07.01.23 um 08:43 schrieb Achim Kraus: Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more. DTLS role exchange was an topic in DTLS 1.2. It was in discussion in LwM2M. > What I meant is that

Re: [TLS] Profile ID in CTLSServerPlaintext

Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more. DTLS role exchange was an topic in DTLS 1.2. It was in discussion in LwM2M. > What I meant is that, isolated to a single path, an endpoint (A > or B) should only be a server or a client, not both at the same > time. So a

Re: [TLS] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

Hi John, I'm not sure, are there any new arguments for this since this discussion https://mailarchive.ietf.org/arch/msg/tls/WoBwUCqEMcFhvIHN6neo5W4Urg4/ in 2020? Maybe, if the new arguments are highlighted, the discussion gets this time shorter. "Malicious actors can get access to long-term

Re: [TLS] FW: New Version Notification for draft-ietf-lwig-security-protocol-comparison-06.txt

Hi John, just to mention, the CCM8 is also considered to be not recommended in the future (see https://mailarchive.ietf.org/arch/msg/core/WnRInwF-j0uZmLggFh37ySljnwE/). Wouldn't it make more sense to use then CCM instead (16 bytes tag length)? I would appreciate, if the comparison DTLS vs. TLS

Re: [TLS] DTLS AAD length usage clarification?

Hi Andrew, > length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14. Yes, the original plaintext, the original record type and the padding. For AEAD and CBC without EtM, that "length_of_DTLSInnerPlaintext" is

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

ated https://github.com/tlswg/tls-subcerts/issues/107 best regards Achim Kraus Am 10.05.22 um 02:37 schrieb internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF.

Re: [TLS] Up to date overview of TLS implementations?

github.com/ARMmbed/mbedtls/pull/5061 Tools: Wireshark, implemented, https://gitlab.com/wireshark/wireshark/-/issues/17695 Zephyr, waiting on mbedtls, https://github.com/zephyrproject-rtos/zephyr/pull/36738 best regards Achim Kraus Am 12.11.21 um 09:55 schrieb John Mattsson: Hi, Is there any

Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

mory Footprint - IACR <https://eprint.iacr.org/2021/138> Cryptology ePrint Archive: Report 2021/138. Classic McEliece Implementation with Low Memory Footprint. Johannes Roth and Evangelos Karatsiolis and Juliane Krämer eprint.iacr.org // ------

Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

nor intended by RFC6347. Therefore I would recommend, to use less Client-Parameters to make the ClientHello small. That's one good reason for RFC7252 to define a mandatory set, clients can rely on. best regards Achim Kraus Am 05.11.21 um 20:14 schrieb Hanno Becker: Hi all, Both DTLS 1.2 a

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

Flags Extension". I'm not sure, how fast DTLS 1.2 deployments will be moved to DTLS 1.3. But I'm pretty sure, that DTLS 1.2 with Connection ID will make many NB-IoT solutions possible, and RRC will help to defend that against attacks. best regards Achim Kraus Eclipse/Californium (Currently DTL

Re: [TLS] TLS Flags and IANA registration policy

d of the "Y" amended to the "N", e.g. "N (was Y 2010-2019)". best regards Achim Kraus Am 30.10.21 um 04:47 schrieb Sean Turner: I actually think we’re going to try to do this 8447bis: https://github.com/tls-stuff/rfc8447bis We need to get it adopted, but that’s on

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

such a fallback by the server, the general rule, to only use "full-handshakes", will be also full filled. And the benefit would be, that the client doesn't need to send a second handshake. best regards Achim Kraus Am 28.10.21 um 19:44 schrieb David Benjamin: It depends on what t

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

s://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/> best regards Achim Kraus Am 26.10.21 um 00:51 schrieb David Benjamin: > Here's some possible replacement text for that paragraph: > > """ > In some deployments, a legacy client

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

hy SHOULD the server not (also) just fall-back to use a full handshake? For more details see: https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/ best regards Achim Kraus Am 26.10.21 um 00:51 schrieb David Benjamin: Here's some possible replacement text for that paragraph: &q

Re: [TLS] DTLS RRC and heartbeat

. that sounds as a good reason, to ask for a new code-point. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DTLS RRC and heartbeat

rs/tls-parameters.xhtml#tls-parameters-5 And we are not sure, if considering mainly implementation issues, will justify to allocate a new code-point. best regards Achim Kraus Am 21.10.21 um 16:30 schrieb Hanno Böck: On Thu, 21 Oct 2021 10:35:54 +0100 Thomas Fossati wrote: One problem is - as Hann

[TLS] (TLS) RFC5246 - 7.2.1. Closure Alerts - Applied to (DTLS) RFC 6347

g/tls/VNrSd7gv7uFjJNZH6frBt5lb57A/ https://mailarchive.ietf.org/arch/msg/tls/FJM6OHfvLJP_pF5uUcR86pzrdYo/ But I miss a explicit statement about the "truncation attack". Or is that too obvious? best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

t CID, much more (resumption) handshakes are needed in order to communicate using DTLS. - with CID, such (resumption) handshakes are still required, but much less. Your attack adds some more handshakes, but it doesn't introduce something new, nor do I see, that this will exceed the number of handshake

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

, the probe will again protect the victim's new source from being DDoS'ed. So, please be more explizit, what the resulting attack would look like? best regards Achim Kraus Am 05.05.21 um 04:45 schrieb Martin Thomson: I can't claim credit for all of the jankiness in QUIC regarding on-path

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

Hello Sean, Hello List, FMPOV, that dtls-rrc work is very welcome! All use-cases, where the northbound-layers don't provide solutions for that, will benefit from it. best regards Achim Kraus Am 03.05.21 um 17:44 schrieb Sean Turner: Hi! We would like to re-run the WG adoption call

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

efer a longer "reserved period", e.g. 12 months. (That's just my personal preference.) Best regards Achim Kraus Am 21.04.21 um 10:29 schrieb Francesca Palombini: Hi Hannes, Achim, Thanks, that's all I was curious about! No need to add that to the IANA considerations, this was more of a ques

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

a strategy that will fulfill the third condition? That might be worth saying, if so. Yes, see https://github.com/tlswg/dtls-conn-id/issues/103#issuecomment-822306643 best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

akes it easier to migrate existing deployments to that new MAC. At least for Eclipse/Californium I know, that is used with 53 and the old MAC. best regards Achim Kraus Am 20.04.21 um 18:22 schrieb Francesca Palombini via Datatracker: Francesca Palombini has entered the following ballot positio

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

-NB solutions). And there are also some advanced use-cases, e.g. CID based load-balancer. For your other points, Thomas created an issue on github (https://github.com/tlswg/dtls-conn-id/issues/103). I left some comments there. best regards Achim Kraus Am 19.04.21 um 09:47 schrieb Éric Vyncke

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

thub.com/tlswg/dtls-conn-id/issues/43 and follow the refered PRs. The outcome: If the CID is empty, RFC6347 record format is used. That's equivalent to "empty CID is only used in the extensions of the Hellos". Best regards Achim Kraus Am 12.03.21 um 18:28 schrieb tom petch: On 12/03/2

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

egotiated non-empty CID. WDYT? best regards Achim Kraus Am 12.03.21 um 12:58 schrieb Hannes Tschofenig: 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://githu

[TLS] RFC7627 - 5.3 - inconsistent behavior of client and server?

t follow this (maybe, the client is not aware of RFC 7627), the server SHOULD aborts. Why SHOULD the server not (also) just fall-back to use a full handshake? best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] RFC 6347 - Section 4.2.1 - used version in a HelloVerifyRequest

s HelloVerifyRequest? best regrads Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

Hi Ben, Am 17.11.20 um 07:07 schrieb Benjamin Kaduk: On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote: Hi Ekr, As for EtM Encrypt-then-MAC: struct {   uint8 marker = tls12_cid;   uint8 cid_len;   uint8 content_type = tls12_cid;      \   uint16 DTLSCiphertext.version

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

t the "uint16" instead of "uint8". I'm looking forward, when this will get finished :-). best regards Achim Kraus Am 30.10.20 um 13:39 schrieb Peter Gutmann: Achim Kraus writes: 2. Why should a "uint16 iv_length" be added? To make it explicit which of th

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

f at all, to have that at the begin. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

Hi Ben, at least at your point (from the e-mail before) > and not have to change it again. I agree :-). That will naturally become true, if the RFC gets released. best regards Achim Am 26.10.20 um 17:56 schrieb Benjamin Kaduk: Hi Achim, On Sat, Oct 24, 2020 at 08:56:08AM +0200, Ac

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

, > DTLSInnerPlaintext.content = <513 bytes>. I would feel much more comfortable, if you state, that you consider now either 1. that example was not compliant to the draft, or 2. the draft is not clear enough about that. If 1. is true, https://github.com/tlswg/dtls-conn-id/issues

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

t be possible, to get more information about an attack applied on the generation of a MAC (above in step 3)? Or does the effect occur in an other step (maybe 4)? Which effect should be considered? Maybe, someone else has also an opinion about that attack or the description. best regards Achim Kraus __

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

. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

ble length CID" to be the real spot. That points for me to the same direction, it's that encoding not the position of the cid-lenght. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

my opinion, that's a problem of the encoding of the variable length CID, but not the MAC. best regards Achim Kraus Am 11.10.20 um 22:53 schrieb anto...@delignat-lavaud.fr: Dear Watson, I object to your comment about formal models of TLS not capturing wire encoding issues. miTLS does in fact formal

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

Hi Wadson, my bad, I mislead in understanding "injective". It's not related to "injection". best regards Achim Kraus Hi Wadson, The doubt is because of where it appears not that it appears. If every value was preceded by its length the encoding would obviously be

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

for encoding variable length CIDs. https://github.com/tlswg/dtls-conn-id/issues/76 best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

For me this seems to be different input to the MAC, if the cid-length is left out. My feeling is, your example proves my opinion, that it's better to remove the cid-length from the MAC. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https

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

nd so create a time signal. Or with "same MAC_write_key" the receiver will not know by the failing MAC, which interpretation is the right. I guess, this will end up in decrypt twice, also obvious time signal.) best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

> Would this issue have been caught by formal verification? That may also be something to help, not to change still again and again. best regards Achim Kraus Am 11.10.20 um 00:26 schrieb Joseph Salowey: On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus mailto:achimkr...@gmx.net>> wrote:

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

may be, when this changes will end. best regards Achim Kraus Am 10.10.20 um 19:29 schrieb Michael D'Errico: On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote: [...] The behavior we should demand from our cryptographic constructions is that the cryptography itself correctly returns "valid&

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

erience with the long history of this discussion, if more can give their feedback about changing the MAC again. Please, this year, not next :-). best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

nd CID-less traffic to different endpoints?) If it's possible to use different endpoints, I think so. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

example, especially the cid-length, is not in the message. Please, find the time to check that current record defintion! There the CID is encoded in the protocols tls-cid-records without the explicit CID length. With that, I can't see the posssiblity to inject the cid-length. It's simply not "i

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

Hi Ben, any progress on the cid-length / calculate MAC topic? As I wrote, though the cid-length itself is not "on the wire" (it's only the cid), I can't see, that the cid-length could be injected. Do I oversee soemthing? best regrads Achim Kraus Weitergeleitete

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

year also next year. best regards Achim Kraus Am 30.09.20 um 10:19 schrieb Rob Sayre: On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> wrote: Hi Watson, through Arm I deal with customers who use microcontrollers that have all sorts of limita

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

regards Achim Kraus Am 30.09.20 um 02:48 schrieb Blumenthal, Uri - 0553 - MITLL: Because PSK is one of the affordable and reliable quantum-resistant key exchanges that work *today*? And done environments do not wish to do any EC operations. Yes, key management issues are real. Those who need

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

case will still need some time to adapt for the new recommendations. best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

. Maybe, they are not in the IoT scope... Best Regards Pascal Le lun. 21 sept. 2020 à 19:57, Achim Kraus mailto:achimkr...@gmx.net>> a écrit : Hi Pascal, that using these ISO 7816 card is fast and save, doesn't say too much about the use-case without that card, or? For sure,

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

Hi John, I can only fully agree with Hannes's arguments! PSK is in my experience for some constraint devices currently the only choice. Devices, which are able to execute a PSKs with ECDHE handshakes, will be able to use RPK. I'm not sure, if sometimes the arguments, not to recommend

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

Hi Pascal, that using these ISO 7816 card is fast and save, doesn't say too much about the use-case without that card, or? For sure, there are micro-controller, which are also equipped with hw-ecc or hw-rsa. And there are more secure-devices protecting credentials. But there are also still ones

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

Hi Ben, Am 16.09.20 um 08:31 schrieb Achim Kraus: Hi Ben, If I did't get it, it may be easier to discus this as issue in the github repo. I think you got it; I am just failing to remember where the "MUST anyway use new handshakes" requirement comes in from.  And I guess that a

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

Hi Ben, For receiving, if the tls12_cid content type is set, then the CID is used to look up the connection and the security association. If the tls12_cid content type is not set, then the connection and security association is looked up by the 5-tuple and a check MUST be

Re: [TLS] Static DH timing attack

than using it with e.g. secp384r1? Or do I mix-up things and "DH with 25519 keys" is something different? best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

. But these discussion have been at that time. For now, I'm not sure, if changing details will bring that benefit. So, please, only address and change things, which are really important. best regards Achim Kraus Am 04.09.20 um 01:02 schrieb Benjamin Kaduk: Hi all, Sorry for the slow processing

Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

Hello Ben, thanks for your answer and actions. best regards Achim Am 27.07.20 um 21:03 schrieb Benjamin Kaduk: Hi Achim, My apologies for the URL mangling by my corporate spam filter. On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote: Dear list, are there any news about

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

hing and therefore do less. The others may also justify, why they consider something additionally, and therefore do more. In the end, it's more the question, who is intended to invest the time. best regards Achim Kraus Am 23.07.20 um 02:32 schrieb Martin Thomson: I'm OK with adopt

[TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

gh the cid changes the 13. For me this looks much more, that the authors are too busy with other work and not that this draft doesn't make sense anymore. Therefore I would appreciate, if the temporary IANA registration for the connection_id could be extended by an additional year. Best regards A

Re: [TLS] RFC 8449 – DTLS 1.2 considerations

Hello Martin, thanks a lot for your answer! That helps very much to overcome my UDP confusion :-). best regards Achim Am 15.07.20 um 08:41 schrieb Martin Thomson: On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote: For me it seems, that an agreement about this message buffer size is still

Re: [TLS] Banning implicit CIDs in DTLS

Hi Thomas, > Now, it turns out in the specific situation (and whenever the data > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one > might as well buffer and coalesce all the application stuff into one > single record, making the need for CID compression moot. I'm not sure,

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

Hi Martin, > So this depends on either concurrent use of the two CIDs, with that and the "routing based on cid", I would raise the question, if the usage of the cid turns into a swiss-army-knife? Therefore it may get larger, and so it gets attractive, to use it only on the first record, but

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 MAC. (ekr: "authenticating the whole header is just good practice.") My arguments was, that the CID is always

Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

iciently, but leave enough for still have an MAC check on the truncated message, lead to a conclusion, that at least very short messages are not affected. Does this match your assumptions? best regards Achim Kraus Am 09.09.19 um 10:45 schrieb Paterson Kenneth: Hi Achim, See below for a comme

Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

e padding overflow check without drawbacks. best regards Achim Kraus Am 09.09.19 um 10:03 schrieb Martin Thomson: Are you able to use an AEAD? I agree that EtM is likely a non-starter, but moving to an AEAD is just better. NSS does the "255 compares" approach, which I think is OK.

[TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

en−1−t that reduces in some case (1/mac-blocksize) the number of extras compression evaluations best regards Achim Kraus [1] https://www.ietf.org/proceedings/89/slides/slides-89-irtfopen-1.pdf [2] http://www.ieee-security.org/TC/SP2013/papers/4977a526

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

release and it would be very great, if I could include the values of the early assigned code-points. best regards Achim Kraus Am 05.04.19 um 22:18 schrieb Joseph Salowey: We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04.  We believe