Re: [TLS] TLS1.3 Ticket Usage Across Versions

It could be valid to populate both if the client wishes to offer both a TLS 1.2 session and a (different!) TLS 1.3 session. I don't believe there's any prohibition on this per se. But I've not heard of any client doing this. It seems needlessly fussy and interacts awkwardly with the appendix C.4 me

Re: [TLS] supported_versions in TLS 1.2

The operators themselves are probably not in a position to either implement supported_versions or not in TLS 1.2. If an operator, for whatever reason, only has a TLS 1.2 implementation on hand, it presumably predates TLS 1.3 and thus does not implement supported_versions. If it implements supported

Re: [TLS] supported_versions in TLS 1.2

I think that's right. There's not much benefit to adding supported_versions to a TLS-1.2-only stack. We introduced it in TLS 1.3 because of compatibility issues and because it was more flexible and less prone to compatibility issues going forward. The forward-looking benefits don't really apply her

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

On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz wrote: > I continue to support this draft. > > I am puzzled by the requirement that "A server MUST omit any compatible > protocols from this extension". Including them seems harmless, and > omitting them seems to impose an unstated requirement that (1

Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Following the discussions around draft-bartle-tls-deprecate-ffdh and > draft-aviram-tls-deprecate-obsolete-kex, and after consulting the chairs, > we have merged the two drafts into draft-aviram-tls-deprecat

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

I don't think the upgrade path needs any mention or changes. It's no different from what we always do: allocate a new code point. Now that we've removed all the in-protocol combinator schemes from the early versions, what remains is simply *a* method for defining a NameGroup out of a pile of KEMs.

Re: [TLS] Client programs and stapling?

Prior to TLS 1.3, it wasn't possible because the Certificate message didn't have extensions. Starting TLS 1.3, it looks like we did define status_request to be allowed in either direction. We (BoringSSL) never implemented the client certificate direction, since we haven't needed it yet. We just ign

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

I agree this is quite a compatibility risk. In addition to messing with SNI lookup, there are servers that try to correlate TLS SNI and HTTP Host. Indeed, when we accidentally sent IP literals in SNI, we broke a server that tried to do that but got very confused by the colons in an IPv6 literal. Th

Re: [TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting

Solutions which require software changes to both sides may as well apply that software change to TLS 1.3, or even just TLS 1.2 ECDHE. (RFC 7919 could also have been such an option, but it was defined wrong, per the meeting discussion, it is not. So it goes.) Skimming the TLS-LTS formulation, it se

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

I too am not seeing the use case here. Could you elaborate? Since browsers were mentioned as an example, when Chrome makes several connections in a row (e.g. to measure impacts of a removal more accurately), we generally do *not* expect the server to change its selection algorithm across the two c

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

Depending on what the server does, there may also be downgrade implications, if the server uses some unauthenticated prior state to influence parameter selection. On Fri, Sep 16, 2022 at 11:53 AM David Benjamin wrote: > I too am not seeing the use case here. Could you elaborate? > &

Re: [TLS] RFC 5746 applicable for session resumption?

The exact contents and structure of StatePlaintext and ticket itself are up to the implementation to decide. This format is merely a recommendation or example. The only interop requirements are that the server maintain enough state that it can correctly resume a session on the subsequent request. O

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

Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in TLS 1.3? I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed them from Chrome back in 2016

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

S on behalf of Carrick Bartle < > cbartle...@gmail.com> > *Date: *Thursday, 15 December 2022 at 20:15 > *To: *David Benjamin > *Cc: *TLS List > *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites > > > > Hi David, > > > > My u

[TLS] Merkle Tree Certificates

e're very eager to get feedback on this. David On Fri, Mar 10, 2023 at 4:38 PM wrote: > > A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draf

Re: [TLS] Merkle Tree Certificates

in a TLS handshake we would > have (1 subscriber public key + 2 signatures + some relatively small tree > structure) compared to (1 signature + (3 sigs + 1 public key) for server > cert + (1 Sig + 1 Public key) per ICA cert in the chain). If we borrowed > the same flat PKI logic though

Re: [TLS] Merkle Tree Certificates

change is not trivial in my eyes, but the end > goal is similar, to shrink the amount of auth data. > > > > -Original Message- > From: TLS On Behalf Of Hubert Kario > Sent: Monday, March 13, 2023 11:08 AM > To: David Benjamin > Cc: ; Devon O'Brien > Subje

Re: [TLS] Merkle Tree Certificates

On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote: > On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote: > > I don't think flattening is the right way to look at it. See my > > other reply for a discussion about flattening, and how this does > > a bit more t

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

I support adoption. On Tue, Mar 28, 2023 at 2:20 PM Stephen Farrell wrote: > > > On 28/03/2023 05:57, Salz, Rich 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 room. Please i

Re: [TLS] TLS 1.2 deprecation

post_handshake_auth was only in TLS 1.3 because some folks relied on an existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a renegotiation and request a client certificate in the new handshake. I don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such a bac

Re: [TLS] Servers sending CA names

Chrome also uses this to filter the set of client certificates when asking the user to pick one. We also sometimes use this to figure out what intermediates to send, in cases where the server does not already have all its intermediates available. (Though this is not very reliable and OS-dependent.

Re: [TLS] Merkle Tree Certificates

ll cases, so we're thinking of this as one of several sorts of > PKI > > mechanisms that might be selected via negotiation. > > > > Thoughts? We're very eager to get feedback on this. > > > > David > > > > On Fri, Mar 10, 2023 at 4:38 PM w

Re: [TLS] Merkle Tree Certificates

On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd wrote: > Come embrace the temptations of the Sea-SIDH! > > Intermediate certs are rarely used, so that would achieve 204 byte sig > on intermediate+ 64 byte intermediate key + 204 byte sig of EE cert > since the signing time doesn't matter. Then with S

Re: [TLS] Merkle Tree Certificates

Thanks for such detailed feedback! Responses inline. On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara wrote: > Some quick comments / ideas: > > - I think it would be easier for subscribers to get inclusion proofs > from transparency service than certificate authority. > > This is because iss

Re: [TLS] Merkle Tree Certificates

On Wed, Mar 22, 2023 at 11:22 AM Ilari Liusvaara wrote: > On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote: > > > > > > Unpopular pages are much more likely to deploy a solution that > > > doesn't require a parallel CA infrastructure and a cryptographer > > > on staff. > > I don't t

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

On Mon, Aug 7, 2023 at 9:27 PM Eric Rescorla wrote: > On Mon, Aug 7, 2023 at 2:50 PM Jonathan Lennox > wrote: > >> On Aug 6, 2023, at 5:22 PM, Rob Sayre wrote: >> >> On Sun, Aug 6, 2023 at 2:14 PM Eric Rescorla wrote: >> >>> Sure. Though with that said, DTLS-SRTP should use the same code point

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

I don't think what we do with the registry has any bearing on whether the codepoint is burned. There are already draft ECH deployments today, on both the client and server side, independent of what we later put in the registry. Rather, the ECHConfigList structure is internally versioned, so as long

Re: [TLS] Early IANA Allocations for draft-ietf-tls-esni

effort and more problematic.) > Do we believe the draft is stable enough that we should reference it > informationally for that code point? > > > On Wed, Sep 20, 2023 at 3:01 PM David Benjamin > wrote: > >> I don't think what we do with the registry has any bear

Re: [TLS] SVCB codepoint for ECH

How do we want to handle the rest of draft-sbn-tls-svcb-ech? It got WG adoption in May, but I don't think anything's happened with it since. (Unless we decided something and I forgot?) In particular, the section on switching to SVCB-reliant mode is important for a client: https://www.ietf.org/archi

[TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

emely difficult without introducing downgrades. Thoughts? David -- Forwarded message - From: Date: Mon, Sep 25, 2023 at 6:56 PM Subject: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt To: David Benjamin A new version of Internet-Draft draft-davidben-tls-k

Re: [TLS] TLSFlags ambiguity

Nice catch! I agree those don't match. I think bit zero should be the least-significant bit. That is, we should leave the examples as-is and then fix the specification text. Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no inherent order to bits in memory, so the most nat

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote: > On Tue, Oct 10, 2023 at 8:28 AM David Benjamin > wrote: > >> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote: >> >>> To make sure I've understood correctly,

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

On Tue, Oct 10, 2023 at 1:24 PM Bas Westerbaan wrote: > OK, I see. It's worse than a compatibility risk, though, isn't it? If you >> just let them break in case (a), and then maybe try again with (b), that >> opens up a downgrade attack. Intermediaries can observe the size of the >> Client Hello

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

On Fri, Oct 13, 2023 at 1:29 AM Rob Sayre wrote: > On Wed, Oct 11, 2023 at 8:43 AM David Benjamin > wrote: > >> Tossed onto GitHub and removed the discussion of authenticated records >> in >> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320a

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

Answering a few questions that have come up thus far: > Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? > Or am I missing some other possible downgrade attack? A fallback is certainly one po

Re: [TLS] weird DHE params p length in TLSv1.2

If I recall, TLS 1.2 was ambiguous on this point, so it's unclear what the sender is expected to do. I believe there were some implementations that expected a fixed-width public key (which would have been the better option to pick, but we don't have a time machine), so zero-padding on send is prud

[TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

ct: New Version Notification for draft-davidben-tls-trust-expr-00.txt To: Bob Beck , David Benjamin , Devon O'Brien A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-tru

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

the compression was actually needed, so we omitted it. (These are not sent in TLS connections, just in the root program -> CA -> subscriber flow. We don't want them to be *humongous*, but we don't need to squeeze them that tightly.) But if folks prefer ranges, that's easy enough

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Fri, Oct 20, 2023 at 4:07 PM David Benjamin wrote: > Thanks for the comments! Responses inline. > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara > wrote: > >> Some quick thoughts: >> >> - The multiple certificates from one ACME order really scares me. It

Re: [TLS] Request mTLS Flag

Would you expect a browser user to send this flag? On the browser side, we don't know until the CertificateRequest whether a client certificate is configured. We have to do a moderately expensive query, dependent on information on the CertificateRequest of the OS's cert and key stores to get this i

Re: [TLS] Request mTLS Flag

d user agent (and a bunch of > ML), which isn't always reliable. > > The web crawler case is where the dedicated endpoint falls over, because > crawlers are indexing the human visible web. > > I don't think this leaks more info than a dedicated endpoint (even > accounting

Re: [TLS] New Version Notification for draft-davidben-tls-trust-expr-00.txt

Quick update: we pushed a draft-01. It's basically the same, but we noticed we referred to the wrong name of some structs in places and figured it was worth a draft-01 to be less confusing. :-) On Thu, Oct 19, 2023 at 11:38 AM David Benjamin wrote: > Hi all, > > We just published

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

e very many words to say. :-) But I'm fine with whatever order. The goal was to just pick *some* defined sort order, so that it's easy to find duplicates, and to hint that maybe you should put this into some structure that can binary search easily. Happy to do "a" before &qu

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

On Sat, Oct 21, 2023 at 5:41 AM Ilari Liusvaara wrote: > On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote: > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > - The multiple certificates from on

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Is the concern here errors or prompting? From the original email, it sounded like the issue was that requesting client certificates showed undesirable UI to human-backed clients. That one is a bit harder to avoid since no one is acting incorrectly per se. Clients for humans need to ask the human f

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

On Tue, Oct 24, 2023, 13:07 Viktor Dukhovni wrote: > On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote: > > > Is the concern here errors or prompting? From the original email, it > > sounded like the issue was that requesting client certificates showed > >

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Some changes from the last time this was posted: - Apparently we got early codepoint allocation for this and I forgot about it? Anyway the allocated codepoints are now in the draft. - We've crisped up the motivation a bit. One thing I'll call out is that the previous discussion mentioned one could

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

rfc8446bis is still open for substantive changes (though my impression was it isn't?), I don't mind putting things in there. Though we'd still need to expend a lot of text to define prediction-safe and prediction-unsafe groups, precisely because we do *not* want to define duplicate gr

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk wrote: > On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote: > >Additionally I want to emphasize that, because of the negotiation > order > >between versions and client certificates, there is no way to do an

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

thenticated > signals, such as DNS or falling back on apparent network error > (e.g., due to apparent intolerance of large CH), then the attacker > can exploit the behavior described in (3) to downgrade the selected > groups. > > > Is this a reasonably accurate summary of the si

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

I support adoption and am willing to contribute text, but this is perhaps not surprising. :-) On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey wrote: > At the TLS meeting at IETF 118 there was significant support for the > draft Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 >

Re: [TLS] Request mTLS Flag

On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara wrote: > On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: > > > > - Some Java TLS libraries (used to?) fail the handshake when the > > client has no configured certs, or the list of issuer CA DN hints > > does include

Re: [TLS] Request mTLS Flag

a mess. Client certificates are the bane of my existence. :-) On Tue, Nov 7, 2023 at 10:46 PM David Benjamin wrote: > On Tue, Nov 7, 2023 at 3:43 PM Ilari Liusvaara > wrote: > >> On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote: >> > >> > - Some

Re: [TLS] Design Rational for Key Exporter

An unhelpful answer is that the key exporter interface was already set by prior versions of TLS and any TLS 1.3 key exporter needs to remain analogous. :-) A more helpful answer is that we cannot simultaneously believe that key update is a transparent feature of TLS, and that exporters are sensiti

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Done, although I'm not sure if I got all the metadata right. (How does one mark it as replacing the old one?) https://datatracker.ietf.org/doc/draft-tls-tls13-pkcs1/ The GitHub is still under my account, but happy to move it to the TLSWG if preferred. (How would we go about doing that?) On Wed, N

Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

under this name? It would be better to have in the > tlswg repo, we'll follow up offline. > > Thanks, > > Joe > > On Wed, Nov 29, 2023 at 9:41 AM David Benjamin > wrote: > >> Done, although I'm not sure if I got all the metadata right. (How does &

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

I support adoption and am willing to review. On Wed, Dec 6, 2023 at 12:34 AM Deirdre Connolly wrote: > At the TLS meeting at IETF 118 there was significant support for the draft > 'TLS 1.2 is in Feature Freeze' ( > https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This > call is t

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

I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be around for quite some time, but that *does not mean it is worth adding new features to TLS 1.2*. Those two statements are not directly related. Protocol changes generally require both client and server changes to take effect. P

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

I agree that IANA registrations aren't a great place to constrain this. First, constraining the registry for TLS 1.2 and not DTLS 1.2 makes a lot of things very weird. For a feature that's TLS/DTLS-agnostic, like post-quantum, it helps no one to define it for DTLS 1.2 and not TLS 1.2. Most of the

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

Skimming the draft, I am not following the timing of this process. Suppose the client initiates an extended key update. It cannot update the keys yet, because it does not know the server's response. It needs to keep reading from the server. In doing so, it will hopefully see a responding ExtendedKe

Re: [TLS] TLS Suite Naming Conventions

I think this thread stems from a misunderstanding of what TLS is doing, and what "Ed25519" means. > In the thread, Neil said that it is better to negotiate for key (representations), instead of algorithms, and that TLS has been moving away from fully specifying things. This is the exact opposite

Re: [TLS] TLS Suite Naming Conventions

On Sat, Jan 6, 2024 at 12:23 PM David Benjamin wrote: > I think this thread stems from a misunderstanding of what TLS is doing, > and what "Ed25519" means. > > > In the thread, Neil said that it is better to negotiate for key > (representations), instead of algor

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

The extension list cannot actually be empty because we also say: > The "signature_algorithms" extension > MUST be specified, and other extensions may optionally be included > if defined for this message. That said, enforcing this by rejecting the empty list doesn't do much because the receiver wi

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

On Thu, Jan 18, 2024 at 5:25 PM Rob Sayre wrote: > On Thu, Jan 18, 2024 at 1:26 PM David Benjamin > wrote: > >> >> I think sometimes we spend a little more energy than is actually useful >> in figuring out these implied lower bounds. :-) In practice, the only >>

[TLS] Trust Expressions Follow-up

Hi all, Now that the holidays are over, I wanted to follow up on draft-davidben-tls-trust-expr and continue some of the discussions from Prague: https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-t

Re: [TLS] Trust Expressions Follow-up

On Fri, Jan 26, 2024 at 5:15 AM Ilari Liusvaara wrote: > On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote: > > > > Second, I wanted to take a step back and try to better articulate our > > goals. I think the best way to look at this draft is in three parts: &

Re: [TLS] Trust Expressions Follow-up

here, we'd like to get some experience with things.) On Thu, Jan 25, 2024 at 5:00 PM David Benjamin wrote: > Hi all, > > Now that the holidays are over, I wanted to follow up on > draft-davidben-tls-trust-expr and continue some of the discussions from > Prague: > > &

Re: [TLS] Trust Expressions Follow-up

obably adapt some of that text back into the draft, after some more wordsmithing.) On Thu, Feb 29, 2024 at 7:18 PM David Benjamin wrote: > Circling back to this thread, we're now looking at prototyping the TLS > parts in BoringSSL, on both the client (Chrome) and the server side. Let

Re: [TLS] Trust Expressions Follow-up

te > ellison here: > https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-intermediate-elision > > The idea was that if you had stable receipts from a transparency service > you trusted, you might not need to care about all the parts of a cert cha

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

This is good work, but we need to be wary of getting too excited about TTLB, and then declaring performance solved. Ultimately, TTLB simply dampens the impact of postquantum by mixing in the (handshake-independent) time to do the bulk transfer. The question is whether that reflects our goals. Ulti

[TLS] Next steps for key share prediction

Hi all, With the excitement about, sometime in the far future, possibly transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I thought it would be a good time to remind folks that, right now, *we have no way to effectively transition between PQ-sized KEMs at all*. At IETF 118

Re: [TLS] Next steps for key share prediction

On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd wrote: > On Thu, Mar 7, 2024 at 2:56 PM David Benjamin > wrote: > > > > Hi all, > > > > With the excitement about, sometime in the far future, possibly > transitioning from a hybrid, or to a to-be-developed better PQ a

Re: [TLS] TLSFlags ambiguity

that this document does not define any particular bits for this string. That is left to the protocol documents such as the ones in the examples from the previous section. Such documents will have to define which bit to set to show support. David On Wed, Sep 27, 2023, 17:50 David Benjamin wrote: &

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > >> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> > FWIW: In my experience middleboxes don't ossify based on what the spec >> says, >> > they ossify based on what they see on the w

Re: [TLS] close_notify and TLS 1.3

I think this change is a good idea. Our implementation actually does this already anyway. We are happy to continue servicing writes even when the read half has consumed a close_notify. I believe we inherited this behavior from OpenSSL, so it should be there too. Go's crypto/tls implementation appe

Re: [TLS] close_notify and TLS 1.3

On Mon, Nov 13, 2017 at 8:25 PM Eric Rescorla wrote: > On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario wrote: > >> On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote: >> > Hello all, >> > >> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 >> did. >> > I believ

Re: [TLS] PR#1091: Changes to provide middlebox robustness

As a source of some of those numbers, someone interested in actually deploying TLS 1.3, and, most importantly, someone who would have to deal with the fallout of that deployment, I can unequivocally say those are not "very good" figures. They are completely implausible by orders of magnitude. TLS 1

Re: [TLS] TLS 1.3 draft 22 middlebox interaction

On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla wrote: > On Fri, Dec 1, 2017 at 6:47 AM, R du Toit wrote: > >> I want to provide some feedback that might be useful to the TLS WG: >> Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org >> is triggering an interesting failure in a

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

On Wed, Dec 13, 2017 at 5:39 PM Hanno Böck wrote: > Hi, > > The deployment of TLS 1.3 was delayed because Internet middleboxes > broke when they saw unknown TLS data. > > I guess it's plausible to assume that the same problem will show up > with compressed certificates. Has any thought been given

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

On Thu, Dec 14, 2017 at 4:47 PM Ilari Liusvaara wrote: > On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote: > > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev > wrote: > > > https://github.com/tlswg/certificate-compression/pull/8 > > > > That's a lot cleaner. Thanks. Some minor

[TLS] Additional TLS 1.3 results from Chrome

Dear all, The recent release of Google Chrome 63 enabled (effectively) TLS 1.3 draft 22 for 95% of stable channel users who updated. (Our previous results were on our beta channel.) While, in the past, we have demurred[1] from providing details about problematic products we now plan to alter that

Re: [TLS] ClientHello record header version

What implementation are you working on? Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes". And, of course, any pre-1.3 middleboxes which hit this case are non-compliant. That would imply they assume they can parse messages following a ClientHello t

Re: [TLS] Network middlebox corrupting TLS session resumes

I don't think we've observed this particular issue. We have observed middleboxes which, when they see a ServerHello they can't parse (such as the pre-draft-22 TLS 1.3 ServerHello), drop the ServerHello record on the floor, but pass through any following application_data records as-is. That's simila

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

FWIW, this was BoringSSL's interpretation as well. We don't consider supported_versions an acceptable TLS 1.2 (or earlier) ServerHello extension. I generally agree that we shouldn't add new unnecessary combinations. (TBH, I don't even consider the ability to advertise TLS 1.3 and TLS 1.1 on the cl

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

The data ultimately needs to be returned to the calling application, presumably some HTTP parser, which in turn passes data up to more calling code and so on. Conversely, the data must have been produced by some also application-level process on the sender, some HTTP serializer, before it was hande

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

+1. If anything, the existing "buggy implementation" alert codes should get folded together. (But I don't think it's worth making that change at this stage either.) E.g. decode_error vs illegal_parameter vs unexpected_message are rather useless distinctions and trying to get them "right" adds compl

Re: [TLS] potential attack on TLS cert compression

To make sure I understand the issue, the concern is that your decompression function provides a chunk-by-chunk interface, there's a bug and the division into chunks produces a different result? Or are you suggesting that, with the same chunking pattern, the result is still non-deterministic somehow

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

On Mon, Mar 26, 2018 at 1:25 PM Salz, Rich wrote: > Is it now impossible adding new things to TLS 1.2? I don't believe the WG > understood that this would be the situation. So I disagree with your claim > that this was our understanding of the situation. > > Okay, it turns out that David's neat

Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression

+1 On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla wrote: > +1 > > On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote: > >> All, >> >> tl;dr: If you object to the following early code point assignments 1) add >> the compress_certificate in the TLS ExtensionType Registry and 2) >> compressed_cert

Re: [TLS] TLS 1.3 Specification

BoringSSL and OpenSSL have are draft versions which use different version numbers from the final RFC, so as not to collide. Early experimental deployment is generally useful to help inform the final standard and flush out any non-compliant TLS 1.2 implementations that may cause deployment difficult

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

I'm not sure I follow this. So, in this scenario, you are the client. You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and this is fine. You are able to verify RSA-PSS signatures from the server at TLS 1.3. At the same time, you still talk to some TLS 1.2 servers, so you

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov wrote: > On 05/29/2018 01:07 PM, David Benjamin wrote: > > I'm not sure I follow this. So, in this scenario, you are the client. > > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS > > 1.3, and thi

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

I probed a bunch of servers yesterday and found evidence of yet another collision at 26! It's possible these are TLS-LTS implementations, but a lot of them additionally only support RSA decryption ciphers, which makes this seem unlikely. These servers do not appear to do anything with the extension

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

ly TLS connections, though of course it must have a > unique code point from other extensions used with QUIC. So it's not > entirely clear how best to handle this, > > -Ekr > > > On Thu, May 31, 2018 at 7:42 AM, David Benjamin > wrote: > >> I probed

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

nternet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Applying GREASE to TLS Extensibility > Author : David Benjamin > Filename

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

On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk wrote: > On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: > > Hi all, > > > > Apologies for the probably record time delay in actually updating this > > thing. I like the graph... apparently -00 was expired f

Re: [TLS] draft-ietf-tls-grease and RFC 7919

This value would be kind of weird because this part of RFC 7919 is quite complex. But if there's interest, I don't mind adding some. But I think the TLS 1.2 bits of RFC 7919, particularly the rule you refer to, were a mistake and are best ignored. The benefits of that document are unrealizable to

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

.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.3>. I did not propose any new ideas in this document update, as this was just about updating it to match the prior discussion of rebasing atop TLS 1.3. David On Thu, 07 Jun 2018 17:05:47 -0400 *David Benjamin > >* wrot

Re: [TLS] TLS 1.2 and sha256

In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a function of the cipher suite you negotiate (and also, separately, the signature algorithm you negotiate). That said, in practice, both are pretty solidly dependent on SHA-256. Most options involve it. AES-128-GCM and ChaCha20-Poly1

[TLS] Enforcing Protocol Invariants

Hi all, Now that TLS 1.3 is about done, perhaps it is time to reflect on the ossification problems. TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet we had problems. Widespread non-compliant servers

<    1   2   3   4   5   6   >