As currently written, this draft has multiple problems.
Section 4 decides not to repeat the Protocol Invariants described in
section 9.3 of RFC 8446. However, further sections are written assuming
that a proxy acts in a way contrary to those Protocol Invariants. One such
example is section 4.2 in
I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
The grease_extension parameter shouldn't exist, and there should be no
special handling for GREASE values. GREASE doesn't need to be mentioned in
this draft, except to say that a client may send values (cipher suites,
extens
On Thu, Oct 1, 2020 at 7:05 AM Michael D'Errico wrote:
> > I am having a difficult time understanding the tradeoffs you're facing.
>
> This is the first time I'm reading the TLS 1.3 RFC. I have
> implemented SSLv3, TLS 1.0, 1.1, and 1.2. You may have
> used my test server at https www dot mikes
On Tue, Oct 6, 2020 at 11:37 AM Michael D'Errico
wrote:
> I think we are in agreement.
>
> On 10/6/20 13:12, Christian Huitema wrote:
> > * Receiver side: receive the message, parser with generic ASN.1 decoder,
> > process the message using the "parsed" representation, re-encode with
> > DER, che
I have no strong opinion on how this is formatted. I'd base my decision on
what the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's
keep it as is, otherwise let's change it to the QUIC format (or some other
change to increase the max value). I do like that the existing scheme,
co
On Thu, Jan 21, 2021 at 9:46 PM Martin Thomson wrote:
> In other words, each flag is treated just like an empty extension: you can
> initiate an exchange with it, but you can only answer with it if it was
> initiated with it.
>
> I agree that this is the correct guiding principle for handling fla
On Thu, May 20, 2021 at 11:19 AM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:
>
> > > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > > values in the IANA registry (that might then also appear in DNS
> > > zone files, configuration
On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni
wrote:
> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
>
> But, it makes for a fairly terrible user interface for the human
> operator. Compare:
>
> * managesieve
> * 6d616e61
Regarding
> so where 1.2 uses { hash, sig } 1.3 uses values equivalent to { sig, hash
}.
While some TLS 1.3 SignatureScheme enum values might appear to have the sig
in the upper octet and hash in the lower octet, that is not the case and
SignatureSchemes for TLS 1.3 only exist as combinations with
Yes, backward compatibility is optional.
On Thu, Aug 5, 2021 at 1:44 PM Toerless Eckert wrote:
> I am trying to figure out if every implementation compliant with
> RFC8446 is also necessarily interoperable with an RFC5246 peer, or if this
> is just a likely common, but still completely optional
That is not the expected behavior. Likely what is happening is the server
(at the http layer) sees the Connection: close header, and goes to close
the socket for the underlying transport (in this case, the tls stack). The
server’s tls stack, when getting that signal, closes the tls connection,
and
On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing
wrote:
> The draft does consider this by allowing ECH to be disabled - as discussed
> in this thread. Albeit at the cost of an extra round trip. However, the
> connection retry logic in the presence of ECH disabling is currently
> optional.
>
> The dr
ertificate valid for the public name,
> the client can safely retry with updated settings, as described in Section
> 6.1.6
> <https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html#rejected-ech>
> ."
>
> So it simply refers back to Section 6.1.6 again, which then gets
On Mon, Mar 6, 2023 at 9:30 PM Viktor Dukhovni
wrote:
> On 6 Mar 2023, at 8:13 pm, Peter Gutmann
> wrote:
>
> > Not really sure how to fix this, although at the moment "stay with TLS
> > classic" seems to be the preferred option.
>
> There are three stages of fixes:
>
> 1. Update the protocol sp
On Tue, Mar 7, 2023 at 6:50 AM Viktor Dukhovni
wrote:
> On Mon, Mar 06, 2023 at 11:18:50PM -0800, Nick Harper wrote:
>
> > > Basically, one way or another, PSK key exchange mode negotiation needs
> > > to be interoperable by default.
> >
> > Based on your fi
On Tue, Mar 7, 2023 at 6:51 PM Viktor Dukhovni
wrote:
> What specific changes would you recommend in say the OpenSSL
> implementation? Just not sending the useless tickets? Fine, we've
> saved a bit of bandwidth, but haven't really solved the problem.
>
I don't know the details of the OpenSSL
I have a slight preference for 3.
On Wed, Jun 26, 2019 at 10:35 AM Salz, Rich wrote:
> Something should be done, I don't have a strong preference for 2 or 3.
> Having this info back then might have prevented Heartbleed.
>
> ___
> TLS mailing list
> TLS
On Wed, Mar 4, 2020 at 5:27 PM Viktor Dukhovni
wrote:
> On Wed, Mar 04, 2020 at 05:19:02PM -0800, Nick Harper wrote:
>
> > > Breaking interoperability.
> >
> > This doesn't break interoperability. If both endpoints negotiate
> > ticketrequests and this new
>
> -Ekr
>
> On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote:
>
>> Does the wording of this PR mean that the value from the exporter changes
>> depending on whether it's run before or after exporter_secret can be
>> computed? I think it would be better to
I prefer TLS 1.3 but am also fine with TLS 4.
On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else. Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-
> 97-tls-
On Mon, Dec 12, 2016 at 5:32 PM, Eric Rescorla wrote:
>
>
> On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson
> wrote:
>
>> On 13 December 2016 at 12:09, Eric Rescorla wrote:
>> > David Benjamin pointed out to me that end_of_early_data is the only
>> place
>> > where we transition keys on an aler
On Mon, May 20, 2024 at 7:26 AM Dennis Jackson wrote:
> Compared to the alternatives, Trust Expressions seems to solve the
> problems less effectively and introduce much greater risks. If you really
> feel the opposite is true, I would strongly encourage you to:
> b) Make a good faith attempt to
easier to adopt and
> deploy any new CA regardless of trust, rather than a system that makes
> it easier to deploy & adopt any new *trusted* CA.
I disagree that it makes it easier to adopt and deploy a new CA *regardless
of trust*. Trust Expressions only makes it easier to deploy a CA that i
On Thu, May 23, 2024 at 4:14 AM Dennis Jackson wrote:
> Hi Nick,
>
> I think the issues around risk have a great deal of nuance that you're not
> appreciating, but which I've tried to lay out below. I appreciate that
> rational reasonable people can absolutely disagree on how they weigh up
> thes
On Fri, May 24, 2024 at 10:14 AM Dennis Jackson wrote:
> Hi David,
>
> The certification chains issued to the server by the CA comes tagged with
> a list of trust stores its included in. The named trust stores are
> completely opaque to the server. These chains and names may not be trusted
> by a
On Fri, May 24, 2024 at 2:27 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:
> In your latest message [5], I understand the context of governments
>> pushing for inclusion of certain roots with varying degrees of legitimacy.
>> I don’t see the on-ramp for CA pre-distribution being meanin
On Fri, May 24, 2024 at 4:15 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:
> The part of the spec you quoted says: if multiple certs match, choose any.
> When TE is rendered in actual code, why do you assume that there will be no
> configurable or easily-gameable way to make sure the g
On Mon, Jun 3, 2024 at 3:02 PM Peter Gutmann
wrote:
> Filippo Valsorda writes:
>
> >The most important performance consideration in TLS is avoiding Hello
> Retry
> >Request round-trips due to the server supporting none of the client's key
> >shares.
>
> This is already a huge problem with Chrome
On Wed, Jun 5, 2024 at 6:25 AM Peter Gutmann
wrote:
> Martin Thomson writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and possi
On Tue, Jun 11, 2024 at 3:25 AM Dennis Jackson wrote:
> I think the above captures the main thrust of your argument in this
> thread, but it seems like quite a flawed analysis. If T.E. does not offer
> any new capabilities over certificate_authorities, then there is no point
> in standardizing it
On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson
wrote:
> You can't argue that T.E. contains the functionality of
> certificate_authorities as a subset, then conclude that having additional
> functionalities makes it less risky. You would need to argue the exact
> opposite, that T.E. doesn't contai
The scenario where more than one party has the private keys is described in
scenario 6 [1]. The analysis of that scenario is that trust anchor
negotiation has no effect on the surveillant's ability to carry out their
goals.
1:
https://github.com/davidben/tls-trust-expressions/blob/main/surveillanc
On Fri, Jul 19, 2024 at 8:58 PM Salz, Rich wrote:
>
>- I've read it before. I the main issue is that it says "trusted" a
>lot.
>
>
>
> Yeah, kinda snippy but not necessarily wrong.
>
>
>
> I’m a little skeptical of approaches that solve an entire problem space
> with one architecture. I’m
I understand the stated goal of this draft to be to provide a way for
hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
a document that describes how to safely deploy TLS 1.2 sounds like a good
idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
draft
On Sat, Feb 1, 2025 at 10:02 AM Eric Rescorla wrote:
> Starting a new thread to keep it off the adoption call thread.
>
> I'm still forming my opinion on this topic. To that end, perhaps it's
> most useful to focus in on the post-quantum case, as I think that's
> the one that the WG finds most co
It is silly that in today’s world, we consider it good enough that a server
can send a client an end entity cert and a grab bag of intermediates and
cross signs and tell the client “I hope there’s enough material here for
you to build a path to something that you trust”. If someone proposed a new
s
36 matches
Mail list logo
