Re: [TLS] Adoption call for TLS Flag - Request mTLS

lling to provide a client cert. > > Best, > Dennis > On 04/04/2024 11:17, Jonathan Hoyland wrote: > > Hi all, > > Thanks for the feedback here. > > With respect to RFC 7250, as I mentioned earlier on list, there seen to be > two issues. First it changes the semantics of t

Re: [TLS] Adoption call for TLS Flag - Request mTLS

Hi all, Thanks for the feedback here. With respect to RFC 7250, as I mentioned earlier on list, there seen to be two issues. First it changes the semantics of the extension slightly, and second the RFC explicitly excludes x.509 certs. IIUC the semantics of the extension are "I have a weird

Re: [TLS] Proposal: a TLS formal analysis triage panel

I'd be happy to help work on something like this, but it might make more sense to come present at UFMRG. One of the goals of the Research Group is to try and bring together experts and IETFers. Rather than adding formal process, having a low stakes way of engaging with the formal methods

Re: [TLS] tls@ietf119: agenda requests

Hi Sean, I would like to speak briefly on my draft TLS flag that signals client support for mTLS [1], and if possible to have a call for adoption. I would need ~5 mins. Regards, Jonathan [1] https://datatracker.ietf.org/doc/html/draft-jhoyla-req-mtls-flag-01 On Thu, 29 Feb 2024, 16:05 Sean

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

Hi all, So as David mentioned, this doesn't really offer anything for human clients, and is aimed at reliably distinguishing between bots. To be honest it might be better that browsers not implement it, because that massively increases the number of potential users, and thus the noise we get from

Re: [TLS] Request mTLS Flag

Flags work over the line, so even if we can make UpA work here I think there is some value to this work stream. Regards, Jonathan On Mon, 23 Oct 2023 at 22:22, Watson Ladd wrote: > On Mon, Oct 23, 2023 at 9:52 AM Jonathan Hoyland > wrote: > > >> > >> I'm not follo

Re: [TLS] Request mTLS Flag

in my mind this is sent by a bot that is crawling the entire web. It's automated (as opposed to human triggered), and this is an optional hint, so it doesn't matter if there's a privacy leak in that way. (Although that's an interesting thought, do bots have a need for privacy?) Regards, Jonat

Re: [TLS] Request mTLS Flag

tegy seems more straightforward. > > David > > > On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland > wrote: > >> Hey TLSWG, >> >> I've just posted a new draft >> <https://www.ietf.org/archive/id/draft-jhoyla-req-mtls-flag-00.html> >> that defines

[TLS] Request mTLS Flag

Hey TLSWG, I've just posted a new draft that defines a TLS Flag that provides a hint to the server that the client supports mTLS / is configured with a client

[TLS] TLSFlags ambiguity

Hi TLSWG, I'm working on implementing the TLS Flags extension , and I just wanted to clarify a potential ambiguity in the spec. In Section 2 the spec says: Such documents will have to define which bit to set to show support, and

Re: [TLS] [EXTERNAL] Re: RFC 9345 on Delegated Credentials for TLS and DTLS

adly both the Mozilla and > Facebook test sites are totally missing, neither of them resolve anymore. > > Anyone have any other known test sites or have a contact at > Mozilla/Cloudflare/Meta? > > -Kyle > > On Jul 17, 2023, at 4:06 PM, Jonathan Hoyland > wrote: > >  >

Re: [TLS] [EXTERNAL] Re: RFC 9345 on Delegated Credentials for TLS and DTLS

upport? > > > > Cheers, > > > > Andrei > > > > *From:* TLS *On Behalf Of * Jonathan Hoyland > *Sent:* Monday, July 17, 2023 4:39 AM > *To:* Ilari Liusvaara > *Cc:* tls@ietf.org > *Subject:* [EXTERNAL] Re: [TLS] RFC 9345 on Delegated Credentials for TLS

Re: [TLS] RFC 9345 on Delegated Credentials for TLS and DTLS

Hi Ilari, If you're looking for a currently live server www.facebook.com will serve you a Delegated Credential if you indicate support for it in your ClientHello. If you want other implementations to test against, Cloudflare's fork of Go

[TLS] Delegated Credentials Test Vectors

Hi All, I've been putting together a generator for test vectors for DCs. This code is available as a PR at https://github.com/tlswg/tls-subcerts/pull/119 The vectors generated are for: Leaf public key signature algorithm - DC public key signature algorithm 1. ECDSA (P-384) - EdDSA (Ed25519)

Re: [TLS] Better TLS Client Authentication

Whilst I strongly support Client Authentication use-cases, I think framing it in terms of getting rid of the password is unhelpful. Removing the password and just using a single key stored as a file makes the implicit assumption that everyone always has a secure physical environment. This is not

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

Hi Dave, On Tue, 9 Nov 2021 at 16:13, Dave Cridland wrote: > On Tue, 9 Nov 2021 at 16:01, Jonathan Hoyland > wrote: > > > > Hi All, > > > > My specific solution is to simply include a different fixed string for > each variant of SCRAM and GSS-API, and ideally

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

about the security exponentially harder (and yes, I mean that in the literal / mathematical sense). Regards, Jonathan On Tue, 9 Nov 2021 at 13:00, Dave Cridland wrote: > On Tue, 26 Oct 2021 at 17:33, Jonathan Hoyland > wrote: > > There isn't even a one-to-one relationship bet

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

nathan, > > On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote: > > Hi Ruslan, > > > > Yes, two distinct TLS connections having the same exporter key would be > > really bad, but I'm specifically talking about two runs of some protocol > > bound to a si

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

Authenticators, or MLS, or any other protocol that uses keys, we should use channel bindings to separate protocols run over the top of TLS. Regards, Jonathan On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko wrote: > Hi Jonathan, > > Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

ut in excruciating detail in my thesis.) Having a generic channel binding mechanism is great, I totally support that, we just need to consider that a single TLS session may be used for more than one thing, and that channel bindings should keep each of those things separate. —Sam > > On Wed, Oct 27,

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

0.2021 um 17:32 +0100 schrieb Jonathan Hoyland: > > Hi Sam, all, > > > > I'd like to again raise the issues I pointed out in > > > https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/ > > . > > This draft hasn't received enough security ana

Re: [TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

Hi Sam, all, I'd like to again raise the issues I pointed out in https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/ . This draft hasn't received enough security analysis, and further, I pointed out a specific security issue that remains unaddressed. Using the same label

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

nitial handshake transcript and we could use that? > > [ns] This is a very good question. I didn’t follow the EAP-TLS1.3 > issue closely, but this does seem to imply an imperfect match with > post-handshake authentication in the case of mutually authenticated > connections. I would li

Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

affected, but if two things use this binding then they could be vulnerable. Regards, Jonathan On Thu, 11 Mar 2021 at 21:56, Watson Ladd wrote: > On Wed, Mar 10, 2021 at 3:57 PM Jonathan Hoyland > wrote: > > > > IIUC a channel binding (in this context) provides a unique "n

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

I don't believe so, but that would seem like a configuration issue. I guess if you really wanted you could define an extension that goes in the Certificate Request message (which the AR is based on), assuming there isn't one already, that requests a specific serial number. Although that of course

Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

indings per protocol and per channel and not just per channel that I > can't see though. > > —Sam > > > On Wed, Mar 10, 2021, at 18:57, Jonathan Hoyland wrote: > > IIUC a channel binding (in this context) provides a unique "name" for > > a channel. In the case

Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

IIUC a channel binding (in this context) provides a unique "name" for a channel. In the case where two distinct protocols running over the top of TLS use this definition, they will both get the same channel binding. It might be useful to pull out in the security considerations one consideration

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

One option that I haven't seen mentioned in the thread is Exported Authenticators . EAs let you send a certificate from either side of the connection at any point after the handshake is complete. I'm not sure what the

Re: [TLS] [ECH] Reverting the config ID change

ere it's trivial to block connections using real ECH, regardless of the > length of the config_id, which was why I thought we'd largely dropped the > attempt not to stick out. > > > > On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland > wrote: > > I know that ECH doesn't

Re: [TLS] [ECH] Reverting the config ID change

I know that ECH doesn't provide security against probing attackers, but such an attacker could easily maintain a list of active keys, and drop connections using them. If the key ID is very long, this would be highly effective at allowing grease ECH connections, but blocking real ECH connections.

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

Hi All, For those interested, I've been working on a formal analysis of DCs the results of which should appear online in the next few days. I'll post to the list when it's up. In summary I managed to prove a server only version of DCs secure (i.e. does not violate any of the properties in

Re: [TLS] TLS Export Channel Binding

Hi Alexey On Mon, 4 May 2020 at 16:23, Alexey Melnikov wrote: > Hi Jonathan, > > On 04/05/2020 14:14, Jonathan Hoyland wrote: > > Hi Sam, > > > > If you wanted to use a SCRAM based SASL auth then you could pick > > `p=SCRAM-SHA256-PLUS`, or any other very sp

Re: [TLS] TLS Export Channel Binding

y identify the underlying channel, because you don't have to worry about the (potentially pathological) behaviours of other users of the binding. Regards, Jonathan On Fri, 1 May 2020 at 19:16, Sam Whited wrote: > On Fri, May 1, 2020, at 14:08, Jonathan Hoyland wrote: > > Maybe I'

Re: [TLS] TLS Export Channel Binding

the given label and context are unique. 2. Unless the second protocol does something stupid like leak the TLS session's master secret. On Fri, 1 May 2020 at 17:08, Sam Whited wrote: > Hi Jonathan, > > On Fri, May 1, 2020, at 12:00, Jonathan Hoyland wrote: > > I believe T

Re: [TLS] TLS Export Channel Binding

Hi Sam, I believe TLS Exporters are what you are looking for. https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5 Exporters allow you to produce a key that is a bound to a particular channel i.e. TLS session. Regards, Jonathan On Fri, 1 May 2020 at 15:13, Sam Whited wrote: > Hi all, > >

Re: [TLS] Dropping "do not stick out" from ECHO

I'm worried that it'll be too tempting for orgs and Governments to just drop sessions which have negotiated ECHO. Even if we had wide scale deployment of GREASE, if a third-party can allow GREASE but block successful ECHO handshakes then all the effort we've expended will be wasted. Does the

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

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 > > wrote: > > > This would be for cases where we want to inject extra context into a

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

;. I vaguely remember discussing whether the longer name would tip us into an extra hash invocation at the last IETF, and concluding that it didn't, although I'd have to double check that. Regards, Jonathan On Mon, 24 Feb 2020, 22:23 David Benjamin, wrote: > On Mon, Feb 24, 2020 at 4:33 PM Jona

Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer

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 | +-> Derive-Secret(., "ext binder"

Re: [TLS] External PSK design team

Hi All, This is something I'm very interested in. Definitely want to participate. Regards, Jonathan On Tue, 21 Jan 2020 at 10:04, Mohit Sethi M wrote: > I would let CFRG deal with the PAKE selection process: > https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs > and not

Re: [TLS] Binder key labels for imported PSKs

Hi Rob, The situation we are trying to prevent is when both the client and server think they have completed a handshake with each other, but disagree on what happened. In this case, for example, the client might have used a PSK importer, but the server might believe the client has used a vanilla

[TLS] TLS 1.3 Extended Key Schedule

Hi TLSWG, Chris and I have put together a draft for adding extra key material into the TLS 1.3 handshake. There are various drafts that want to inject extra information into the key schedule, so it would be great if we could manage to do this in a generic way. You can have a look here

Re: [TLS] Distinguishing between external/resumption PSKs

On Thu, 19 Sep 2019 at 21:57, Richard Barnes wrote: > I don't think anyone's asking for these cases to be differentiable on the > wire. The question is whether the *server* can differentiate, in > particular, the application running on the server. > > --Richard > Exactly. I hope it's not

Re: [TLS] Distinguishing between external/resumption PSKs

Ah yes, Richard is right, the PSK IDs do not have a defined structure. Having two different PSKs attached to a single PSK_ID should be banned if it isn't already. Regards, Jonathan On Thu, 19 Sep 2019 at 16:26, Richard Barnes wrote: > On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyl

Re: [TLS] Distinguishing between external/resumption PSKs

have a defined structure. Regards, Jonathan On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) wrote: > > > > -Original Message- > > From: Jonathan Hoyland > > Sent: 19 September 2019 14:32 > > To: Owen Friel (ofriel) > > Cc: Martin Thomson

Re: [TLS] Distinguishing between external/resumption PSKs

Hi Owen, If I understand your question correctly the distinguishing is done implicitly (not explicitly) through the key schedule. If the client and server do not agree on whether the PSK is a resumption or an OOB PSK then the `binder_key` will not match, and the handshake will fail. See pp.

Re: [TLS] Binder key labels for imported PSKs

Hi Martin, So I agree that on the micro-scale there is limited practical value to be gained from adding this binding. The theoretical benefits, which mean that the client and server agree that PSK Importers are being used are nice, but on their own might not justify a high-effort change. However,

Re: [TLS] Comment on draft-thomson-tls-sic-00

Hi Martin, Could you comment on how the client and server know they agree on the certificate chain? Would it be possible for the client and server to resolve the certificate chain down two distinct paths, for example in the case of cross signed certificates? If so, is there a security risk here,

Re: [TLS] ETSI releases standards for enterprise security and data centre management

Isn't there a lower bar at the IETF for defining new cipher suites, as long as you're not seeking a "recommended" setting? I think escrowing lower down keys / not MACing the messages beyond the handshake means that you lose authenticity and integrity of the message data, which is unattractive.

Re: [TLS] ETSI releases standards for enterprise security and data centre management

Is it necessarily true that any key escrow system must allow resumptions? Just to play devil's advocate, consider defining a new cipher suite that appended a MAC to each message before applying one of the other cipher suites. If the MAC is keyed with a key not derived from the master secret, but

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

Hi all, Couldn't make it to the second TLS session, but I did suggest on the mailing list a tweak to the universal PSK draft that achieves compatibility, unambiguity, and is straight-forward to prove secure formally. (By which I mean prove independent of the security of TLS 1.2, and thus any hash

[TLS] Fwd: New Version Notification for draft-hoyland-tls-layered-exported-authenticator-00.txt

the PKI. This would require compromising two separate administrative domains. Other use cases and a description of the mechanism appear in the draft. I'd really appreciate any feedback on the design, use cases, and the draft in general. Thanks, Jonathan Hoyland -- Forwarded message

Re: [TLS] Universal PSKs

. In this case the hash function used for the binder remains selectable. Would that resolve your issue? Regards, Jonathan Hoyland On Mon, 18 Jun 2018 at 12:22 Hubert Kario wrote: > On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > > >that's not workable. > > >

Re: [TLS] Universal PSKs

a manually entered key, and the other that it was a TLS 1.2 PSK, which is obviously a plausible threat. Regards, Jonathan On Fri, 15 Jun 2018, 17:13 Benjamin Kaduk, wrote: > On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote: > > Agreement on a channel binding in the ident

Re: [TLS] Universal PSKs

Agreement on a channel binding in the identity would prove, amongst other things, agreement on the KDF used to derive the PSK, whereas the TLS handshake proves agreement on the PSK itself, but says nothing about the derivation of it. This way means you don't have to worry about collisions between

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Hi Nikos, The problems post-handshake authentication has with HTTP/2 are described in draft-ietf-httpbis-http2-secondary-certs-00 a.k.a. draft-Bishop. See Section 1.2.3 in particular. In brief, the problem

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

orrect that an >>> active attacker can do online password guessing. Everything that is >>> revealed on the wire is blinded with fresh, per-connection entropy, and >>> thus doesn't reveal anything about the password. >>> >>> --Richard >>> >

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

can do online password guessing. Everything that is > revealed on the wire is blinded with fresh, per-connection entropy, and > thus doesn't reveal anything about the password. > > --Richard > > > On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland < > jonathan.hoyl...@gmail.co

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

Hi Richard, A few nits. * In the introduction you have the sentence > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet seen significant security analysis. Iiuc this draft has no connection to MLS, and this is a typo. * In the setup you define > o A DH group "G" of

[TLS] Formal analysis of Exported Authenticators

Hi all, A number of people expressed interest in the Tamarin model we made of Exported Authenticators. For those interested, you can see the code, along with an explanatory guide here [0]. The full analysis report is a