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: > >

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.

[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,

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

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

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

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

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

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

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

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

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

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 >

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] 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] 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

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

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 > up a l

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

[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

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

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 >

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 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

Re: [TLS] Don't Split HelloRetryRequest

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. > > &g

Re: [TLS] Don't Split HelloRetryRequest

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 HelloRetryRequest into ou

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

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

[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

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

s. > 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 reflect that. > &

[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

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

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] 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

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

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] [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

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,

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)

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

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

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 it's not always easy to enumerate a

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 > > descr

[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] [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

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

[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

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

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

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

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

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,

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

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

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

ing 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 share session tic

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. 

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

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

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 >

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] 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

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

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

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,

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

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

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

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

[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

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

Re: [TLS] Application-Layer Protocol Settings

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.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/> >

Re: [TLS] Application-Layer Protocol Settings

Hi Victor, For HTTP/2, this is essentially a noop, as endpoints are required to send SETTINGS immediately. Whether these bytes appear before Finished or not only affects endpoints that aren't inclined to wait for SETTINGS. This is somewhat complicated by the way that TLS 1.2 and TLS 1.3

Re: [TLS] Proposed change in TLS-Flags

More to the point, this makes it more difficult to analyze relative to an empty "flag" extension of the likes we currently use. I haven't implemented this, but I imagine one strategy would be to rewrite these flags and pretend that they were empty extensions. That would allow implementations

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

On Fri, Jun 5, 2020, at 03:54, Russ Housley wrote: > > On Jun 4, 2020, at 12:37 PM, Eric Rescorla wrote: > > Changing: > > TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk"

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

On Thu, Jun 4, 2020, at 11:44, Eric Rescorla wrote: > I think it would help to be more explicit here: > Servers which are authenticating with a resumption PSK MUST NOT send > the CertificateRequest message in the main handshake, [...], > Servers which are authenticating with an external PSK MUST

Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

I think that this is a useful erratum and it should be approved/HFDU. The extension to which this text alludes is RFC 8773, not post_handshake_auth. There is one other piece to this that is very confusing, and less clear. "Servers which are authenticating with a PSK MUST NOT send the

Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

I've reviewed it, it's mostly fine. I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is

Re: [TLS] Banning implicit CIDs in DTLS

On Fri, May 22, 2020, at 01:58, Christopher Wood wrote: > PR #148 I think that this is the right solution to this problem. > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I'm not

Re: [TLS] Integrity bounds in DTLS

On Fri, May 15, 2020, at 20:29, Thomas Fossati wrote: > While the specific behaviours might more or less differ, the same > considerations apply to 1.2. How do we make sure that the message > doesn't get ignored? Would it be worth drafting this separately to > cover both versions (+ an explicit

Re: [TLS] Integrity bounds in DTLS

Continuing the trend where I am the only one to post to this thread... I just posted a proposal: https://github.com/tlswg/dtls13-spec/pull/147 This is essentially a transcription of the work done for QUIC to DTLS. There is one major change, in the addition of TLS_AES_128_CCM_8_SHA256. QUIC

Re: [TLS] Integrity bounds in DTLS

On Fri, May 1, 2020, at 14:51, Martin Thomson wrote: > Thanks to some good work from Felix Günther, Marc Fischlin, Christian > Janson, and Kenny Paterson we now have a new result to share about the > integrity limits in QUIC. > > There is a long write-up in > https://gith

[TLS] Integrity bounds in DTLS

Thanks to some good work from Felix Günther, Marc Fischlin, Christian Janson, and Kenny Paterson we now have a new result to share about the integrity limits in QUIC. There is a long write-up in https://github.com/quicwg/base-drafts/issues/3619, the conclusion of which is that endpoints need

Re: [TLS] Choice of Additional Data Computation

On Mon, Apr 27, 2020, at 17:06, Hannes Tschofenig wrote: > (*): Even if we optimize the CID away with cTLS the question about the > security implications will surface again. I think that cTLS is the answer to the size issue. But there, the rule tends to be that removing from the wire doesn't

Re: [TLS] Choice of Additional Data Computation

On Sat, Apr 25, 2020, at 01:56, chris - wrote: > However, the formal > models of [1,2] assume reliable transport (i.e., TCP): failure to > deliver packets in order is deemed an attack. Therefore, the > definitions would need to be changed in order to account for the case > of DTLS. (I'm not

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

Hi Hannes, Let me see if I can clarify then :) On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote: > > Say that a connection spans two network paths. CID A is used on path > A; CID B is used on path B. > I guess you are considering a scenario where a device, of the lifetime > of the

Re: [TLS] Implicit ACKs in post-handshake

What makes this case interesting is the non-machine time that might exist between receiving CertificateRequest and sending Certificate. In most of the exchanges, we expect there to be an answer that is immediately available, so that the implicit ACK works. Here we have to recognize that ACK

Re: [TLS] DTLS 1.3 AEAD additional data

On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote: > You criticize that an implicit CID which is still included in the AAD > requires state on the receiver when processing multiple records within > a single datagram, which is true. I'm saying that the same holds for > the PR 143 which adds the

Re: [TLS] DTLS 1.3 AEAD additional data

On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > OK but we would expect the peer to process CID-less records if they are > coalesced? I guess so. If we allowed them to drop them, then we're close to saying MUST NOT omit. On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > But

Re: [TLS] DTLS 1.3 AEAD additional data

On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote: > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson wrote: > > I prefer Ekr's solution, but I would go with that being a recommendation > > (SHOULD) as opposed to a requirement (MUST). > > Can you clarify where you think

Re: [TLS] DTLS 1.3 AEAD additional data

I prefer Ekr's solution, but I would go with that being a recommendation (SHOULD) as opposed to a requirement (MUST). I was initially inclined toward doing nothing at all, but there is an attack of sorts that is worth avoiding here. Say that a connection spans two network paths. CID A is used

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

I made a few comments on the pull request, but they are minor. Let's do this. On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote: > hi TLS WG, > > During the consensus call to determine whether ticket reuse use cases > should be supported we did not see consensus to add that text, but we > did

Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

I like this work, but I don't believe this to be ready yet. S1 None of the current proposed extensions are such that the server indicates support without the client first indicating support. So as not to preclude future extensions that are so defined, this specification allows the

Re: [TLS] Efficiency of ACKing scheme

Hi Hanno, I think that you are assuming a lot about how the loss recovery part of the sender is operating here. If you receive ACK { 1, 3 }, then it might be reasonable to assume that 2 got lost, but it seems to me that assuming anything about 4 is premature. As you say, delaying ACKs is a

Re: [TLS] Dropping "do not stick out" from ECHO

On Mon, Mar 23, 2020, at 03:54, Christopher Wood wrote: > I propose we remove this requirement and add an explicit signal in SH > that says whether or not ECHO was negotiated. Here's a spitball signaling option that might not stick out: Client sends (in the ECHO) a random value, N, with 32(?)

Re: [TLS] heads-up: ALPN ID allocation for NTP security with "Recommended" as "Y"

On Wed, Mar 11, 2020, at 10:45, Benjamin Kaduk wrote: > For purposes of increased visibility, I note that > draft-ietf-ntp-using-nts-for-ntp is making an ALPIN ID registration and > requesting to be marked as "Recommended" in the registry. The > high-level summary of the NTS-KE protocol is to do

Re: [TLS] I-D Action: draft-rescorla-tls-ctls-04.txt

On Tue, Mar 10, 2020, at 14:17, Watson Ladd wrote: > One thing I noticed from my reading is there is no gain from knowing > an extension will be present if one doesn't also know the value. That is only true if the extension has a value. (See also flags) > I could imagine SNI being very useful

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

On Fri, Mar 6, 2020, at 12:28, Benjamin Kaduk wrote: > Other than this bit about giving resumption_count of zero additional > semantics than "I am requesting zero tickets if resumption succeeds", I > actually think this proposal is quite good. The comments I left on PR > 18 are effectively

Re: [TLS] Session resumption ticket reuse considered harmful

On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote: > unless both parties agree. It takes two to agree. RFC 8446 says: Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. Are you arguing that

<    1   2   3   4   5   6   7   8   >