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
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
I
> > 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 wrote:
> >
> >>
> >> A new version of I-D, draft-davidben
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.
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
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
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 than t
imilar, 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
> Subject: RE: [EXTERNAL][TLS] Merkle Tree Certificates
>
> CAUTIO
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 and started “trusting” on a per issuer CA
> basis then the comparison becomes (1 public key + 2 signatures + some small
> tree structure) vs (1 public key + 4 sigs)
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: draft-davidben-tls-merkle-tree-certs
> Revision: 00
> Tit
artle <
> 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 understanding is that we'r
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
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.
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?
>
&
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
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
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.
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
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
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
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
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
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
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
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.
>
>
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
he 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 d
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:
> > Here's some possible replacement
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
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:
> > >
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.
>
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:
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
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
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 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
tificate. 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@dmarc.ietf.org> wrote:
>
>> &
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
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
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.
>
> Sure. We just
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 resumption
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 th
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
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
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
.
>
> 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 as an exte
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,
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
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.
>
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
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
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
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
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,
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
> > the
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
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
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
r 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 wrote:
> >
> > One thing at a
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
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
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
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
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
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
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,
-- 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 Benjamin
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
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
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
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.
NA 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
>
>
>
> *From:* Dav
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
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
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 an open q
"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
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
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
'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:
>>&
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
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 Pard
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
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 proto
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
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
On Fri, May 29, 2020 at 7:28 PM Nico Williams wrote:
> On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote:
> > In my experience the issues are thorniest when dealing with blocking
> > sockets. Libraries using nonblocking sockets have to signal to the
> > application that they want IO to
On Fri, May 29, 2020 at 8:06 PM Jeremy Harris wrote:
> On 29/05/2020 22:52, David Benjamin wrote:
> > On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote:
> >
> >> On 29/05/2020 21:59, David Benjamin wrote:
> >>> Moreover, in a client-speaks-first
On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote:
> On 29/05/2020 21:59, David Benjamin wrote:
> > Moreover, in a client-speaks-first protocol, the error now comes after
> the
> > client has already sent its request. This is not only a behavior change
> but
> > m
Hi all,
As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some
interesting interactions with TCP. We thought we’d document these and send
a note here. In general, we've found that TLS implementations need to be
wary of post-handshake messages and “unexpected” transport writes. This
On Wed, Mar 4, 2020 at 11:07 AM Sean Turner wrote:
> one more time ...
>
> All,
>
> The purpose of this message is to help the chairs judge consensus on the
> way forward for draft-ietf-tls-ticketrequests. The issue at hand is whether
> the client-initiated ticket request mechanism [0] should be
On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:
> On Fri, 28 Feb 2020 at 04:49, Christopher Wood
> wrote:
>
>> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
>> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
on at the last IETF, and concluding that it didn't,
> although I'd have to double check that.
>
Of course. Yeah, I think the more pertinent question is whether "imp r
binder" is actually a thing.
> Regards,
>
> Jonathan
>
> On Mon, 24 Feb 2020, 22:23 David Benjamin,
On Mon, Feb 24, 2020 at 4:33 PM Jonathan Hoyland
wrote:
> Just looking at this again, it might be better to make a slightly
> different tweak to the key schedule.
> Instead of:
>
> 0
> |
> v
> PSK -> HKDF-Extract = Early Secret
>
On Wed, Feb 12, 2020 at 11:10 AM Peter Gutmann
wrote:
> M K Saravanan writes:
>
> >Is this allowed? i.e. stripping the leading zero of the RSA signature and
> >marking the length as 255? It is not clear to me from the RFC5246
> whether
> >it is allowed or not.
>
> It's not allowed according
The signature is invalid. The client is correct to reject it, and the
server is incorrect to produce it.
RFC5246 cites PKCS1 (then RFC3447, now RFC8017). Both versions spell out
the signing and verifying operations explicitly. The signing operation must
produce a fixed-width output and the
On Mon, Jan 13, 2020 at 6:58 PM Jeremy Harris wrote:
> On 13/01/2020 17:48, internet-dra...@ietf.org wrote:
> > Title : Batch Signing for TLS
> > Author : David Benjamin
> > Filename: draft-ietf-tls-batch-signing-0
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario wrote:
> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote:
> > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> >> On Wed, Dec 11, 2019
On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara
wrote:
> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote:
> > On Saturday, 7 December 2019 11:20:17 CET, Ilari Liusvaara wrote:
> > >
> > > One test I just tried:
> > >
> > > - Smartcard capable of raw RSA.
> > > - OpenSC PKCS#11
On Thu, Dec 5, 2019 at 12:36 PM Benjamin Kaduk wrote:
> On Thu, Dec 05, 2019 at 05:30:10PM +, Daniel Van Geest wrote:
> > Hi all,
> >
> > I think there might be ambiguity or an interoperability issue with the
> TLS 1.3 ServerHello Random value downgrade protection and some (possibly?)
>
On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara
wrote:
> On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote:
> > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
> > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote:
> > >
> > > &g
101 - 200 of 444 matches
Mail list logo
