Re: [TLS] IANA Recommendations for Obsolete Key Exchange

With David's clarifications, this is good. On Tue, Apr 16, 2024, at 04:46, David Benjamin wrote: > From the meeting, I remember there being some confusion around a table > that split things up between TLS 1.2 and TLS 1.3, and differences in > how they negotiate things, which makes this listing

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

On Tue, Apr 16, 2024, at 04:14, Joseph Salowey wrote: > Should the draft deprecate these ClientCertificateTypes and mark the > entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) > as 'D' discouraged? Yes. ___ TLS mailing list

Re: [TLS] Genart last call review of draft-ietf-tls-keylogfile-01

Thanks Russ, https://github.com/tlswg/sslkeylogfile/pull/11 and https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/ should address those issues. Cheers, Martin On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote: > Reviewer: Russ Housley > Review

[TLS] Transfer of change control for SSLKEYLOGFILE format

Hey, I'm writing this in my capacity as owner for NSS[1], not as a draft author. The chairs asked that I formally indicate that Mozilla and the NSS project are willing to transfer ownership of the SSLKEYLOGFILE format[2]. Though it might be obvious to some of us that submitting an

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

Short inline comments. On Tue, Apr 2, 2024, at 23:24, Stephen Farrell wrote: > [...] > I'm not really sure how to interpret the above tbh. Was that intended > as a summary of the draft or as a synopsis of the problem space? That's my sketch of what I think the draft should be doing. I don't

[TLS] Artart early review of draft-ietf-tls-wkech-04

Reviewer: Martin Thomson Review result: Not Ready This document describes how an HTTP origin can publish information about its ECH configuration so that other nodes can aid it in setting up the DNS records necessary to run DNS. Issues: Most of the document talks about having the back-end

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Dennis beat me to making the key point about identity :) There are cases where identity misbinding is possible in similar systems. RFC 8844 describes one such case. However, this is not an inherent failing in TLS, but in the usage context. That weakness was not the result of using raw public

Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS

In offline discussion l was convinced that a bigger change might be needed. The shifting is cute, but we might be able to do better. This won't be wire compatible with the existing protocol, so maybe just embrace that and change the record header. This would happen when switching from

Re: [TLS] Working Group Last Call for SSLKEYLOG File

t; On 12/03/2024 23:07, Eric Rescorla wrote: >> >> >> On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell >> wrote: >>> >>> I'll argue just a little more then shut up... >>> >>> On 12/03/2024 22:55, Martin Thomson wrote: >>> >

Re: [TLS] Working Group Last Call for SSLKEYLOG File

On Wed, Mar 13, 2024, at 08:39, Stephen Farrell wrote: > (Apologies to Martin for the grudging acceptance of > his worthy effort;-) No apology needed. Nose-holding is expected :) > Sorry also for a late suggestion, but how'd we feel about adding > some text like this to 1.1? > > "An

Re: [TLS] Working Group Last Call for ECH

 Ship it. On Tue, Mar 12, 2024, at 09:00, Joseph Salowey wrote: > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the > IESG and send any comments to the list by 31 March 2024. The comments > sent by

Re: [TLS] Time to first byte vs time to last byte

Hi Panos, I realize that TTLB might correlate well for some types of web content, but it's important to recognize that lots of web content is badly bloated (if you can tolerate the invective, this is a pretty good look at the situation, with numbers:

Re: [TLS] Status of draft-ietf-tls-rfc8446bis

On Mon, Feb 19, 2024, at 04:44, Eric Rescorla wrote: > I wouldn't object to more analysis, but given the relatively narrow > remit of this > document and that changing the key schedule would obviously create wire > format incompatibilities, I wouldn't want to do that absent some > evidence >

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

On Wed, Jan 31, 2024, at 07:16, Salz, Rich wrote: >> This version incorporates all known issues. The authors believe this version >> is ready for WGLC. > > Yes, pretty much. Two nits than can be fixed during AUTH48 > > This sentence in Sec 15 confuses me: > For this reason, designated

Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt

On Fri, Jan 26, 2024, at 02:36, Salz, Rich wrote: >> Internet-Draft draft-ietf-tls-keylogfile-00.txt is now available. It is a >> work >> item of the Transport Layer Security (TLS) WG of the IETF. > > I assume this just documents the current format and that therefore > existing implementations

Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)

t; ------ >> Status: Held for Document Update >> Type: Editorial >> >> Reported by: Martin Thomson >> Date Reported: 2020-06-04 >> Held by: Paul Wouters (IESG) >> >> Section: 4.3.2 >> >> Original Text >> --

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote: > X-Wing aims for 128-bit security, and for that combines the time-tested > X25519 with ML-KEM-768 [8]. X-Wing uses the combiner > > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 ) At least for TLS, I'm not

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

On Thu, Jan 11, 2024, at 18:38, Christian Huitema wrote: > If an implementation does not want to deal with the extra complexity, > then having a way to plug in some extra code for a specific scenario > makes sense... My point was that the handling does not need to be complex, only the tolerance

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

On Thu, Jan 11, 2024, at 15:45, Christian Huitema wrote: > Good for you. Not all implementations do that. It is hard for me to > blame them, because the 10 seconds recommendation is justified by for > "clients on the Internet", and delays larger than 1 or maybe 2 seconds > are quite rare on the

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

On Thu, Jan 11, 2024, at 11:07, Christian Huitema wrote: > One first problem with this code is that implementations may or may not > have an estimate of the RTT when they are issuing the ticket. In theory > the server could measure the RTT by comparing the send time of the > server first flight

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

On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote: > In the interest of clarity, I favor the WG declining to work on > extending TLS 1.2, so these cipher suites should be marked as > Recommended=No. I'm just concerned that closing the registries entirely > will not have the best results.

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

On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: > That is not what the just-adopted draft says. It says that except for > ALPN and exporters that no new registrations will be accepted for TLS > 1.2 and that new entries should have a Note comment that says “for TLS > 1.3 or later”. This is a

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

On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote: > Of course. We’re not the protocol police and nobody from the IETF will > come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But > with this document, they will not be able to register such an algorithm > for 1.2 I don’t

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

One thing that I observed when we were doing QUIC was that the canonical reference for how to do this sort of anti-replay is a section that is buried deep in an IPsec RFC. Perhaps that short RFC is an opportunity to also document the process in a way that can be a reference to other documents.

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote: > I would strongly recommend all DTLS 1.3 libraries to completely remove > the option to disable replay protection. I believe that the reason this exists is that some higher-layer protocols have their own replay protection, such that as long

Re: [TLS] ECH: Changes to IANA consideration section

On Tue, Nov 28, 2023, at 05:03, Watson Ladd wrote: >> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to >> indicate a value; remember, this column indicates the messages in which the >> extension may appear. Currently, it’s “”. “N/A" has been suggested, which >> makes

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote: > Apologies if I should respond directly to the mailing list - my old W3C > profile has disappeared and I'm trying to get it back... Just on this point. Watson added the HTTP working group, which I think is the right thing to do here. The

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

This is good work and looks to be ready. (I could quibble about the extensibility model or the inclusion of the basic check mode, but both are well specified.) On Tue, Sep 19, 2023, at 07:03, Sean Turner wrote: > This email starts the 2nd working group last call for "Return > Routability Check

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

I support adoption. There are enough short-term performance gains to justify this, even without the possibility that it helps with PQ certs. On Wed, Aug 2, 2023, at 07:17, Stephen Farrell wrote: > Hiya, > > I saw the presentation and scanned the draft and support > adoption on the basis that

Re: [TLS] tls@ietf117

I wonder whether there are any new insights regarding sslkeylogfile standardization. I know we didn't make much progress last time we asked, but it seems like the discussion moved on a little in the time since then. On Mon, Jul 17, 2023, at 09:22, Sean Turner wrote: > And another gentle

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

cation. Not >> sure if I would call this a “simpler integration” (as digital signatures are >> as complex as KEMs) but, as far as I know, that is not KEMTLS ;) >> >> Thanks, >> >> Sent from the phone >> >> >> > On 27 Jun 2023, at 00:56, M

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

Hi Thom, I infer - though it is not explicit - that this experiment is based on the assumption that KEM-TLS is used, rather than a simpler integration. Can you comment on what you see as the relative impact of that difference? On Mon, Jun 26, 2023, at 21:48, Thom Wiggers wrote: > Hi TLS-wg

Re: [TLS] SSL cert - CA issuer question - WIndows Event Reporting CA

On Wed, May 10, 2023, at 10:36, M K Saravanan wrote: > When I first access that website, for e.g. https://www.cloudflare.com > the issuer CA is shown as “Windows Event Reporting CA”. What you have there is known as interception. Something on your machine (Windows Event Reporting maybe) has

[TLS] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)

I like the idea that we might have a more efficient cipher in this particular way. I've been a fan of OCB for that reason for some time. However, I don't think that QUIC or TLS integration is necessarily a good idea for this cipher. SRTP is one thing, but QUIC and TLS have an entirely

Re: [TLS] [EXTERNAL] Re: Servers sending CA names

I think that is also true for NSS, though my experience of this is not thorough. As David notes, client certificates are something of a mess once you step outside a context where the client already knows what it should be sending. On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote: > Windows

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

with a solid conclusion, other than a note from Ilari indicating that maybe a zero length RPK would be OK in some libraries. See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/ On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote: > https://author-tools.ietf.org/diff?do

Re: [TLS] TLS 1.2 deprecation and RFC 7627

On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote: > Are the things like national-wide standards considered as new features > (until they don't pretend to be Internet-wide standards)? I would not expect the IETF to be specifying national standards (that's an obvious contradiction anyway).

[TLS] TLS 1.2 deprecation and RFC 7627

Just a thought, but in the discussion of TLS 1.2, we might start to consider the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated sooner. RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so maybe requiring it (or not supporting TLS 1.2 if that

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

https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07 might be helpful to others. I opened a few issues, but the TLS 1.3 revision is very much ready to be published. For the 8447 revision, I found that our decision to remove the definition of the fields for each

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

Adopt. But please include an example, even if the public key is 0x010203040506... On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote: > At TLS@IETF116, the sense of the room was that there was WG support to > adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the > consensus in the

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

On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote: > I think the current working group consensus for the policy of the > recommended column is reflected in the following statement: > > Setting a value to "Y" or "D" in the "Recommended" column requires IETF > Standards Action [RFC8126 >

Re: [TLS] Identify and mitigate tracking and fingerprinting vectors - How to progress

On Fri, Jan 13, 2023, at 22:56, John Mattsson wrote: > There are a lot of additional tracking and fingerprinting vectors in > the Client Hello and Server Hello. > > - Tracking is also an issue for servers. IoT devices are often servers > and by tracking the device you can often track the person

Re: [TLS] Profile ID in CTLSServerPlaintext

On Fri, Jan 6, 2023, at 01:46, Ben Schwartz wrote: > In Datagram cTLS (as of -07), this is not possible. The parsing of > handshake messages depends on prior knowledge of who is the client and > who is the server. This is because CTLSServerPlaintext and > CTLSClientPlaintext are different

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote: > use of FFDHE with large key sizes is the best protection against > store-and-decrypt-later attacks This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some ludicrously large named groups. Is that not enough? > If anything,

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote: >> You might need to clarify that TLS 1.1 and earlier are wholly deprecated >> though, just to be sure. > > We do mention that in the body of the document. Are you suggesting that > we also add that to the abstract and intro? Oh yeah, three

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

On Sun, Dec 18, 2022, at 04:33, Yaron Sheffer wrote: > Yes, this is clear to people on this thread. My comment was just about > the document, which IMO should define its scope more clearly and early > on. The title and abstract and introduction could say "TLS 1.2" and the document would be

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

I personally have no intention of making this PS (or to otherwise water down recommendations against it). I do have some interest in doing what can be done to make this less of a hazard. You will see that I took John's suggest to more directly proscribe its use:

Re: [TLS] sslkeylogfile

Thanks for the input John, I agree on both points, the minor one and the substantive one. https://github.com/martinthomson/sslkeylogfile/pull/1 is my attempt to put something stronger about usage/applicability up front. Do you think that is sufficient? On Thu, Nov 24, 2022, at 21:37, John

Re: [TLS] DTLS 1.3 Sequence number reconstruction?

QUIC uses approximately the same basic approach as DTLS does, with the same ambiguity. The example [1] makes a choice, but in practice it doesn't matter. This only happens for two numbers that are very far from the expected sequence number. 50% odds of making a wrong choice probably doesn't

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

On Thu, Oct 27, 2022, at 09:23, Martin Thomson wrote: > On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote: >> Idea > > We're not short on ideas (your idea is not new). We're short on the > willingness to implement and deploy them. I should apologize here. Ilari's

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote: > Idea We're not short on ideas (your idea is not new). We're short on the willingness to implement and deploy them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] sslkeylogfile

On Tue, Oct 25, 2022, at 16:48, Peter Gutmann wrote: > But it's not the same thing, it only seems to cover some TLS 1.3 extensions. > Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE Format for TLS > 1.3". That's not the intent. Section 3.2 covers all you need for TLS 1.2. I did

Re: [TLS] sslkeylogfile

On Tue, Oct 25, 2022, at 16:09, Peter Gutmann wrote: > Well at the moment the web page defines what's used in practice and the spec > defines... something? A hope for the future? An extension to the current > usage? The exact same thing, just using different words and style. The intent is to

[TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

On Tue, Oct 25, 2022, at 13:57, Stephen Farrell wrote: > Is there any public info as to how often HRR happens? > (Sorry if that's well known, but it's not well known to > me:-) > > Were that rare enough, I'd hope it'd be a thing where we > could reach consensus for deprecation. If it's not yet >

Re: [TLS] sslkeylogfile

On Tue, Oct 25, 2022, at 13:19, Peter Gutmann wrote: > Martin Thomson writes: > >>I just posted https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/ > > This looks like some variant of > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format &g

[TLS] sslkeylogfile

I just posted https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/ Latest HTML: https://martinthomson.github.io/sslkeylogfile/draft-thomson-tls-keylogfile.html It's annoyed me for some time that the NSS team has been responsible for maintaining this fairly important piece of

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

The integrity of TLS doesn't depend on the key holder presenting proof of possession toward the issuing CA. Perhaps we could define an extension that produced an empty signature, so that it could be used for any algorithm without these complications... On Wed, Oct 5, 2022, at 03:05, Russ

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote: > As X25519 is not FIPS-approved, the lab won't be able to test it, OK, hypothetical question, but maybe an important one. Why would a certification lab care? We compose secrets with non-secrets all the time, so even if X25519 were

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote: > Actually, that was our original intention with this draft - to specify > the framework, and to have other documents specify the actual pairs. > However, I believe that the sense of the working group is that they > want this

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote: > Well, if we were to discuss some suggested hybrids (and we now know the > NIST selection), I would suggest these possibilities: > > - X25519 + Kyber512 > - P256 + Kyber512 > - X448 + Kyber768 > - P384 + Kyber768 Any specific pairs

Re: [TLS] What is "completed handshake"?

On Tue, Aug 9, 2022, at 17:49, Ben Smyth wrote: > A handshake partially completes on sending/receiving a server's Finished > message I don't see this as "partially complete", the way I frame this is that a server can send prior to the completion of the handshake under some conditions. The

Re: [TLS] What is "completed handshake"?

On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote: > On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote: >> "Upon receiving the server's messages, the client responds with its >> Authentication messages, namely Certificate and CertificateVerify (if >> requested), and Finished. At this point, the

Re: [TLS] [Technical Errata Reported] RFC8446 (7073)

This is correct, though I would have extended this to say ", except for post-handshake authentication, which uses keys derived from the current [sender]_application_traffic_secret_N." or similar. On Sat, Aug 6, 2022, at 23:03, RFC Errata System wrote: > The following errata report has been

Re: [TLS] Representing IP addresses in SNI -- proposed draft

connection's IP", it's >> already unambiguous. Granted, there may be edge cases because missing >> server_name can also mean "I want the default cert" and perhaps your >> "default" cert and IP cert are different. >> >> On Wed, Jul 27, 20

Re: [TLS] Representing IP addresses in SNI -- proposed draft

Hi Erik, As far as it goes, this might work. However, I'm not sure about the effect of this on compatibility. I'm concerned that maybe this would end up causing some servers to choke. Servers that receive SNI can sometimes use that SNI value to lookup the correct certificate. Your design

Re: [TLS] PQC key exchange sizes

On Tue, Jul 26, 2022, at 22:21, Kampanakis, Panos wrote: > Why are 2-3 packet CHs unworkable? Loss probability is a contributing factor for sure, but the thing that really hurts is the extra round trip that many servers will induce when they cannot process the TLS ClientHello in one go.

Re: [TLS] PQC key exchange sizes

On Tue, Jul 26, 2022, at 11:42, Blumenthal, Uri - 0553 - MITLL wrote: > What are the implications for environments that require NIST Sec Level 3 or 5? Poor performance. By which I mean increased exposure to packet loss and additional round trips. For instance, in QUIC servers might be forced

Re: [TLS] PQC key exchange sizes

On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: > Be interested in how that'd change the CH if ECH is used too. > I guess the answer mightn't make us happy;-) PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for ECH if we stuck with classical security. For

[TLS] Extensibility in SCVP draft

Take this: struct { PathValidationType path_validation_type; select (path_validation_type) { case scvp: SCVPValidationRequest; } request; } PathValidationRequest; enum { scvp(1), (255) } PathValidationType; This adds a layer of extensibility that doesn't do a lot.

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On Sat, Apr 30, 2022, at 00:24, Douglas Stebila wrote: > Thanks for the feedback Martin. I see what you're getting at regarding > phrasing it in terms of KeyGen[i], Encaps[i], etc. This is a good > point: > >>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the >>>

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

I found the introduction of KeyGen, Encaps, and Decaps to be underutilized. It would require a little work, but I think that it would be better to describe a method whereby you produce each of these functions by taking an ordered collection of these functions (KeyGen[i], Encaps[i], and

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

, but distinct, use in RFC 5246. On Thu, Feb 24, 2022, at 08:41, Martin Thomson wrote: > Adopt. > > I found the changes from 8447 hard to find without a diff: > > https://www.ietf.org/rfcdiff?url1=rfc8447=draft-salowey-tls-rfc8447bis-01 > > Some comments on the content: > >

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

Adopt. I found the changes from 8447 hard to find without a diff: https://www.ietf.org/rfcdiff?url1=rfc8447=draft-salowey-tls-rfc8447bis-01 Some comments on the content: * Recommended = D requires standards action. I think that you might want IETF consensus instead. * A lot of the "changes"

Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt

On Wed, Feb 23, 2022, at 09:31, Ben Schwartz wrote: > In TLS, I think "MUST" means "recipients should validate this if > possible and fail the handshake if there is a mismatch". Consider a > client implementation. Upon receipt of a SNIP response, is it supposed > to cross-check the SNIP

Re: [TLS] tlsflags and "responses"

On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote: > I think (but don't have a solid recollection) that this may have > stemmed from a desire for the sender to know if the recipient supports > flags at all. But thinking about it now (and as Ekr's response > suggests), so long as we don't

[TLS] tlsflags and "responses"

I missed this text in draft-ietf-tls-tlsflags: A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it

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

On Thu, Feb 17, 2022, at 07:25, Sean Turner wrote: > Right now the I-D exclusively mentions TLS. The fix might be as easy as > a global replace of TLS with (D)TLS. Can anybody think of a reason to > preclude DTLS? I just checked and our implementation (thanks again Chris P) works and is tested

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

On Wed, Feb 16, 2022, at 22:26, Ilari Liusvaara wrote: > I think the language in tlsflags about acknowledging extensions is > confusing. Tlsflags behavior should be similar to extensions, which do > not have acknowledgment requirement in base TLS (any acknowledgement > requirement is per

Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt

work item of the Transport Layer Security WG of the IETF. > > Title : Secure Negotiation of Incompatible Protocols in TLS > Author : Martin Thomson > Filename: draft-ietf-tls-snip-01.txt > Pages : 12 > Date

Re: [TLS] Revised hybrid key exchange draft

I am not convinced that the extra effort is justified. However, I am convinced that the proposed construction is complex. combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2), data=1||F(k1))) H1(k) = H('derive1' || k) H2(k) = H('derive2' || k) F(m) =

Re: [TLS] Revised hybrid key exchange draft

I was operating under the assumption that inputs to concatenation were fixed length. It seems that the attack mentioned did not. It seems like that is a far simpler way of achieving that goal. That is, it seems to be sufficient to state that assumption as a requirement. Constructing a

Re: [TLS] Two final DTLS 1.3 issues

These are both disruptive changes, but I agree that they are OK in principle. I have a few questions on #257. Those are on the PR, but I'll repeat them here: Many implementations of DTLS use a 16-bit integer to hold epoch. Sometimes, that leaks into places that mean that it is hard to change.

Re: [TLS] IANA Registry for TLS-Flags

On Tue, Dec 14, 2021, at 01:47, Salz, Rich wrote: >>How about we split the difference and go with the first 0-15 flags for >> standards action? We can keep the initial value of 8 for >> cross-sni-resumption since that document is going through the process. (We >> could also make it 7 or

Re: [TLS] IANA Registry for TLS-Flags

On Wed, Dec 8, 2021, at 08:32, Salz, Rich wrote: > As one of the current designated experts, I’d rather there were almost > no room for judgement or subjectivity in assignments. This is part of why I think that Rich is an excellent choice of designated expert :) Judgment is what we have the

Re: [TLS] ECH - handling retry config with different public name?

I assume that you might add "just once" there. Or at least a limited number of times. Infinite regress seems like something worth avoiding. outer1 -> outer2 -> outer1 is likely not a great outcome. On Sat, Nov 6, 2021, at 02:20, David Benjamin wrote: > That's my inclination as well. It's an

Re: [TLS] tls@ietf112

Hey Sean, what is "Zero-Knowledge Proofs meet TLS"? I can't find a draft and the link in the agenda is busted. On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote: > Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from > 1600-1800 (UTC). Please send in your agenda topics along

[TLS] Artart last call review of draft-ietf-tls-external-psk-guidance-03

Reviewer: Martin Thomson Review result: Ready with Issues This document addresses some of the less obvious aspects of how pre-shared keys can be used in TLS. A lot of this advice isn't specific to TLS, but it is a helpful document. For someone who might be deploying a protocol that relies

Re: [TLS] Late DLS 1.3 issue

I left a comment, but I don't think that the fix, as it is specifically proposed, works. The general shape of the proposal seems credible. A larger epoch space, of which we only send the least-significant bits, would seem to address the concern. But the proposal doesn't specify what to do

[TLS] =?UTF-8?Q?Re:__FYI, _a_subverted_implementation_attack_against_TLS_a?= t ia.cr/2020/1452

I don't think that this is a particularly important result. The formalism is perhaps valuable, but the intuition is not novel: if you control an endpoint and it can send messages, those messages can contain information. There are far too many places in almost any protocol where information

[TLS] Intolerance for delegated credentials

Hey, We've found a server that is intolerant of our offer to use delegated credentials. This seems to run a modern nginx and TLS 1.3, but it is not producing the same handshake keys as us, so I can't tell if it supports the extension or not (as the EncryptedExtensions message is

Re: [TLS] RFC8447bis

On Thu, Aug 19, 2021, at 23:14, Salz, Rich wrote: > I understand this concern. I am sympathetic to it. But perhaps > large-scale experiments on the whole Internet aren't the scope here? > Those kinds of things seem to ask for an early allocation. I am > thinking, in particular, of some

Re: [TLS] RFC8447bis

On Thu, Aug 19, 2021, at 12:30, Sean Turner wrote: > The primary reason we are proposing this approach is that it seemed to > us to be a bit more explicit about the numbers in this space being part > of an experiment. The added benefit here is that we are in some sense > greasing the bits too.

Re: [TLS] RFC8447bis

On Wed, Aug 18, 2021, at 11:31, Eric Rescorla wrote: > I'm a bit less sure about randomly versus sequentially, but I could go > either way. IIRC the QUIC thing leaned somewhat on the space being very > big. That is true. QUIC has a large space, but TLS is a lot smaller. This is just my

Re: [TLS] RFC8447bis

I don't think that this approach is the best we could do. Experiments, particularly large-scale ones, turn into deployments. Consequently the difference between "an experiment" and "a standard" is the date at which you look. See also RFC 6648. In that light, why not use the entire unassigned

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

This document is mostly fine. The text on use of client certificates isn't particularly clear. The key piece of information that a reader is going to need is that a resumed connection will include any (and potentially all) client authentication. I found the meat of the flag definition hard to

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

I think that this is largely good. I don't like how the IANA registry is structured and would like to discuss it more. I think that it is 0-31 (Standards Action), 32+ (Specification Required), but it doesn't say that. I think that the experimental range (64-79) should not be reserved.

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

On Sat, Jul 31, 2021, at 06:25, Carrick Bartle wrote: > are you opposed to fully deprecating FFDHE? If so, why? No so much opposed as that it is not necessary. Though the TLS 1.2 variant is - as others have noted - close to impossible to negotiate the "good" groups, it's not concretely bad

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

I support the *contents* of this document. The title, however, I can't agree to. So I want to be clear about the scope of the work, namely deprecating semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with reused keys. The draft limits the ban on ephemeral key reuse to

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote: > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 > ). > There was

Re: [TLS] Adoption call for "Secure Negotiation of Incompatible Protocols in TLS"

On Fri, Jul 30, 2021, at 04:20, Christopher Wood wrote: > Based on positive feedback during this week's meeting, we'd like to > start an adoption call for "Secure Negotiation of Incompatible > Protocols in TLS." The document may be found here: > >

  1   2   3   4   5   6   7   8   >