On Fri, Jun 07, 2024 at 01:04:33PM +0200, Hubert Kario wrote:
> On the other hand the RFC states (section 1.1):
>
> ...
> A client that requests
> session resumption does not in general know whether the server will
> accept this request, and therefore it SHOULD send the same extensions
>
As is well known, the RFC6066 maximum_fragment_length (MFL) extension has a
few serious deficiencies, that led to its subsequent deprecation in
favour of RFC8449 record_size_limit (RSL).
Nevertheless a number of TLS implementations still support MFL, and
there is some history of
On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote:
> I realise that absence of evidence != evidence of absence, but in response to
> my previous request for anyone who has such a thing to comment on it, and even
> better to send me a sample so I can see one, no-one has mentioned, or
>
On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote:
> I looked into what RFC 8446(bis) says about Raw Public Keys. As
> correctly stated in RFC 8446, TLS 1.3 with signatures and certificates
> is an implementation of SIGMA-I:
Assuming certificates are issued with strong assurance,
On Mon, Dec 11, 2023 at 07:51:13PM -0800, Rob Sayre wrote:
> > Absolutely clear. I work with stuff with 20-30 year deployment and
> > life cycles. I'm fairly certain TLS 1.2 will still be around when
> > the WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> I have to say, I am
On Mon, Dec 11, 2023 at 06:38:05PM -0500, David Benjamin wrote:
> Protocol changes generally require both client and server changes to take
> effect. Pre-existing deployments, by simply pre-existing, will not have
> those changes. If we add, say, post-quantum options for TLS 1.2, it will
>
On Mon, Dec 11, 2023 at 02:40:41PM -0800, Rob Sayre wrote:
> > Given that TLS 1.2 will be around for quite some time
>
> Not clear.
As a data point, I've had no luck so far with encouraging the email
operators of domain-registry.bg to upgrade their primary MX from TLS 1.0
to at least TLS 1.2.
On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:
> PS - I have to say, not in this message, but sometimes it seems like the
> goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
> TLS 1.2 that the draft describes are desirable. If that's the case,
> participants
On Wed, Dec 06, 2023 at 12:33:52AM -0500, 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 to confirm this on the list. Please
On Wed, Nov 29, 2023 at 10:49:42AM -0500, Russ Housley wrote:
> People are implementing RFC 8773, so I would like to advance this to
> the standards track. In addition, this fixes the only errata that was
> posted against RFC 8773.
>
I am somewhat confused by an apparent conflict between:
On Fri, Nov 17, 2023 at 09:57:42AM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >Indeed, Postfix 3.9 (release estimated Q1 '2024), when compiled against
> >OpenSSL 3.2 (release estimated circa next week), will automatically signal
> >client certificate types
On Thu, Nov 16, 2023 at 09:00:52PM +0200, Mohit Sethi wrote:
> Unless I am mistaken, it has probably slipped under the radar of the
> WG that this indication is already achievable by using the
> client_certificate_type extension defined in RFC 7250:
> https://datatracker.ietf.org/doc/html/rfc7250
On Wed, Nov 08, 2023 at 03:54:05AM +, Andrei Popov wrote:
> A few concerns I have with this extension:
>
> 1. Privacy: clients broadcasting intent to identify themselves to
> anyone who asks. I know, this is intended for crawler bots, but the
> TLS stack does not know whether our
On Wed, Oct 25, 2023 at 02:34:08AM +, Peter Gutmann wrote:
> Andrei Popov writes:
>
> >An "I really mean it" flag. We can add these for every TLS message, not just
> >authentication-related ones. Just to make sure the peer truly is serious
> >about the TLS handshake.
>
> It really depends
On Tue, Oct 24, 2023 at 04:13:48PM +, Andrei Popov wrote:
> > So it may be necessary to have the server respond with its own flag
> > to indicate that it really does want client cert auth and isn't just
> > asking for a client cert on autopilot.
>
> An "I really mean it" flag. We can add
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
> undesirable UI to human-backed clients.
My concern is errors, browser UX concerts are
On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:
> > At least as a client, you can't read anything into seeing a cert request
> > from the server, it's just a standard part of the handshake, like a keyex
> > or a finished.
>
> This is exactly my argument: when a client receives a
On Tue, Oct 24, 2023 at 02:40:35AM +, Peter Gutmann wrote:
> >Yes, but, arguably, such broken clients won't be fixed by adding new
> >extensions/flags/etc. If they do not comply with the simple RFC language that
> >exists, can we expect them to implement the new flag correctly?
>
> I would
On Mon, Oct 23, 2023 at 05:49:47PM +, Andrei Popov wrote:
> >> They could just proceed without a certificate, or return a default
> one, but they don't.
>
> Yes, but, arguably, such broken clients won't be fixed by adding new
> extensions/flags/etc. If they do not comply with the
On Mon, Oct 23, 2023 at 11:36:10AM -0400, David Benjamin wrote:
> 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
>
On Tue, Aug 29, 2023 at 10:55:56AM +0200, Ben Smyth wrote:
> TLS 1.2 dictates: Either party may initiate a close by sending a
> close_notify alert...The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately, discarding
> any pending writes.
>
>
On Mon, Aug 28, 2023 at 04:02:18AM -0700, RFC Errata System wrote:
> Both parties need not wait to receive a "close_notify" alert before
> closing their read side of the connection, though doing so would
> introduce the possibility of truncation.
While the paragraph text is under the microscope,
On Fri, Jul 14, 2023 at 04:03:25PM +, Peter Gutmann wrote:
> Interesting, so you're saying that essentially no-one uses custom groups? My
> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
> allows custom groups (with additional checking) to be on the safe side
On Fri, Jul 14, 2023 at 04:53:42PM +0300, Nimrod Aviram wrote:
> There are a few valid arguments, from yourself and others here, to soften
> the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.
The formulation I would choose would be:
- MUST prefer ECDHE key exchange, when
On Thu, Jul 13, 2023 at 03:03:15PM +0200, Hubert Kario wrote:
> And in general, it's far better to use FFDHE kex with legacy client
> than RSA. Getting RSA right is very hard, using ephemeral secrets for
> FFDHE is trivial and recommended practice already.
Indeed, though I agree that TLS
On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
> > On Jul 11, 2023, at 13:52, Salz, Rich wrote:
> >
> >> This email starts the working group last call for "Deprecating Obsolete
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> >
> >> .
On Tue, Apr 18, 2023 at 09:06:40PM -0300, Soni L. wrote:
> That seems particularly useful for federated networks (XMPP, etc). Why
> not call these server-to-server certs?
That's basically it. At least in OpenSSL, when a EKU extension is
present in the client certificate, it must allow client
On Wed, Apr 12, 2023 at 08:41:31PM +, Salz, Rich wrote:
> Is this generally used? Would things go badly if we stopped sending them?
I take you mean sending CA names as part of a certificate request.
https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
On Sun, Mar 26, 2023 at 02:18:58AM +, Yannick LaRue wrote:
> [...] This means that information such as the client's name, email
> address, and other identifying details are transmitted in cleartext,
> potentially allowing for interception and exploitation by malicious
> actors.
This is true
On Wed, Mar 08, 2023 at 05:11:27AM +, Peter Gutmann wrote:
> I think a safer option moving forward is "scrap it and order a new one", just
> do an RFC with a new, single extension with unambiguous semantics that
> reintroduces the TLS classic session resumption, but done with TLS 1.3
>
On Tue, Mar 07, 2023 at 03:49:13PM -0800, Nick Harper wrote:
> It is interoperable by default, if the implementations follow the spec. If
> implementations don't follow the spec, no amount of spec language will fix
> their behavior.
What specific changes would you recommend in say the OpenSSL
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 first message, it sounds like you have identified an
> implementation where it is not interoperable. All
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 specification.
2. Fix the implementations.
3. Keep using TLS 1.2 until
On Fri, Mar 03, 2023 at 03:49:28PM -0800, Watson Ladd wrote:
> > 20 years is a long time. We can only reason about shorter timelines.
> > In the next ~5 years, I don't yet see a defensible reason to deprecate
> > TLS 1.2.
>
> 20 years from today we'll be dealing with products shipped out today.
On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:
> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.
20 years is a long time. We can only reason about shorter timelines.
In the next ~5 years, I don't yet see a defensible
I took a look at whether it is practically possible for a client to
"opt-in" to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
"psk_key_exchange_modes" extension consisting of just "psk_ke".
Turns out that at least when the server is OpenSSL, the client is likely
to be sad.
Details
On Tue, Feb 14, 2023 at 04:22:48PM +1300, Marten Seemann wrote:
> It hides certain bits of the header, as well as the packet number,
> from an on-path observer. This is crucial to prevent middleboxes from
> being "helpful" and acting upon (observed) gaps in packet numbers. As
> such, it's hard
On Mon, Feb 13, 2023 at 06:13:36PM -0800, Christian Huitema wrote:
> The process for any proposal is to submit a draft to the relevant
> working group. I have no idea whether you will find a better reception
> in QUIC or in TLS. Your proposal amounts to lowering security in order
> to improve
On Sat, Feb 04, 2023 at 07:25:31PM +0100, Achim Kraus wrote:
> My interpretation of RFC5246, 7.4.6 Client Certificate
>
> https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6
>
> "If no suitable certificate is available, the client MUST send a
> certificate message containing no
On Sun, Jan 22, 2023 at 03:41:06PM -0500, Viktor Dukhovni wrote:
> Thanks to Todd Short, RFC7250 raw public keys should be available in
> OpenSSL ~3.2. Applications that use unauthenticated opportunistic TLS,
> employ DANE or have other ways to avoid X.509 certificates and make do
&
On Sat, Jan 28, 2023 at 02:18:01PM -0500, Viktor Dukhovni wrote:
> On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:
>
> > This draft looks good.
> >
> > One nit, omitted "TLS" before SignatureAlgorithm in two places in
> > https://www.ietf.org
On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:
> This draft looks good.
>
> One nit, omitted "TLS" before SignatureAlgorithm in two places in
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3
Would it be appropriate to clarify the status of Ed25519 in
On Sat, Jan 28, 2023 at 03:03:54PM +0200, Ilari Liusvaara wrote:
> On Sat, Jan 28, 2023 at 08:35:40AM +, John Mattsson wrote:
> > Thanks Ilari for that very fast and detailed answer. I a made a PR to
> > RFC8446bis to suggest adding “A node MAY use the same certificate as
> > both server and
On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote:
> "If the extension is present, then the certificate MUST only be used
>for one of the purposes indicated. If multiple purposes are
>indicated the application need not recognize all purposes indicated,
>as long as the
On Mon, Jan 23, 2023 at 09:04:40PM +, John Mattsson wrote:
> RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
> Section 4.1 of RFC 5280".
>
> The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
> which says that: "MUST support the uncompressed form and
On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Hi Viktor,
>
> Are point compressed secp256r1 RPKs supported?
>
> - Uncompressed secp256r1 RPKs are 91 bytes.
> - Point compressed secp256r1 RPKs are 59 bytes
> - Ed25519 RPKs are 58 bytes
It looks to me like EC keys will be sent
On Mon, Jan 23, 2023 at 09:56:05AM -0500, Viktor Dukhovni wrote:
> On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
>
> > > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > > accepted. I don't recall seeing any code to transmit point
>
On Mon, Jan 23, 2023 at 02:51:45PM +, Salz, Rich wrote:
> > Assuming OpenSSL's d2i_PUBKEY(3) can decode these, they'll be
> > accepted. I don't recall seeing any code to transmit point
> > compressed public keys *to* the peer, but may have missed it,
> > wasn't looking at the codec that
On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:
> Are point compressed secp256r1 RPKs supported?
There is no RPK-specific code that either accepts or rejects point
compression in ECDSA public keys received from the peer:
https://www.rfc-editor.org/rfc/rfc5480#section-2.2
Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2. Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing
On Mon, Jan 02, 2023 at 06:32:26PM +0200, Nimrod Aviram wrote:
> (To concede a point in advance: It is obviously possible to _assume_ that
> if the server presents a modulus, then it "must" be a safe prime, or it
> meets some desired security notion that the server operator has deemed
>
On Thu, Dec 22, 2022 at 05:56:50AM +, Peter Gutmann wrote:
> John Mattsson writes:
>
> >A more reasonable approach would be to deprecate all cipher suites without
> >_ECDHE_.
> >
> >While the WG is in deprecation mode, please deprecate all non-AEAD cipher
> >suites as well. RFC 7540 did
On Tue, Dec 13, 2022 at 09:46:29AM -0500, Sean Turner wrote:
> This message starts the process to judge whether there is consensus to
> deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by
On Fri, Dec 02, 2022 at 08:20:58PM +, Ollie wrote:
> That said, in reply to your points, I understand DANE to a level that I know
> PKIX isn't applicable to my original intention/query, so perhaps I haven't
> been clear with what I'm looking to achieve.
DANE has 4 certificate usages, and 2
On Fri, Dec 02, 2022 at 06:40:25AM +, Ollie wrote:
> > There's nothing to be gained by publishing SCTs in self-issued DANE-EE
> > validated certificates. Are you proposing to make SCTs mandatory in
> > DANE? Which user agents would insist on such SCTs and why? If not,
> > what problem would
On Wed, Nov 30, 2022 at 11:35:09PM +, Ollie wrote:
> It increases the barrier of entry to someone having ownership of a
> valid domain, configuring a full DNSSEC chain and configuring a valid
> certificate with an appropriate DANE record. Everyone of those
> trillion requests would need to be
On Tue, Nov 29, 2022 at 04:04:58PM +0100, Bas Westerbaan wrote:
> > On the other hand, the actual certificates are not what one
> > would want to log anyway. Instead one would only want to log DS RRsets
> > or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> > 2LD, 3LD, ...
On Mon, Nov 28, 2022 at 06:23:36PM -0800, Eric Rescorla wrote:
> Thanks for the elaboration, Viktor.
>
> I think the TL;DR here is that this isn't TLS-relevant work at present.
> Either you get the certs directly or you get them via RFC 9102 but in
> either case, TLS has the appropriate support.
On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote:
> > In essence, I'm proposing that user agents should trust a fully DNSSEC
> > domain with a TLS certificate set up using DANE, along with changes to CT
> > log submission process to allow self-signed certificates (looking to
> >
On Mon, Nov 28, 2022 at 12:27:07PM -0800, Eric Rescorla wrote:
> How much of the TLS part of this objective is achieved by RFC 9102?
Well, RFC9102 is at a different layer. It provides a mechanism for
clients to obtain a TLSA RRset by other means than direct DNS lookup,
because that often runs
On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Then publish the certificate. Then the victim is unable to read email
> encrypted to her. A DoS that costs the attacker very little,
> practically nothing.
What victim is that?
All the PoP does is make it harder
On Sat, Oct 01, 2022 at 09:33:30PM -0400, Phillip Hallam-Baker wrote:
> Now we have ACME, why not move to 3 day certs issued daily and avoid the
> need for revocation entirely?
This could put rather a strain on certificate transparency. 30x times
the renewal cadence. Not that I personally
On Thu, Sep 15, 2022 at 01:16:33PM +, Fries, Steffen wrote:
> I was just double checking if there was an answer to the question of
> using the TLS renegotiation extension from RFC 5746 in the context of
> TLS session resumption. As stated below, based on the RFC it is not
> crystal clear if
On Thu, Aug 25, 2022 at 05:12:43PM -0400, Ben Schwartz wrote:
> > Here is my another undisclosed ambition, a PSI free Internet.
>
> I think you would be better off starting with DANE (RFC 7671), rather than
> ECH. If you're willing to accept DNSSEC as a requirement, all sorts of
> strange
On Fri, Jul 29, 2022 at 09:50:56AM -0400, Erik Nygren wrote:
> Also including an Extended SNI option for "Certificate Fingerprint"
> would solve a bunch of issues that have come up from time-to-time.
> For example, it might help with DANE.
DANE does not need and must not carry a client-side
On Sun, Jun 26, 2022 at 04:29:38PM -0400, Robert Moskowitz wrote:
> I will use them in draft-ietf-drip-registries for our X.509 certs and
> our 'custom' attestation certs (private OID will be needed). And then
> the powers-that-be can sort it out as we move forward.
Why do the certificates
On Mon, Jun 13, 2022 at 02:16:03PM -0400, Daniel Migault wrote:
> Thanks for the detailed response, that is very much appreciated. When I
> wrote the initial email, I had more in mind some sort of configuration - as
> opposed to DANE. I agree that the use of PSKI should not cause any of the
>
On Mon, Jun 13, 2022 at 10:42:51AM -0400, Daniel Migault wrote:
> I sent this question regarding the use of SPKI Fingerprints to the
> add mailing list, but I am also eventually interested to feed backs not
> necessarily restricted to encrypted resolvers.
>
> RFC 7858 (DNS over TLS) indicates
On Tue, Feb 01, 2022 at 08:55:02PM +0100, Stefan Santesson wrote:
> However, I'm curious about the facts of the case, and would appreciate
> if people here could help me answer a key question:
>
> - Would removal of such upper bounds (e.g. common name max 64
> characters) break TLS in any way
> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer wrote:
>
> So our plan moving forward is to essentially keep the new text on OCSP [1]
> and add a reference to RFC 7633 (the certificate must-staple extension). But
> only as a MAY. In addition, we will add a MUST requirement to perform (some
> kind
On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote:
> > > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > > we urge the CAs to be more strict here? Perhaps that would be another
> > > recommendation.
> >
> > CAA lookups must not softfail. This needs to be the
> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor
> wrote:
>
>> Without wanting to detract too much from the core question of the thread,
>> how does this address the routing gap? The adversary at the routing layer
>> just redirects the host being validated to control the key that way, and
>>
> On 19 Jan 2022, at 9:57 am, Yaron Sheffer wrote:
>
> But this raises a larger question: many client-side implementations soft-fail
> if they don’t get an OCSP response within the handshake, i.e. they just
> ignore the problem. As far as we understand, this makes OCSP stapling
> completely
On Tue, Nov 02, 2021 at 01:18:22PM +0100, alex.sch...@gmx.de wrote:
> my question addresses the negotiation of the "encrypt_then_mac" extension
> proposed in RFC 7366 and, specifically, two possible interpretations of such
> negotiation when using AEAD ciphers.
I think the source of the
On Wed, Nov 03, 2021 at 11:12:00AM +0100, Robin MARX wrote:
> I'm wondering if you could give a bit more details about the expected
> outcome of this meeting?
Indeed it is hard to see how OpenSSL project governance and development
priorities are a subject matter for the IETF TLS and/or QUIC
> On 6 Aug 2021, at 3:31 pm, Benjamin Kaduk
> wrote:
>
>> That said, I've given up fighting potentially counter-productive "raising
>> the floor"
>> rather than "the celing" on all fronts, and now try to focus on just the
>> most important
>> cases. Thus have accepted the fact that sadly no
> On 6 Aug 2021, at 2:51 pm, Ilari Liusvaara wrote:
>
> As note: the DH_anon and ECDH_anon names are a bit misleading: Those
> two are actually ephemeral (but are still rarely a good idea to use)
For what it is worth, anon DH, and anon ECDH ciphers are used by default
in Postfix when doing
ot;standard"
groups (from outdated informational RFCs, ...) of suspect provenance
might reasonably be blacklisted.
On Sun, Aug 01, 2021 at 11:42:22AM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >OK, who goes around bothering to actually generate custom DH para
On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >I strongly doubt there's a non-negligible server population with weak locally
> >generated groups.
>
> Would you care to rephrase that so we can make sure you're saying what
On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (sfluhrer) wrote:
> > Was it wrong to generate server-side DH parameters?
>
> The problem is that it is hard for the client to distinguish between a
> well designed server vs a server that isn't as well written, and
> selects the DH group
On Fri, Jul 30, 2021 at 05:14:08AM +, Peter Gutmann wrote:
> >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code
> >points that use negotiated groups from the group list. But it is far from
> >clear that this is worth doing given that we now have ECDHE, X25519 and
On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote:
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> > This is a working group call for adoption of Deprecating Obsolete Key
> > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00
> >
On Fri, Jul 16, 2021 at 04:55:49PM -0700, Christopher Wood wrote:
> This is the second working group last call for the "A Flags Extension for TLS
> 1.3" draft, available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>
> Please review this document and send your
On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:
> > But, it makes for a fairly terrible user interface for the human
> > operator. Compare:
> >
> > * managesieve
> > * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
>
> I agree that
On Thu, May 20, 2021 at 11:52:50AM -0700, Nick Harper wrote:
> > Since the likelihood of actually adding exotic ALPN values to the
> > registry appears slim, why not say so. That would leave the exotic
> > values for private on-the-wire use, while allowing DNS and other
> > configuration
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 files, ...) a more restricted character
> > set would actually be
On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
> ALPN IDs are byte strings; the fact that some of them can be displayed
> as ASCII character strings merely reflects the fact that those ALPN
> IDs were chosen by humans.
That's fine when they're just private signalling between a
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
> 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
>
On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
> wrote:
>
> > On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> >
> > > I support limiting it.
> >
> > I concur. These are not
On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> I support limiting it.
I concur. These are not strings used between users to communicate in
their native language. They are machine-to-machine protocol
identifiers, and use of the narrowest reasonable character set promotes
On Wed, Mar 17, 2021 at 08:15:53AM +0100, Ben Smyth wrote:
> > Do I understand that right? And if so, what is the point of the
> > language in the RFC that appears to permit a half-close?
>
> Specifications don't define systems, they guide design. The specification
> does not "requir[e] an end
On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
> > Because there are still many TLS (non-web) implementations that don't
> > do ECDHE.
>
> I'm confused: if those implementations don't do ECDHE, what's wrong
> with prohibiting the way it's used?
The proposal on the table is to
On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote:
> > My take is such measures are much too complicated. Just keep the connection
> > lifetime short, and make a new one from time to time. Also keep certificate
> > lifetimes short. Where DNSSEC is an option on both ends, you can
On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:
> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > >In practice security improves more when you raise the ceiling, rather the
> > >floor.
> >
On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote:
> > I think the blanket prohibition of reuse of ECDHE keys is maybe not
> > really justified.
>
> Why is that?
Because there are still many TLS (non-web) implementations that don't
do ECDHE.
Is there a credible active MiTM attack
On Mon, Mar 08, 2021 at 08:51:31AM +, Fries, Steffen wrote:
> The problem that was addressed so far with the session renegotiation in TLS
> 1.2 was motivated by different points.
>
> - Recommendation in RFC 5246 regarding the use of the SessionID lifetime
> - Regular session key update for
> On Mar 8, 2021, at 1:45 AM, Peter Gutmann wrote:
>
> Not that "never" since it would break a lot of things, but some time far
> enough in the future that you don't have to worry about it.
The cert generator I cobbled together for the OpenSSL test-suite
generates 100-year certs. These work
On Sun, Mar 07, 2021 at 07:31:24PM -0800, Benjamin Kaduk wrote:
> Just to confirm: the scenario you're using to contrast to the one described
> by Viktor (and Nico) is a scenarios in which the certificates expire at
> "never"
> (1231235959Z)?
>
> I think that at least some people are
On Sun, Mar 07, 2021 at 11:19:49PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > > So instead of getting one chance a year for your control system to break
> > > itself if the renewal fails, you get hundreds of them?
> >
> >Yes. Exactly. It's a human factors problem. And this solution
On Sat, Mar 06, 2021 at 12:11:25AM -0600, Nico Williams wrote:
> On Fri, Mar 05, 2021 at 04:46:15PM -0800, Eric Rescorla wrote:
> > This leaves us with the case where Bob's certificate is no longer valid but
> > Bob has a new certificate [0]. In this case, just re-validating does not
> > help.
1 - 100 of 459 matches
Mail list logo
