Sent from the right email this time. (Sorry folks who got it twice. One of
these days I'll not mess this up! :-) )
On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote:
> On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov
> wrote:
>
>> Thanks for the detailed comments, Ilari
On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara
wrote:
> > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin
> wrote:
> >
> > > Are you intending that this mechanism be enabled by default for HTTP/2
> or
> > > would the prohibition against renego still apply? Wi
On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich wrote:
> > Personally, I would rather see the nonce construction follow the form
> > defined in the respective TLS version. [DB: Adding back in for context:
> "That means including redundant bytes in TLS 1.2 and only getting the full
> advantage when we
On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov
wrote:
> > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS
> 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.
> Correct, anything less than this will create deployment problems.
>
But this proposal is only su
(Resending from the right address, again. Possibly I should have subscribed
with the other one...)
On Thu, Sep 17, 2015 at 6:23 PM David Benjamin wrote:
> On Thu, Sep 17, 2015 at 5:46 PM Brian Smith wrote:
>
>> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
>> wrote:
>
On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote:
> On 14/10/15 16:44, Martin Rex wrote:
> > Matt Caswell wrote:
> >>
> >> Does anyone have any views on the below?
> >
> > Yup. Interleaving application & handshake records is a
> > highly dangerous idea (and fortunately some TLS implementations
On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson
wrote:
> On 14 October 2015 at 13:29, David Benjamin wrote:
> > If you really absolutely must support interleave and can't avoid it, I
> think
> > it being allowed everywhere except between CCS and Finished is probably
> t
On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote:
> On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
>
>> Does the sentinel have to be the first N bytes?
>>
>> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
>> value and 28 random bytes.
>>
>> Rather than risk break
What purpose does putting the version in the AD serve? It's not harmful,
sure, but just using the sequence number is simplest. It seems the only
reason we'd consider putting it into the AD is because historically the
record version was in there as part of the record header. In a vacuum, I'm
having
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote:
>
> > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote:
> >
> > The TLS 1.3 post-handshake client-auth was intended, as I recall, to
> > support HTTP/1.1 over TLS 1.3.
>
> No, it was (and is) presented as a way to do client certificate
> authenticat
sible for the "something cleaner" and "ugly compat solution" to be the
same, that is certainly preferable, no? It's possible my guesses about your
constraints are incorrect, but so far I'm not seeing any reason that
wouldn't be possible. What am I missing here?
Davi
On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote:
> On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
> > * Fully deprecate RSA key exchange.
> > The compatibility costs of this one are high. They are even higher
> > considering the fact that chrome wants to deprecate dhe and use rsa as
> >
BoringSSL has an implementation of the AEAD itself you could test against.
It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed
to EVP_aead_chacha20_poly1305 later).
On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote:
> OpenSSL just landed our chacha/poly implementation into ma
In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
it's likely that enterprise deployments are much worse.
I started gathering numbers on ServerKeyExchange hashes back in November.
The code isn't on Chro
On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote:
> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)
>
0xca,0xfe has since been removed as nothing was using it. I'm not aware of
anything th
Chrome is also expecting to ship the cipher in Chrome 49. It's available in
Canary and Dev channel right now. It should interop with OpenSSL's master
branch as of when I last tested this.
David
On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote:
> We (OpenSSL) have already tested interop of chac
Hi folks,
This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
1.2, signature algorithms are spread across the handshake. We have
SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
independent registries. NamedGroup is sent in one list, also used for
(E
On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored i
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett wrote:
> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> > 1.2, signature algorithms are spread across the handshake.
> [...]
> &g
On Fri, Jan 15, 2016 at 8:10 PM David Benjamin
wrote:
> If changing the existing meaning is a nuisance, another option is to
> continue to allocate new values but only define ecdsa_p256_sha256,
> ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
> is) for
On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario wrote:
> On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > Hi folks,
> >
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
> > TLS 1.2, signature algorithms are spread across
BoringSSL has a pair of implementations ready (in C and in our fork of Go's
TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29.
It's not currently enabled in any Chrome builds, but I'm expecting to
change this soon.
David
On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey wro
ies not only what
> curves can be used for signing but also what curves can get signed.
>
> Or are you saying that the NamedGroup would stay, and would now specify
> only the supported parameters for the key exchange, not how they are
> authenticated (as it is now)?
>
Yes.
>
On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote:
> David Benjamin wrote:
>
>> (Whether such certificates exist on the web is probably answerable via CT
>> logs, but I haven't checked.)
>>
>
> Me neither, and I think that's the key thing that would need
Sorry, sent from the wrong address.
On Tue, Jan 19, 2016 at 5:19 PM David Benjamin wrote:
> On Sat, Jan 16, 2016 at 5:00 AM Hanno Böck wrote:
>
>> Hi,
>>
>> I generally like the idea of simplifying the different algorithm
>> negotiation things, but:
>>
&
Jan 15, 2016 at 3:45 PM David Benjamin
wrote:
> Hi folks,
>
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
> 1.2, signature algorithms are spread across the handshake. We have
> SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and HashAlgorithm, all in
&
signature algorithms. The other benefits from
incorporating curve preferences into the negotiation also still apply.
David
On Fri, Jan 22, 2016 at 5:25 PM David Benjamin
wrote:
> I've put together a pull request with some initial text for this proposal
> if folks decide to adopt it.
It's possible I'm reading the draft wrong, so this thread may be a very
short one.
(t here is in units of RTT, so t=0 is when the client sends ClientHello and
t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is
when the client receives ServerHello, etc.)
Looking at the Zer
by
the client at t=2. The same data arrives at the same times and we don't
increase the state-space.
David
[*] Mid-stream auth is a serious regression, and I am not endorsing it in
any way. But supposing it exists for the purposes of this thread...
> On 27 January 2016 at 11:46, Da
Instead of putting 0-RTT data in a ClientHello extension, the current draft
has the client send extra records in the first flight, right? (I see an
early_data extension, but it seems only be an indicator. There's also
mention of requiring trial decryption which only makes sense if it were
appended.
On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson
wrote:
> On 27 January 2016 at 12:58, David Benjamin wrote:
> > If the server needs to send a CertificateRequest (i.e. the client
> > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> > 0-RTT hit,
On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla wrote:
> On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin
> wrote:
>
>> Instead of putting 0-RTT data in a ClientHello extension, the current
>> draft has the client send extra records in the first flight, right? (I see
>&
On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson
wrote:
> 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
> &
On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara
wrote:
> On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote:
> > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> > >
> > > I get your point, but I
On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara
wrote:
> On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote:
> > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Jan 27, 2016 at
On Mon, Jan 11, 2016 at 6:17 PM David Benjamin
wrote:
> In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing
> around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and
> it's likely that enterprise deployments are much worse.
>
>
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote:
> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
> wrote:
>
>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
>> wrote:
>>
>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
&
Hi Martin,
You’re right that this is closely related to half-RTT data. However, I
don’t think this is a no-op for HTTP/2.
I’m not aware of HTTP/2 clients that wait for the SETTINGS frame today.
Doing so costs a round-trip with servers that don’t send SETTINGS in
half-RTT, and there's no indicator
Hi Ben,
(I’ve covered many of these points in my reply to Martin, so you may want
to read that first.)
Any solution here involves a TLS change, even for servers which currently
send half-RTT settings. See my reply to Martin for why. The question then
is which is more complex. As a TLS implementor
On Tue, Jul 7, 2020 at 4:38 PM Ben Schwartz wrote:
>
> On Tue, Jul 7, 2020 at 3:14 PM David Benjamin
> wrote:
>
>> Any solution here involves a TLS change, even for servers which currently
>> send half-RTT settings. ...
>>
>
> I think a new ALPN protocol
On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev wrote:
> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue
> wrote:
>
>> Hi Victor,
>>
>> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in
>> your original email. I was reading it in the context of David Benjamin's
>> thread on C
On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue
wrote:
> On Mon, 20 Jul 2020, 21:38 David Benjamin, wrote:
>
>> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev > 40google@dmarc.ietf.org> wrote:
>>
>>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue
>>&g
On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue
wrote:
>
> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin
> wrote:
>
>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue
>> wrote:
>>
>>>
>>> That makes sense but I guess I don't see the point in d
there's any
> significant overlap between those.
>
> On Tue, Jul 21, 2020 at 11:49 AM David Benjamin
> wrote:
>
>> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue
>> wrote:
>>
>>>
>>> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin
>>> wrote:
Hi all,
In discussing ECH (draft-ietf-tls-esni) with some QUIC folks, we identified
some places where the extension would not easily apply to QUIC unmodified.
One of them is ECH’s integration of handshake information (anonymity set of
certificates, etc.) with TLS record-level padding. Since QUIC b
Thanks for writing this up! We've been pondering this subject as well, as
part of identifying places where ECH and QUIC interact interestingly. (The
other being the padding issue in
https://github.com/tlswg/draft-ietf-tls-esni/issues/264.)
As with the padding issue, QUIC replaces the record layer,
"Variable-length" and "secret" don't really go together in the same
sentence, as your work demonstrates. I would actually go further and strike
that text altogether. I don't think it needs to be an open question. That
lets us stick with a simple construction.
While the public values aren't secret
On Wed, Sep 16, 2020 at 12:47 PM David Benjamin
wrote:
> "Variable-length" and "secret" don't really go together in the same
> sentence, as your work demonstrates. I would actually go further and strike
> that text altogether. I don't think it needs to be
On Fri, Sep 18, 2020 at 10:28 AM Sean Turner wrote:
> Also, should we be adding “_legacy” to the names of the code points as was
> done for rsa_pkcs1_sha256_legacy by:
> https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt?
>
My inclination is no. We didn't go about renaming the hug
There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N
Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke
is that the IANA registry only says “not recommended” but it
> does not say for what environments these ciphersuites are not recommended.
> Worse, it also wants to indicate whether the specification has gone through
> the IETF process.
>
>
>
> Ciao
>
> Hannes
>
>
>
&g
Hi all,
Victor and I recently published draft-vvv-tls-alps-01. It has a couple of
changes that I wanted to get the WG’s thoughts on. The changes are
switching the bespoke ClientApplicationSettings message to a client
EncryptedExtensions message and clarifying the 0-RTT handling.
https://tools.iet
I support adopting this draft.
On Tue, Nov 10, 2020 at 5:38 PM Ryan Sleevi wrote:
> On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev 40google@dmarc.ietf.org> wrote:
>
>> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson wrote:
>>
>>> I've no objection to adopting this, though I will note that
On Thu, Dec 3, 2020 at 1:16 PM Eric Rescorla wrote:
>If a client certificate has been associated with the session, the
>client MUST use the same policy on whether to present said
>certificate to the server as if it were a new TLS session. For
>instance, if the client would show a
I think, like the tracking issue, it should go in both. (I wrote
https://github.com/tlswg/tls13-spec/pull/1205 to try to capture the
tracking case.) This draft should definitely (re)-state it because TLS
preferences are most common keyed by domain name. So even if it's in TLS
itself, it's worth emp
David
-- Forwarded message -
From:
Date: Thu, Dec 3, 2020 at 4:22 PM
Subject: New Version Notification for
draft-davidben-tls-alps-half-rtt-00.txt
To: David Benjamin
A new version of I-D, draft-davidben-tls-alps-half-rtt-00.txt
has been successfully submitted by David Benjami
On Sat, Dec 5, 2020 at 6:31 PM Eric Rescorla wrote:
>
>
> On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir wrote:
>
>> Hi.
>>
>> At IETF 108 a question was raised about The TLS Flags extension. What
>> payloads on the server side can include this extension?
>>
>> The “candidates” are ServerHello, Encry
Agreed with reserving the code points. Even ignoring the remnants of draft
1.3, we probably should have reserved 40 when we changed it, given the
compatibility issues we found.
I don't remember enough of how 46 in draft 1.3 was used to reason about the
compatibility implications, but code points a
Hi all,
Thanks all for the feedback. I’ve tried to address it below, but there's a
lot of text, so please let me know if I’ve missed or misunderstood any of
your points.
Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in
draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a dr
On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield wrote:
> On Fri, 29 Jan 2021 at 23:38, David Benjamin
> wrote:
> > To clarify, are you unconvinced that ALPS is easier than leaving H2
> alone, or that ALPS is easier than solving this problem with half-RTT? The
> document’s aim i
Moving to a three-byte length wouldn't do anything: extension bodies
themselves have two-byte lengths, so any longer lengths within an extension
is just a waste.
(To that end, because every field in a ClientHello has a two-byte length,
the longest possible syntactically valid ClientHello at all is
On Sun, Feb 28, 2021 at 12:35 PM Stephen Farrell
wrote:
> - This is *much* harder to implement compared to ESNI as
>it interacts with the rest of the TLS stack/library in
>many more ways. It should be an explicit goal to reduce
>that complexity IMO and not increase it further. That
>
I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
- The construction is broken. The leak itself in the Raccoon attack comes
from TLS 1.2 removing leading zeros. We can't change the meaning of the
existing code points, so any fix there would involve dropping them.
- It lacks gr
d supporting them"
On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle wrote:
> I'm not opposed to expanding the scope of this document to include
> deprecating DHE. Is there a major advantage to that being its own draft?
>
>
> > On Mar 8, 2021, at 10:09 AM, Martin Thomson wr
Chrome dropped TLS 1.2 DHE nearly five years ago now. I don't have data on
the current DHE-to-RSA conversion, but I can tell you what it was then.
When we put it under a fallback for measurement, only 2% of connections
negotiated DHE. Of that 2%, 95% used 1024-bit DHE. That means we really
only had
Oh, that is a good observation.
If the client has the same ServerHello-sensitive preferences (version, key
share, supported groups, cipher suites, PSKs) between inner and outer
ClientHello, it doesn't need to reprocess. But if it has different
preferences, it needs to resolve this circular depende
On Thu, Mar 18, 2021 at 2:56 PM Christian Huitema
wrote:
>
> On 3/18/2021 10:24 AM, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 18/03/2021 16:55, Christian Huitema wrote:
> >> On 3/18/2021 7:35 AM, Christopher Patton wrote:
> >>
> I forget, did we need to bind it to the actual handshake
On Thu, Mar 18, 2021 at 4:07 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 18/03/2021 19:17, David Benjamin wrote:
> > I don't think I'd agree that *most* of the work is in the secret
> > computation per se. Actually doing trial decryption with
> > th
tweak wouldn't remove the need for HRR completely -- it could be
>> >> necessary when changing server configuration, for example -- but it
>> could
>> >> remove the need for HRR in the common case.
>> >>
>> >> Nick
>> >>
>> &
Hi Martin,
Thanks for the comments. As the author of #374, I obviously didn't think it
so clearly unnecessary, but glad to hear your thoughts. Hopefully we can
get on the same page as to what the issues are and/or a better solution.
(Always happy to replace something with a simpler option, provide
Mechanically on the TLS side, we already aligned the client and server
certificate flows in TLS 1.3. TLS 1.3 already
allows signed_certificate_timestamp in the CertificateRequest message. So
basically what you said in Approach 1, except there's no need for the
server to condition the CertificateReq
I don't know of any list, but everything that deals with secrets has some
constant-time portion. This applies to both long-lived and ephemeral
secrets, and includes clients and servers. How practical an attack is
depends on many factors, including the application itself, but I think we
have ample e
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex definitions for allowed strings result in
ambiguities around who is responsible for validating what and subtle
variati
I think there might be some confusion here. It probably doesn't help that
(1) and [1] are different things. :-)
(1) is a standalone change, unrelated to QUIC, [1], (2), or (3). It's about
changing how we pad the *ClientHelloInner*, which is carried in the ECH
encrypted payload. We currently use th
On Tue, Jun 22, 2021 at 6:12 PM Stephen Farrell
wrote:
> On 22/06/2021 22:57, Christopher Patton wrote:
> > Just to be clear, (1), (2) and (3) are not alternatives to the same
> > problem. (1) solves client-side padding, whereas (2) and (3) are
> > alternatives for solving server-side padding.
>
No, resumption should happen after version negotiation, and be declined if
inconsistent. The way it works is:
1. Suppose the client previously connected to the server and received a TLS
1.2 session. It connects again. The client supports TLS 1.2 and 1.3, but
doesn't know a priori whether the serve
In addition to needing to send ECH in case the server declines resumption,
we need to keep the ticket under encryption anyway. Without changing how
resumption works, there are a couple of attacks on cleartext tickets:
1. If the tickets from two backend servers are distinguishable from each
other,
s needed...
>
> On 25/06/2021 17:01, David Benjamin wrote:
> > 1. Either this layer knows how to set up TLS, but doesn't know how to
> > establish connections. Low-level TLS APIs look like this. This layer must
> > take both the transport connection and ECHConfigList
The SignatureScheme change was perhaps overly clever, but the intent is
that you can process them the same at both versions and backport
the single-enum interpretation. (That's what we do.) The key observation is
that TLS 1.3's allocations will never overlap with a defined TLS 1.2 hash
or signature
I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with RFC
On Mon, Jul 19, 2021 at 12:27 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:17, David Benjamin wrote:
> > I'll add that, in the context of cross-domain tracking on the web, this
> > draft is a red herring. Remember that web pages have subresources.
On Mon, Jul 19, 2021 at 12:38 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:35, David Benjamin wrote:
> > We need to*both* not add new tracking vectors*and* mitigate the
> existing
> > ones. Doing either one on its own is not useful. That means if the
&g
On Mon, Jul 19, 2021 at 4:20 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 17:50, David Benjamin wrote:
> > Do you have other text in mind? There doesn't seem to be any other
> possible
> > answer here, since there is only one decision to make in resum
On Mon, Jul 19, 2021 at 5:32 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 19/07/2021 22:13, David Benjamin wrote:
> > I don't think that's an accurate characterization of what's going on. I
> at
> > least care about both optimization and privacy.
>
>
I'm having a bit of a hard time following email quotes containing diffs of
diffs, so I may be misinterpreting who is arguing for what, but I think I
agree with Daniel? I'm not sure. :-) I think:
- We can't usefully change the interpretation of ClientHellos without the
sigalgs extension. In particu
On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle wrote:
> > Notably, it still relies on the server certificate being re-validated
> against the new SNI at the
> > session resumption time.
>
> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed
> it.)
>
Does RFC 8446 actually
amounts of information from the certificate. The exact
details here I don't think TLS should specify, only the conditions on when
using a session is okay.
David
> On Aug 11, 2021, at 2:13 PM, David Benjamin wrote:
>
> On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle 40icloud@d
I support adoption, and will second everything Filippo says.
Deprecation is about the working group issuing updated guidance. Existing
ecosystems may apply new guidance at different rates. That's up to TLS
implementations and deployments to work through. Some ecosystems may remove
things at long t
It's because of the rules in RFC8446. If the server doesn't utter an
extension in HelloRetryRequest, the client is not allowed to change the
corresponding ClientHello extension. We found an implementation which
actually enforces this.
https://github.com/tlswg/draft-ietf-tls-esni/issues/358
David
I agree with Martin.
At the end of the day, a collision between IANA and a large-scale
experiment isn't significantly more interesting than a collision between
two large-scale experiments. They will still cause interop problems. There
isn't really any collision benefit to blocking off a range. If
That's right. The AAD and actual CH should be exactly the same, apart from
the payload being zeroed in place. You don't need to reserialize the
structure as a server, or serialize ClientHelloOuter twice as a client.
On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell
wrote:
>
> (Apologies for the acr
Regarding the TLS 1.3 proof, I recall some discussion around
collision-resistance and PSK binders, with the result that we assume the
KDF is collision-resistant.
The paragraph that begins "The PSK binder value forms a binding" in
Appendix E.1:
https://datatracker.ietf.org/doc/html/rfc8446#appendix
On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario wrote:
> On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org wrote:
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> >
On Thu, Sep 9, 2021 at 2:12 PM Sean Turner wrote:
>
> > On Sep 4, 2021, at 17:45, David Benjamin wrote:
> >
> > On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario wrote:
> > On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org
> wrote:
> > > A N
Hi all,
In diagnosing an interop issue, I noticed RFC 7627 did not describe the
correct server behavior for EMS very well. Seemingly as a result, some
server implementation has gotten this wrong. I'd like to fix this in the
spec so this doesn't happen again. I think, at minimum, we need to replace
ble,
deployments may deploy a new session cache or ticket encryption key
alongside the new version.
"""
Unfortunately, "session using extended master secret" is a bit of a
mouthful, but section 5.4 didn't define a more concise term.
On Mon, Oct 25, 2021 at 4:01 PM Davi
.
>
> > Why SHOULD the server not (also) just fall-back to use a full handshake?
>
> For more details see:
>
> https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/
>
> best regards
> Achim Kraus
>
> Am 26.10.21 um 00:51 schrieb David Benjamin:
&
and the other handshake messages of a full handshake.
> In the end, that prevents, that a client to have to execute a second,
> then full handshake, as fallback.
>
> best regards
> Achim
>
>
> Am 26.10.21 um 17:50 schrieb David Benjamin:
> > At least for an erratum, I
While it's true there is still plenty of 1.2 in many environments, defining
a new extension like flags or connection ID won't make it apply to those
connections. Both sides need to deploy new code to implement that
extension. That means we shouldn't be looking at the trailing end of each
environmen
That's my inclination as well. It's an odd thing for a server to do, but it
seems fine to just retry with the new config without much fuss?
On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell
wrote:
>
> Hiya,
>
> Bit of a corner case I'm not sure about. Apologies
> if this has come up before.
>
> Th
1 - 100 of 550 matches
Mail list logo
