Re: [TLS] 0-RTT, server Application Data, and client Finished

On 27 January 2016 at 14:11, David Benjamin wrote: > Why do you say it's an optimization? They're exactly the same except the > simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a > combination that's possible with or without my restriction) and the other is > a brand new han

[TLS] ECDH_anon

4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon cipher suites. I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0-RTT, server Application Data, and client Finished

On 28 January 2016 at 02:09, Watson Ladd wrote: > All 0-RTT data is replayable, but I don't see what replaying a > authenticated replayable connection gets you. If the 0-RTT flight includes actions (especially non-idempotent ones) that only apply if the authentication is correct, then you get aut

Re: [TLS] ECDH_anon

On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL wrote: > Anon ‎!= Ephemeral, despite some similarities. >From a protocol perspective, they are the same. The distinction at the protocol level between ECDH_RSA (for example) and ECDH_anon is that ECDH_anon requires a ServerKeyShare mes

Re: [TLS] ECDH_anon

On 1 February 2016 at 16:56, Dan Harkins wrote: >>>From a protocol perspective, they are the same. The distinction at >> the protocol level between ECDH_RSA (for example) and ECDH_anon is >> that ECDH_anon requires a ServerKeyShare message in the same way that >> ECDHE_RSA does. > > So? A stati

Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)

This really only helps on the first connection attempt. Browsers already pre-warm connections to subresource hosts. On 19 February 2016 at 16:38, Dave Garrett wrote: > I just had an idea. There is significant doubt of how useful semi-static DHE > 0RTT would be due to the difficulty of distribut

[TLS] Remove 0-RTT client auth

I'm sitting here in TRON listening to Karthik describe all the various ways in which client authentication in 0-RTT is bad. I'm particularly sympathetic to the perpetual impersonation attack that arises when the client's ephemeral key is compromised. We originally thought that we might want to do

Re: [TLS] Unified Client Authentication

On 21 February 2016 at 11:33, Watson Ladd wrote: > Currently we client authenticate after handshake and during handshake. > Why not unify these by making all client authentication take place > after the handshake? This will simplify the state machine. I believe that we discussed this extensively

Re: [TLS] Remove 0-RTT client auth

On 21 February 2016 at 11:41, Cedric Fournet wrote: > Agreed. For what it is worth, 0-RTT with PSK would still provide implicit > client authentication. s/would/could That implies many of the hazards that we were talking about here, so none of this makes 0-RTT any less of a hazard. ___

Re: [TLS] Remove 0-RTT client auth

On 21 February 2016 at 12:01, Adam Langley wrote: > The token-binding(*) folks care about authenticating 0-RTT requests, > although they are currently working at the application-layer[1] and so > would be recreating 0-RTT client authentication on top of TLS. (They > would thus have all the same is

Re: [TLS] Remove 0-RTT client auth

On 21 February 2016 at 12:06, Eric Rescorla wrote: > I think we're going to have to invent a 0-RTT exporter (yes, I understand > that this > requires care). We might disagree about that "have to". I'd be happier if the 0-RTT data couldn't rely on the existence of an exporter. If that means that

Re: [TLS] Remove 0-RTT client auth

On 21 February 2016 at 21:46, Ilari Liusvaara wrote: >> We originally thought that we might want to do this for >> WebRTC/real-time. As it so happens, we have an alternative design >> that doesn't need this, so... > > Got mailarchive or draft link? No, this was a realization that we could just s

Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

On 23 February 2016 at 10:43, Benjamin Kaduk wrote: > But leave it as a relative time, contrasting the absolute expiration time of > the server configuration -- why not go for full-out parallelism? As I have said before, the value of absolute time here is that it allows for the use of server con

[TLS] Remove DH-based 0-RTT

Now that the other issue is in the bag, let's talk about making some real savings. I propose that we remove DH-based 0-RTT from TLS 1.3. As ekr's previous mail noted, the security properties of PSK-based 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is much more complex. For

[TLS] 0.5 RTT

Karthik raised some concerns here, and I think that we have some thinking to do. But I don't think that it is intractable, nor even hard, to reason about this problem. The only thing that the client's second flight provides is authentication. The Finished isn't needed if there is no client auth

Re: [TLS] Remove DH-based 0-RTT

On 23 February 2016 at 11:24, Wan-Teh Chang wrote: > It seems sufficient to just ban client authentication in replayable > DH-based 0-RTT. Why remove DH-based 0-RTT altogether? On the grounds that it is more complex to analyze, build, and test. And given that deferring the feature does no signifi

Re: [TLS] 0.5 RTT

On 23 February 2016 at 13:24, Hugo Krawczyk wrote: > As for downgrades, this will be discovered by the server when receiving the > client's Finished message. Won't a downgrade be detected by the client when it fails to decrypt the server's data? If the server was given a false impression about t

Re: [TLS] 0.5 RTT

On 23 February 2016 at 14:01, Karthikeyan Bhargavan wrote: > The main downgrade concern, I think, is for the 0.5-RTT data’s > confidentiality; i.e. it may have been sent encrypted under a broken cipher. Hmm, that's a good point. So Antoine's analogy is closer to correct than I had thought, and

Re: [TLS] 0.5 RTT

On 23 February 2016 at 14:26, Hugo Krawczyk wrote: > Karthik, I think that what you are pointing to are cases where the client > *is* authenticated via its PSK. In the downgrade scenario, that doesn't seem right, but maybe it's just that the client's ClientHello is being authenticated.

Re: [TLS] 0.5 RTT

On 23 February 2016 at 14:37, Hugo Krawczyk wrote: > It seems to imply that you are attaching some "client-specific semantics" > even to keys that were not authenticated by the client. It's primarily a privacy concern, though it's a pretty weak concern. __

Re: [TLS] Remove DH-based 0-RTT

On 24 February 2016 at 07:44, Subodh Iyengar wrote: > Unless we add a way for the client to require a server authentication during > PSK resumption. I have been arguing for this now for a while. If there is an incentive to do "PSK resumption" (there is), and that does not provide the client a wa

Re: [TLS] Remove DH-based 0-RTT

On 24 February 2016 at 08:34, Watson Ladd wrote: > And if we require a DH+sign every resumption, we don't gain anything > over the full exchange except 0-RTT. Why is this server liveness issue > not considered a problem for TLS 1.2 resumption? It wouldn't be a requirement, merely an option. In

Re: [TLS] Remove DH-based 0-RTT

On 24 February 2016 at 10:00, Ilari Liusvaara wrote: > Be careful with that: One can get server impersonation attacks unless > one somehow binds the SS into signature (and unlike with client sigs, > there is no straightforward way). The key schedule, in every variation I've seen proposed, does th

Re: [TLS] RSA-PSS in TLS 1.3

On 1 March 2016 at 04:32, Joseph Salowey wrote: > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. >From my perspective, this is fine. I would like to say that we

Re: [TLS] RSA-PSS in TLS 1.3

On 1 March 2016 at 16:06, Viktor Dukhovni wrote: >> It is much easier to mandate PSS in TLS 1.3 now, than to remove it >> later. Servers that can't do PSS will use TLS 1.2. This avoids >> a break-the-web day. > > Sorry, ... than to remove *PKCS#1.5* later ... Yes, this is true for some people,

Re: [TLS] Application-Layer Protocol Settings

ns and NewSessionTicket are ordered. > > On top of this, the half-RTT point in a non-0-RTT connection is a weird > state. Not all connection properties (e.g. client certs) have been > established yet, and writes out of turn are tricky. This message > <https://mailarchive.ietf

Re: [TLS] Application-Layer Protocol Settings

On Thu, Jul 9, 2020, at 00:13, Victor Vasiliev wrote: > For what it's worth, I don't think we should define a new ALPN token > for that; using ALPN tokens for flags will eventually lead to > combinatorial explosion (e.g. "if we define h2_half_rtt, we have to > define h2c_half_rtt", etc), and can

[TLS] Authenticating incompatible protocols

The work in DNSOP on the SVCB record raised a few awkward questions about the potential for downgrade attacks. Where protocols aren't compatible -- that is, A is not compatible with B if you can't attempt A and negotiate B -- you don't get downgrade protection. ALPN only really protects agains

Re: [TLS] Authenticating incompatible protocols

On Wed, Jul 15, 2020, at 08:53, Ben Schwartz wrote: > For ease of deployment, I wonder whether the concept of a "scope" needs > to be pinned down a bit more precisely. In 00 here, the scope is > entirely implicit; servers are required to know how users might have > found them, and what other se

Re: [TLS] RFC 8449 – DTLS 1.2 considerations

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 missing. This is a question we dealt with in QUIC by limiting UDP datagram size rather than the record size (or packet size in QUIC terminology). In this case, the sp

Re: [TLS] invariant or not: one TLS connection per TCP connection?

On Wed, Jul 8, 2020, at 14:22, Benjamin Kaduk wrote: > Hi all, > > There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently > in IESG Evaluation): > >The protocol convention specified in the current document assumes >there can be no more than one concurrent TLS session per TC

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

I'm OK with adoption. That said, I believe that this falls a long way short of addressing the attacks that I'm aware of. But that assumes we share an understanding about what those attacks are. To begin with, we probably need a clearer description of goals. To give an idea, address valida

Re: [TLS] Authenticating incompatible protocols

On Thu, Jul 16, 2020, at 06:52, Ben Schwartz wrote: > Basically, I think this draft should probably either name the scope or > be specific to SVCB, to avoid cases where the scope is ambiguous. > Naming the scope, and providing a scope identifier meaning "IP and port > number", would often be su

Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp

On Mon, Jul 20, 2020, at 03:34, Ron Bonica wrote: > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp > . I think that others have said enough about the wisdom of adoption of the approach. I agree with them, b

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Hi Eric, On Wed, Jul 29, 2020, at 07:18, Eric Wang (ejwang) wrote: > In any case, the proxy has to conduct selective proxying in a safe, > non-disruptive manner. I will try to be clearer on this point. This requires design work and this document is a poor vehicle for that. It needs a separat

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

On Tue, Aug 18, 2020, at 07:09, Christopher Wood wrote: > HPKE recently removed the Hash() interface from the KDF, which means we > need to either (a) change how the config_digest (formerly > record_digest) is computed, or (b) constrain ECH to HKDF-based HPKE > ciphersuites. This PR takes approa

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

On Tue, Aug 18, 2020, at 07:55, Christopher Patton wrote: > Hi Martin, > > > Or maybe just running the HPKE KDF with a fixed input. > Do you mean something like this? Let `config_digest = KDF.extract("some > salt", "some label", config)`, where `config` is the ECH configuration? Sure. I wo

Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

On Tue, Aug 18, 2020, at 09:04, Christopher Patton wrote: > Just to be clear, you're proposing something like this? Referring to > the KDF API called for in draft-irtf-cfrg-hpke-05: > > config_digest = Expand(PRK=Extract("some_salt", "some_label", > IKM=config), "some_info", 16) > It's maybe

Re: [TLS] TLS ECH, how much can the hint stick out?

On Fri, Sep 11, 2020, at 08:11, Eric Rescorla wrote: > OK, this can't happen in DTLS because the CID management works differently. Right. > While it's not clear to me that QUIC explicitly prohibits this (it > would be prohibited if CRYPTO frames were STREAM frames because of > draft-ietf-tls-qu

Re: [TLS] TLS ECH, how much can the hint stick out?

On Sat, Sep 12, 2020, at 21:55, Karthik Bhargavan wrote: > > Any big issue keeping N=8 > > Regarding the length of N, I gather that the trade-off is that if it is > too short, the probability of collisions between the signal and > randomly generated server randoms becomes significant, > and s

Re: [TLS] TLS 1.3 Problem?

On Tue, Sep 29, 2020, at 10:38, Watson Ladd wrote: > > Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state,

Re: [TLS] TLS 1.3 Problem?

On Wed, Sep 30, 2020, at 01:14, Michael D'Errico wrote: > Also, are you sure you want to do this?  The design of > TLS 1.3 was supposed to make it fast, but creating a > pseudo session ticket for every connection requiring a > HRR and then validating and decoding it is going to be > really slow.  A

Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

7;m resending this with a more appropriate Subject line. --Mike] > > On 9/29/20 19:51, Martin Thomson wrote: > > It's symmetric crypto[1]. Hardly worth noting. > > [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that > > server clusters can sh

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

Oh, I consider that to be a feature. One that I exploit. It's sometimes awkward to build a structure then prepend a length that has a variable-length encoding. If you know the maximum length, the varint encoding allows you to avoid having to move memory. That said, cTLS won't authenticate bo

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

On Tue, Oct 6, 2020, at 17:36, Hannes Tschofenig wrote: > In the work on QUIC did you discuss the ability to make the encoding > such that there are no ways to express a number in two different ways, > as shown in your example with the single byte 25 decoding to 37 and the > two byte sequence 40

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

On Wed, Oct 7, 2020, at 04:12, Christian Huitema wrote: > * Receiver side: receive the message, save it, parse and process, and > when it is time to verify the signature go back to the original message > and check the signature. I think that you mean: receive the message, check the signature, the

Re: [TLS] TLS WG GitHub interaction

On Thu, Oct 22, 2020, at 10:04, Rob Sayre wrote: > On Wed, Oct 21, 2020 at 3:51 PM Christopher Wood wrote: > > > > We'd like to hear whether folks are support or oppose this proposal. Please > > chime in (on the list!) and share your thoughts before November 4. We'll > > determine whether there

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

I've no objection to adopting this, though I will note that it is likely of minimal use in the browser context due to the move to isolated storage (which includes tickets). The potential value for cross-origin connections on the same page exists, but it would be good to understand whether the a

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

On Tue, Nov 10, 2020, at 22:05, Stephen Farrell wrote: > I'd be more in the "not yet" bracket for this. As Martin > mentions this'd seem to create a possibly attractive way > to do more tracking, so I think we ought try understand > how that might fit into the wider set of new things (e.g. > the HT

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

On Wed, Nov 11, 2020, at 09:28, Victor Vasiliev wrote: > > Thus, the draft needs to include privacy considerations, particularly > > regarding cross-origin tracking. I am also of the opinion that it should > > use flags, but that would depend on changes to the flags draft. > > I considered that

Re: [TLS] ALPS and TLS 1.3 half-RTT data

Hi David, Thanks for writing this up. I think that it helped clarify things a little in my mind. I had been separately thinking about the problem and did reach a conclusion. I just needed time to write a response. I think that there are two things you might want to separate here: what might

[TLS] Extension codepoints 40 and 46

Hey All, Dry clerical stuff, sorry. In getting an assignment for the QUIC extension to TLS, the first codepoint IANA chose to assign was 46. In implementing this, I discovered that this was assigned a value already in our implementation and I was unable to use that value. The history here is

Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi All, Ben asked me to take a look at this draft and I think that the general gist of Ben's comments need some careful consideration. # Commitment Message I think that Ben's concerns about the Commitment Message are justified, but aren't as bad a layering violation as observed (almost). It w

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote: > [Joe] I'm not sure I remember correctly, but I think the commitment > message was to make the integration with EAP statement machine cleaner > and perhaps to future proof against additional messages sent after the > handshake. I tend to agr

[TLS] draft-thomson-tls-snip-01

Hi all, I've refreshed this draft: https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ Synopsis: This describes a method for protecting against downgrade attack when protocols are in some way incompatible such that ALPN cannot provide that protection. This revision is an attempt to more

Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote: > > I have a much simpler one: the EAP layer has a signal that the > > protocol is complete: EAP-Success > Alan Dekok explained in a separate email thread why this is not the > case > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASo

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi Alan, On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote: > On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote: > > Your point about reliability is confusing. I've read Section 4.2 of RFC > > 3748 and while it says "A peer MUST allow for this circumstance as > >

Re: [TLS] draft-thomson-tls-snip-01

s a new incompatible protocol, everything will work fine, but SNIP > will flag this as an attack, possibly making the customer's site > unreachable. > > The problem is that the SVCB scope doesn't identify _which_ SVCB RRSet > it's referring to, and

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

Trimming this down. On Wed, Jan 6, 2021, at 14:53, Benjamin Kaduk wrote: > I didn't expect to find much appetite for changes, but I wouldn't be doing > my job if I didn't ask the question. It's a little unusual for something > outside the core protocol to change the behavior of an extension defin

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

I'm not sure that the other discussions are productive any more, so I'll fix my errors... On Thu, Jan 7, 2021, at 15:04, Benjamin Kaduk wrote: > > This isn't an "Updates: X" moment at all in my view. Extensions to TLS > > have added new handshake messages (certificate status for instance) with

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Hi Joe, Thanks for doing this, I think that this is a distinct improvement (and I will take your word for the difficulties involved with further splits). One point that I made poorly perhaps, and was dismissed, might be worth restating: MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote: > Thanks for pointing this out. I think Ben also mentioned this in his > review. I am not sure if it is necessary to add the type-code to the > label when it is already part of the label string as 'EAP_TLS'. Other > TLS based EAP methods should

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Jan 11, 2021, at 17:07, Joseph Salowey wrote: > > > On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson wrote: > > Hi Joe, > > > > Thanks for doing this, I think that this is a distinct improvement (and I > > will take your word for the difficul

Re: [TLS] Flags extension and announcing support

On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote: > See this PR: https://github.com/tlswg/tls-flags/pull/5 It looks like there is lots of disagreement there. I'm going to disagree with others too. > All except the first are Server-side. Certificate is client-side too. > The controversy is about

Re: [TLS] ALPS and TLS 1.3 half-RTT data

On Sat, Jan 30, 2021, at 10:38, David Benjamin wrote: > How does NSS expose the late client authentication to the application? > I thought NSS didn't support half-RTT at all when the server requests > client certificates, but perhaps I misunderstood. There are three states we use with respect to

Re: [TLS] [ECH] Reverting the config ID change

On Wed, Feb 17, 2021, at 08:31, Christopher Wood wrote: > That's true, but I'd personally prefer one tracking vector to two. This > structure also better aligns with other proposed use cases for HPKE > configurations. I also don't see an immediate need for flexibility in > this value given that

Re: [TLS] Moving the ECH interop target

This should be fine. Moving to HPKE-v1 will remove an awkward dependency problem now that we're starting to use HPKE for other things. On Thu, Feb 25, 2021, at 05:07, Christopher Wood wrote: > The WG previously decided to make draft-ietf-tls-esni-09 the official > target for interop. The diff b

[TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Well overdue. We should do this. The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the document content. I only see static or semi-static DH and ECDH key exchange being deprecated (in the document as non-ephemeral). ___ TLS m

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

mplementations. > https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ > https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 > https://weakdh.org/ > > On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle > wrote: > > Agreed. I'll change the title to

[TLS] Don't Split HelloRetryRequest

I just reviewed the proposal to split HelloRetryRequest into outer and (encrypted) inner. https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files I'm strongly opposed to taking the change. It complicates the design greatly and unnecessarily. The existing design has some flaws, but they ca

Re: [TLS] Don't Split HelloRetryRequest

I'm going to briefly respond, but as this is a public holiday and I have no real desire to work too much, please forgive any radio silence that follows. On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote: > This was a previous attempt at this, but it seems to have been confusing. > > I do agree

Re: [TLS] DTLS/SCTP and fragmentation

You could also do SCTP over DTLS, which is what WebRTC uses. On Tue, Apr 6, 2021, at 02:40, Rick van Rein wrote: > Hello Michael, > > Thank you! I was searching for options, things that should go into > DTLS, but I was unaware of the attempts of mapping it better to SCTP. > > > What about using

Re: [TLS] Don't Split HelloRetryRequest

. I would expect most implementations to be compliant already (it's much more work not to be). The whole set: https://github.com/tlswg/draft-ietf-tls-esni/pulls/martinthomson On Thu, Apr 1, 2021, at 12:57, Martin Thomson wrote: > I just reviewed the proposal to split HelloRetryRequ

Re: [TLS] Don't Split HelloRetryRequest

RR (a simpler alternative to #407). > > Best, > Chris P. > > On Mon, Apr 5, 2021 at 7:29 PM Martin Thomson wrote: > > I've created a few pull requests that make the changes I propose. I think > > that the whole suite of related issues are closed as a result. >

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote: > Taking a step back, it would be great if we could reach consensus on > whether or not this is a use case we actually want to solve. The Web currently recognizes IP certificates. The specs, thanks RFC 6125, largely missed this, but we're

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote: > This does sound unusual. That said, if this sort of set-up is possible > (which presumably it is), it seems unfortunate to make ECH impossible > in that scenario. I'm not sure what you are implying might be impossible. Are you suggesting

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote: > > I'm not sure what you are implying might be impossible. Are you suggesting > > that it might be impossible to get a name for which you could get a > > certificate? > > No. I'm implying that if we don't allow clients to authenticate > cl

Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote: > An early version of this specification proposed a XoT specific ALPN in > order to distinguish this from a connection intended to perform > recursive to authoritative DoT (often called ADoT). ADoT is not yet > specified, but is the subject o

[TLS] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

(dprive to bcc, because this is getting further afield) On Fri, Apr 30, 2021, at 00:26, Salz, Rich wrote: > >No new protocol should use TLS without ALPN. It only opens space for > > cross-protocol attacks. Did the working group consider this possibility in > > their discussions? > > I don

Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

On Fri, Apr 30, 2021, at 16:25, Valery Smyslov wrote: > The original motivation for 7525bis was to update RFC 7525 in light of > TLS 1.3 appearance. > However, I believe that recommendations for using ALPN are in scope of > this document. How about a new Section 3.7 "Application-Layer Protocol N

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

; What you might be missing is that Martin Thomson chose what to me is an > unintuitive definition of off-path attacker. On-path means that you a > router that you can drop a packet. An off-path attacker might be an > observer, which can see the packets, or not. I hope that clears things &

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

What Russ said here is important. However, I don't see any reason that this record should not be protected. I also think that we can use a content type outside of the scarce range we have for TLS record content types. This only makes sense for use with DTLS 1.3 and DTLS 1.2 with connection ID

Re: [TLS] SNI as authorization token?

I agree with Rob here. Removing the appendix would be best. It's true that some servers have special names, but that is for operational reasons. Pretending that something you put on the wire in the clear is a security mechanism would be dishonest. This reminds me of port knocking. It's not

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

On Wed, May 5, 2021, at 15:51, Achim Kraus wrote: > For me, this requires, that cid is used in both directions. If not, the > "elicits" doesn't work, or? If both parties are using CID in order to > signal, that the addresses are changing, my feeling is, this scenario is > not that common. (Even

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

Given that RFC 5246 is obsolete, all of this is largely moot. I think that we can reject this erratum. On Thu, May 6, 2021, at 09:06, Benjamin Kaduk wrote: > I agree that this isn't an appropriate change for an erratum. > > Even with a new RFC updating RFC 5246, we'd still need to have some > di

Re: [TLS] Constant-time Algorithms

On Wed, May 19, 2021, at 01:58, David Benjamin wrote: > constant-time should be a default baseline requirement for implementing any > cryptographic primitive. Or put more generally, ... Avoiding side channels through value-independence should be a default baseline requirement for handling any s

Re: [TLS] Narrowing allowed characters in ALPN ?

I think that we would need stronger reasons than "it's annoying". There are good reasons to use octets that map to simple ASCII. We should continue to only define identifiers that use those characters. However, a specification is also a commitment and whether or not it was a good idea, we (th

Re: [TLS] 0-RTT in DTLS 1.3

On Sun, May 23, 2021, at 16:05, Hanno Becker wrote: > 1) In DTLS 1.3, it would seem common for the server to send an HRR for > the sake of return routability checking. TLS 1.3 forbids the use of > 0-RTT after an HRR. So, 0-RTT can't be used in DTLS 1.3 if the server > requires return routability

Re: [TLS] 0-RTT in DTLS 1.3

On Mon, May 24, 2021, at 14:19, Hanno Becker wrote: > Yep, that's clear - my question was whether the DTLS 1.3 Spec should > contain an explicit > reminder of that, e.g. when it claims that cryptographic material is > uniquely identified > by epochs. This wouldn't be true if you could send 0-RTT

Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

It seems to me like the next step is to share a paper, ideally in the form of an internet-draft, that describes more precisely what you would like to see happen. On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote: > Dear all, > > first, we want to thank you for your feedback, it is much appr

Re: [TLS] ECH Padding

So I like #443 as I have said. It simplifies padding for CHInner a lot. I also like #457 (option 3). My initial reaction was not positive, but I've come to appreciate the value of it. I don't like that this has to be in the transcript (QUIC doesn't need it by virtue of a design that separates

Re: [TLS] Editorial: chronological order in ECH draft

Whatever you can do to improve the readability of this document would be greatly appreciated. It's a complicated design and I always spend far too much time trying to find answers to my questions. A better structure would be appreciated. I do find that questions aren't always about behaviour.

Re: [TLS] What's it called

On Fri, Jun 25, 2021, at 05:13, Tim Bray wrote: > How much data is too much? https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-irtf-cfrg-aead-limits.html ...shameless self-promotion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman

Re: [TLS] Advancing draft-ietf-tls-hybrid-design

I just took a look. I didn't read the (large) appendices, though I appreciate that they have value. The draft is largely in good shape. I have a few minor concerns. I don't think that you want to reserve the hybrid_private_use(0x2F00..0x2FFF) range of values. There were specific reasons for

[TLS] SNIP: simplified negotiation of incompatible protocols

I've updated my version of the draft we discussed a while back. After time to reflect, I was convinced by feedback from Benjamin Schwartz suggesting that the more complicated bits of the proposal could be simplifed greatly. So I did that. Hopefully this is a little easier to comprehend, imple

Re: [TLS] Possible TLS 1.3 erratum

On Mon, Jul 19, 2021, at 23:25, Hubert Kario wrote: > That's because browsers don't have the code to handle RSA-PSS certificates. Not ALL the code, but we only have one small piece left in Firefox. And we have plans to address the final small piece. So maybe soon. _

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: > >https://datatracker.ietf.org/doc/draft-thomso

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 suppor

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 FF

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 whe

<    1   2   3   4   5   6   7   8   9   >