Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

I support adoption. Cheers, Andrei -Original Message- From: TLS On Behalf Of Watson Ladd Sent: Friday, April 26, 2024 7:13 PM To: Devon O'Brien Cc: tls@ietf.org; Bob Beck Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions On Tue, Apr 23, 2024 at 1:39 PM Devon

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

* Well, don't we want to say how this is supposed to work somewhere? I doubt this will take much time. The authors may want to, but could this be an independent submission, rather than WG item? It seems that the real goal here is to enable a specific scenario between a cloud provider and a

Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction

* …and now I'm coming around to the idea that we don't need to do anything special to account for the "wrong" server behavior. Since RFC8446 already explicitly said that clients are allowed to not predict their most preferred groups, we can already reasonably infer that such servers

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

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 caller is a bot, so we will have to implement API support, which will be used

Re: [TLS] [EXTERNAL] Re: Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Likewise, I support adoption, willing to contribute text and implementation. Cheers, Andrei From: TLS on behalf of David Benjamin Sent: Monday, November 6, 2023 9:26 AM To: Joseph Salowey Cc: Subject: [EXTERNAL] Re: [TLS] Adoption call for Legacy

Re: [TLS] [EXTERNAL] Re: Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

can detect incompatible client crypto devices and update TLS stacks as needed. Cheers, Andrei From: David Benjamin Sent: Friday, October 27, 2023 11:34 AM To: Benjamin Kaduk Cc: Andrei Popov ; TLS@ietf.org Subject: [EXTERNAL] Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 On Fri, Oct

[TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

Hi TLS, We would like to re-introduce https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/ (it's intended for the TLS WG and the Standards track, despite what the document says at the top; we'll fix it as soon as the submission tool reopens). In the course of TLS 1.3 deployment, it

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

> 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 these for every TLS message, not just authentication-related ones. Just to

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

an empty Certificate and continue with the handshake... -Original Message- From: Peter Gutmann Sent: Monday, October 23, 2023 7:41 PM To: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Request mTLS Flag Andrei Popov writes: >Yes, but, arguably, such broken clients wo

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

>> It would be useful to be able to request certificates conditioned on the >> client promising to not fail just because it is unable or unwilling to offer >> one. TLS RFCs do not require clients to fail the handshake when the server requests a cert and the client cannot satisfy the request.

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

The use-case is not very clear to me: when is the decision whether to authenticate a client or not based on the availability of a pre-configured client certificate? If the client says they have a pre-configured cert, the server authenticates them; otherwise, the connection succeeds without

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

Popov Cc: David Benjamin ; tls@ietf.org Subject: Re: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov mailto:andrei.po...@microsoft.com>> wrote: * Where these interpretations co

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

* Where these interpretations conflict, the selection may be downgraded, potentially even under attacker influence. Downgrade by attacker is only possible if the client attempts insecure fallback (e.g., offer PQ key share, connection failed, retry without PQ key share)? Or am I missing some

Re: [TLS] [EXTERNAL] Adoption call for draft-jackson-tls-cert-abridge

I support adoption. Cheers, Andrei Popov -Original Message- From: TLS On Behalf Of Christopher Wood Sent: Tuesday, August 1, 2023 12:36 PM To: TLS@ietf.org Subject: [EXTERNAL] [TLS] Adoption call for draft-jackson-tls-cert-abridge Hi all, Based on positive feedback received during

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

A similar question for the client side: are there any Web browsers with Delegated Credentials support? 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

Re: [TLS] [EXTERNAL] Re: SSL cert - CA issuer question - WIndows Event Reporting CA

@M K Saravanan: if you export (w/o private key) and share the cert with me, I can take a look. Windows does not MITM TLS connections. Cheers, Andrei -Original Message- From: TLS On Behalf Of Martin Thomson Sent: Wednesday, June 7, 2023 2:17 PM To: tls@ietf.org Subject: [EXTERNAL]

Re: [TLS] [EXTERNAL] Re: Servers sending CA names

Windows TLS stack uses them (when available) for certificate selection. Schannel-based TLS servers don’t send CA names by default, but can be configured to do so. Cheers, Andrei From: TLS On Behalf Of David Benjamin Sent: Wednesday, April 12, 2023 2:16 PM To: tls@ietf.org Subject: [EXTERNAL]

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

eady comes from a lot of different angles. Cheers, Andrei From: TLS On Behalf Of John Mattsson Sent: Friday, April 7, 2023 8:25 AM To: Andrei Popov ; John Mattsson ; Christopher Wood ; Sean Turner Cc: TLS@ietf.org Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfil

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

* Maybe IETF (e.g., UTA) could say what organizations should definitely not do (like NULL encryption). This is already done. UTA BCPs prohibit NULL encryption and static DH: https://www.rfc-editor.org/rfc/rfc9325.html "Implementations MUST NOT negotiate the cipher suites with NULL

Re: [TLS] [EXTERNAL] Re: TLS 1.2 deprecation

IMHO, no reason to add post_handshake_auth to TLS 1.2, because TLS 1.2 already supports renegotiation. While renegotiation had its share of issues we had to patch over time, doing TLS 1.2 client auth without renegotiation leaks client identity. Cheers, Andrei From: TLS On Behalf Of Rob Sayre

Re: [TLS] multi-identity support in RFC 8446

> I don't have details, but the NVMe/TCP specification suggests that it can > make use of multiple PSK identities during a TLS handshake. >From my read of NVMe spec, it's one PSK/identity per TLS connection: "8.13.5.9 Generated PSK for TLS When used with a non-NULL DH exchange, the DH-HMAC-CHAP

Re: [TLS] multi-identity support in RFC 8446

Hi Chuck, > A quick browse of other sections of RFC 8446 does not show a similar > capability for sending multiple certificates. This can be done using TLS 1.3 post-handshake client auth (https://www.rfc-editor.org/rfc/rfc8446#section-4.2.6). However, this is an optional TLS 1.3 feature and

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

> If there were some technical means to ensure that this was less likely to be > abused, I'd like it more. Perhaps require key update prior to secrets export -Original Message- From: TLS On Behalf Of Stephen Farrell Sent: Monday, November 28, 2022 2:20 PM To: Sean Turner ; TLS List

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

for adoption of draft-thomson-tls-keylogfile On Mon, Nov 28, 2022 at 07:02:20PM +, Andrei Popov wrote: > > I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was > to find a permanent, discoverable location for this document, other > than NSS project's repository.

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

Corrected typo inline. -Original Message- From: Andrei Popov Sent: Monday, November 28, 2022 11:02 AM To: 'Salz, Rich' ; Sean Turner ; TLS List Subject: RE: [TLS] Call for adoption of draft-thomson-tls-keylogfile I oppose adoption of draft-thomson-tls-keylogfile. The stated goal

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was to find a permanent, discoverable location for this document, other than NSS project's repository. Perhaps it's fine to create an RFC for this purpose, but then I'd argue that it should not be an Informational RFC.

Re: [TLS] [EXTERNAL] Re: [Technical Errata Reported] RFC8446 (7250)

Hi Alan, * Windows 11 is doing this today with TLS-based EAP methods. It's a disaster. I own TLS in Windows; please share the details with me, on a separate thread, so we can figure out what’s broken. It’s probably a bug in the SSPI caller (EAP in this case). Generally though, I don’t

Re: [TLS] [EXTERNAL] Re: Published RFC 8446bis -05

In TLS <= 1.2, the client and server agree on the (EC)DHE group to use for key exchange by negotiating it (at the cost of a round-trip). In TLS 1.3, the client tries to guess what (EC)DHE group(s) the server might support and sends key share(s) accordingly (saving a round-trip). When a TLS 1.3

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

concern and seems to run counter to the work in RFC 8446, appendix C.4. Correct. I'm trying to see what the use-case would be, regardless of the proposed design. From: Dmitry Belyavsky Sent: Friday, September 16, 2022 12:01 PM To: David Benjamin Cc: Andrei Popov ; TLS Mailing List Subject: Re

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

* Server can distinguish the client and alter some parameters in response to make the new connection successful. A TLS server would typically choose either server-preferred parameters (cipher suite, EC curve, etc.) among those advertised by the client, or honor the client’s preferences. Can

Re: [TLS] [EXTERNAL] Re: Representing IP addresses in SNI -- proposed draft

+1 to defining separate extensions and avoiding unnecessary coupling. -Original Message- From: TLS On Behalf Of Martin Thomson Sent: Friday, July 29, 2022 8:42 AM To: Erik Nygren ; David Benjamin Cc: TLS@ietf.org Subject: [EXTERNAL] Re: [TLS] Representing IP addresses in SNI -- proposed

Re: [TLS] [EXTERNAL] Re: Client programs and stapling?

The same situation with the Windows TLS stack: we're not parsing status_request carried in the CertificateRequest message. There has not been a business case/request to support this for client certs. Cheers, Andrei From: TLS On Behalf Of David Benjamin Sent: Friday, May 20, 2022 10:24 AM To:

Re: [TLS] [EXTERNAL] Re: [Uta] OCSP in RFC7525bis

Speaking for a broader-than-browser implementation: PKI stack in Windows found hard failure on OCSP non-deployable. This is not to say that OCSP is entirely useless; OCSP information is considered as part of certificate validation. A very much simplified summary: * If OCSP says "revoked",

Re: [TLS] [EXTERNAL] Re: TLS 1.3 and certificate based authentication

1.3, configuring TLS client authentication in the original handshake exposes client certificates in the clear, leaking client identities to the network observer. Cheers, Andrei From: Urmas Vanem Sent: Sunday, January 16, 2022 7:29 AM To: Andrei Popov ; Eric Rescorla Cc: tls@ietf.org Subject:

Re: [TLS] [EXTERNAL] Re: TLS 1.3 and certificate based authentication

Essentially, TLS 1.3 post-handshake authentication is analogous to client auth via renegotiation available with TLS <= 1.2. An important difference is that TLS 1.3 post-handshake authentication is optional, and major browsers chose not to support it. In practice, this means TLS server

Re: [TLS] [EXTERNAL] Re: supported_versions in TLS 1.2

Perhaps I missed some part of this thread, but it's still not clear to me what would be the purpose of adding supported_versions extension to a TLS 1.2 implementation? What problem(s) would that solve? Cheers, Andrei From: TLS On Behalf Of Rob Sayre Sent: Friday, November 26, 2021 11:15 AM

Re: [TLS] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

+1 what Ryan said. Especially the point that added restrictions aren’t a viable path to better interoperability. 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. Cheers,

Re: [TLS] [EXTERNAL] Re: Use-case for non-AEAD ciphers in network monitoring

This NIST workshop is investigating the exact problem discussed on this thread. Several types of solutions have been proposed there. Cheers, Andrei From: TLS On Behalf Of Darin Pettis

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

Hi Brian, * Look at Windows Server 2012 and similar legacy products that are in widespread use, which don't support any PFS cipher suites except FFDHE. Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and TLS_ECDHE_RSA cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps |

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

TLS_DHE is weak when used with interoperable key lengths. It also causes interop issues dues to several instances of under-specification (leading zeros, lack of group negotiation). I'm in favor of deprecating TLS_DHE. Cheers, Andrei -Original Message- From: TLS On Behalf Of Martin

Re: [TLS] [EXTERNAL] Re: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

As written, the document provides a basic/general description of MITM proxies. It mentions some of the issues (client auth, handling of 0-RTT application data, single point of failure, updates/patches, risks of disclosure of PII/PHI), but does not really provide alternatives or specific

Re: [TLS] [EXTERNAL] Re: consensus call: draft-ietf-tls-ticketrequests

Hi Nico, > But also, this WG has tried to accomodate things like SChannel whose API > designs are very different from others and impinge on what is feasible in the > protocol. E.g., reconnects are avoided. Both Session ID-based and session ticket-based TLS resumption options are supported in

Re: [TLS] [EXTERNAL] Explicit curve parameters in Server Key Exchange messages

Hi Juraj, > related to the recent Windows/NSA custom curve certificate issues, we are > wondering whether there are any implementations also supporting explicit > curves in TLS server key exchange messages... Just to clarify: Windows TLS stack only supports named_curve in SKE messages. Cheers,

Re: [TLS] [Technical Errata Reported] RFC8446 (5874)

My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these. However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

Scott Fluhrer (sfluhrer) Sent: Tuesday, July 30, 2019 12:44 PM To: Andrei Popov ; David Benjamin ; Watson Ladd Cc: TLS List Subject: RE: [TLS] Options for negotiating hybrid key exchanges for postquantum I believe that one important property (of either of the options I listed) is a nice fa

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

of these? * Don't do PQ1 + PQ2 + PQ3 + PQ4 + X25519 + P-256 + P-384 + FFDHE2048 + FFDHE3072, oww my head. This is the only thing that IMHO the client should be able to say: * PQ1 + X25519 is cool. I like that combo. On Tue, Jul 30, 2019 at 2:48 PM Andrei Popov mailto:andrei.po...@microsoft.com>>

Re: [TLS] A use of flags

> No resumption in TLS 1.3... You probably mean no renegotiation in TLS 1.3. -Original Message- From: TLS On Behalf Of Martin Thomson Sent: Friday, March 29, 2019 10:25 AM To: Hubert Kario ; tls@ietf.org Subject: Re: [TLS] A use of flags On Thu, Mar 28, 2019, at 14:46, Hubert Kario

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

> I don't think the TLS WG or IETF can win this skirmish. That's what I'm thinking as well, although I agree with the goals of draft-dkg-tls-reject-static-dh-01. Cheers, Andrei ___ TLS mailing list TLS@ietf.org

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

I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost servers some perf: "Given the concerns in Section 2 and the necessary client mitigations in the subsections above, servers need to avoid giving the appearance of using non-ephemeral DH. Servers MUST NOT

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into TLS > was a mistake, and glad to see them gone in TLS 1.3. I agree with the sentiment, but there is a concerted effort to bring fixed (EC)DH to TLS 1.3:

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time on the client side (this includes non-browser connections from all sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client connections. Windows server negotiates TLS 1.0 ~1.5% of the

Re: [TLS] TLS@IETF101 Agenda Posted

Doesn’t IETF have a liaison process that is used to work with other standards bodies? And the bigger question, since the ask is essentially for a multi-party security protocol: Is TLS WG the right place to discuss this? Cheers, Andrei From: TLS On Behalf Of Russ Housley

Re: [TLS] TLS@IETF101 Agenda Posted

> If your consortium want a multi-party security protocol that does not affect > other folks' security as you seem to claim, then that is the obvious route to > explore. +1. It seems that this is at the core of the request. In which case the proper solution is to define this multi-party

Re: [TLS] TLS@IETF101 Agenda Posted

* Second, using TLS1.2 does not technically address the issue. If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniques that have been used in the past are thwarted. * Yes, the server cannot use the "tls_visibility" extension unless the client

Re: [TLS] TLS@IETF101 Agenda Posted

* If the client were to exclusively offer DHE-based ciphersuites, then the visibility techniques that have been used in the past are thwarted. TLS1.3-visibility will be equally thwarted if the client does not send the empty "tls_visibility" extension, right? (Assuming the server chooses to

Re: [TLS] TLS@IETF101 Agenda Posted

* "We" is a consortium of organizations. I would say over 50 so far. They operate large data centers. They are in manufacturing, insurance, finance, and others. * Nalini, why don't you (the consortium) define the standard, then? Indeed, if a “TLS13-visibility” standard has to be

Re: [TLS] Duplicate oid_filters

It should be OK to restrict to one appearance of the same OID, if there is a desire to do so. -Original Message- From: TLS On Behalf Of Benjamin Kaduk Sent: Friday, March 9, 2018 1:45 PM To: Subject: Re: [TLS] Duplicate oid_filters

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

> Ideally, you'd want certificates to be able to have two signatures during > the transition period, in order to support clients who have transitioned and > those who have not. > Hosting multiple certificates and switching based on the client is feasible, > but requires some technical wizardry

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

It's true, the migration will be slow, but IMHO it still makes sense to define and implement an alternative hash. -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, December 15, 2017 10:34 AM To: Eric Rescorla Cc:

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Correct. -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Friday, December 15, 2017 9:46 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org Subject: Re: [TLS] A closer look at ROBOT

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

Here's an attempt to define a SHA-2 alternative: https://tools.ietf.org/html/draft-wconner-blake2sigs-01 Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, December 15, 2017 6:31 AM To: Colm MacCárthaigh

Re: [TLS] Transcript-Hash during Handshake

Thanks, Ilari! -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Thursday, November 23, 2017 11:52 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Peter Wu <pe...@lekensteyn.nl>; Le Van Gong, Hubert <hub...@levangong.org&

Re: [TLS] Transcript-Hash during Handshake

To confirm, TLSInnerPlaintext.type and TLSInnerPlaintext.zeros are not part of the handshake messages, and therefore are not included in the transcript hash? Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Wu Sent: Tuesday, November 21, 2017

Re: [TLS] PR#1091: Changes to provide middlebox robustness

The idea was for the client to randomly add non-existent TLS versions to supported_versions. Presumably, this will exercise the extensibility joint and prevent it from becoming unusable. I'm not convinced this new approach will help, but we know the old one required fallbacks every time a new

[TLS] TLS 1.3 Record Boundaries

Draft-21 says: "Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* Industry groups will force us to use newer versions * Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in. * Business Partners or Government agency customers may require TLS1.3. These mandates/requirements

Re: [TLS] Labels in the TLS 1.3 key schedule

> The labels _are_ ASCII, but _not_ NUL-terminated. Thanks; I can't find any mention of character set or nul-termination in draft-21. Perhaps it would be a good idea to clarify. Cheers, Andrei ___ TLS mailing list TLS@ietf.org

Re: [TLS] Should CCM_8 CSs be Recommended?

It seems that CCM_8 falls in the “limited applicability” bucket. However, there’s nothing wrong with IoT specs requiring these ciphers in their TLS profiles. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey Sent: Wednesday, October 4, 2017 11:42 AM To: Salz,

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

* I don't argue with this but this is not the approach TLS 1.3 took. It provides a generic padding mechanism to be used across application protocols. At some point I thought we said that the TLS 1.3 padding mechanism was supposed to be application-driven (in the form of application-provided

Re: [TLS] datacenter TLS decryption as a three-party protocol

and attestation. Cheers, Andrei From: Colm MacCárthaigh [mailto:c...@allcosts.net] Sent: Thursday, July 20, 2017 8:57 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Stephen Farrell <stephen.farr...@cs.tcd.ie>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] d

Re: [TLS] datacenter TLS decryption as a three-party protocol

Hi Colm, * Today browsers do turn on wiretapping support in the normal case. There's nothing they can do about it, and it works right now. This is news to me; which browsers do this (so that I can avoid using them)? Thanks, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

> As Stephen points out, it looks like we've allocated 80 minutes to the topic > of how to remove the forward secrecy guarantees that we've struggled for over > a year to introduce. That's more than we've allocated for the "main point of > the TLS WG", which are only 65 minutes combined. +1.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Would the Informational track be an acceptable compromise? This does not have to be a product of the TLS working group. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich Sent: Friday, July 7, 2017 10:17 AM To: Russ Housley ; Richard Barnes

Re: [TLS] Separate APIs for 0-RTT

* What if the server receives data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? It appears safe to treat such data as 0-RTT; only the application can make this call, and it needs info from the TLS stack to make this call. * We could say

Re: [TLS] Separate APIs for 0-RTT

Regarding RFC language, I think we could be more specific: 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in; 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in; 3.

Re: [TLS] Separate APIs for 0-RTT

, June 13, 2017 9:50 AM To: Eric Rescorla <e...@rtfm.com> Cc: Rich Salz <rs...@akamai.com>; ML IETF TLS <tls@ietf.org>; Andrei Popov <andrei.po...@microsoft.com> Subject: Re: [TLS] Separate APIs for 0-RTT Please forgive me for this naive question, but is there a specific ince

Re: [TLS] Separate APIs for 0-RTT

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did. WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application? This is more flexible and may involve separate

Re: [TLS] Comments on EndOfEarlyData

Yes, it is my plan to make 0-RTT data opt-in only in the Windows TLS stack, with a clear distinction in the API. It is possible, however, that certain middleware components above the TLS stack might choose to blur this distinction (which would be bad design, in my opinion). Cheers, Andrei

Re: [TLS] The case for a single stream of data

> To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. This is true, and early on there seemed to be general agreement that 0-RTT data

Re: [TLS] Security review of TLS1.3 0-RTT

Indeed, as long as the scope of the ticket <= scope of the nonce database, it appears that rerouting wont’ help the attacker. From: Colm MacCárthaigh [mailto:c...@allcosts.net] Sent: Thursday, May 4, 2017 11:33 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Ilari Liusvaara <

Re: [TLS] Security review of TLS1.3 0-RTT

* Providers already work hard to maximize user affinity to a data center for other operational reasons; re-routing is relatively rare and quickly repaired by issuing a new ticket. Understood, but isn’t an attacker going to be able to re-route at will?

Re: [TLS] Security review of TLS1.3 0-RTT

* I don't think we'll have a problem implementing a single use cache, strike register, we have similar systems for other services, at higher volumes. … and these things work across geographically distributed datacenters, without negating the latency benefits of 0-RTT? Cheers, Andrei

Re: [TLS] Security review of TLS1.3 0-RTT

IMHO what we have is a facility in TLS 1.3 that: 1. Requires extraordinary effort on the server side to mitigate replay (for all but the smallest deployments); 2. Offers no way for the client to determine whether the server is mitigating replay (before replay becomes possible); 3. Is trivial to

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Ø Note that any client which in fact supports Ø SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it, Ø is noncomformant. It's not clear to me how many such clients in fact exist. We saw enough TLS 1.2 clients that are non-compliant in this way that I made the

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Hi Steffen, You’re stepping on a sore point for this WG☺. Based on the strict interpretation of the TLS 1.2 RFC, your conclusions are correct. If a TLS1.2 client does not send the signature algorithms extension (or the extension does not include SHA256), a compliant TLS 1.2 server with a SHA256

Re: [TLS] Updating for non-X.509 certificate types

It will be inelegant to have two code points for what is conceptually the same thing, but I think this is the best option, under the circumstances. Cheers, Andrei From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Friday, March 10, 2017 10:53 AM To: Andrei Popov <andrei.po...@microsoft.com&

Re: [TLS] Updating for non-X.509 certificate types

1.3, when the client is willing to accept TLS<=1.2. Cheers, Andrei -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Friday, March 10, 2017 10:43 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Eric Rescorla <e...@rtfm.com>

Re: [TLS] Updating for non-X.509 certificate types

Ø Does anyone use this? Ø I don't think anyone uses it. Au contraire: Windows TLS stack supports user_mapping and this mechanism appears to be somewhat in use. However, I agree that this falls into the category of extensions that need to be either deprecated or redefined for TLS 1.3.

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

I agree with David: a different client auth mechanism is in the works for HTTP/2. Cheers, Andrei From: David Benjamin [mailto:david...@chromium.org] Sent: Wednesday, February 15, 2017 11:52 AM To: David Wong <davidwong.cry...@gmail.com>; Andrei Popov <andrei.po...@microsoft.com

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Yes, I agree that it is useful to mention this in the spec. From: David Wong [mailto:davidwong.cry...@gmail.com] Sent: Wednesday, February 15, 2017 2:07 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: David Benjamin <david...@chromium.org>; Cas Cremers <cas.crem...@cs

Re: [TLS] Questions on certificate_extensions...

> So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF > OBJECT IDENTIFIER for Extended Key Usage. This is correct. The idea is to use the same format your PKI library already knows how to deal with. > As regards the matching rules. How do these apply when a particular

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Is it important for the client to know, from the TLS stack itself, whether client authentication succeeded or not? My assumption (perhaps incorrect) has been that it is the server that cares about the client's identity (or identities) in order to make an authorization decision. This thread

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

What about Eric’s other point: Ø I am not sure that the regular TLS handshake guarantees these Ø properties either. The reason is that the server is permitted to Ø send data prior to receiving the client's second flight (0.5 RTT Ø data). With the server sending data prior to receiving the

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Indeed, "all known versions of SSL are broken and should never be used" is what I've been telling people for a while now... -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Friday, December 2, 2016 6:36 AM To: Peter Gutmann

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Not that I can speak for the whole of Microsoft, but I would not drop TLS support in Windows if it were renamed "SSL":). However, "transport layer security" makes a lot more sense to me than "secure sockets layer" because the latter seems to imply network socket-style API, which is not a

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Peter has some excellent points here (although I would prefer "TLS 2.0"). Perhaps the "re-branders" are losing votes and hums because we're fragmented into numerous camps. With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where the protocol name remains "TLS" and major

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

Yes, this line has confused me as well. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of William Whyte Sent: Tuesday, November 1, 2016 1:42 AM To: Nick Sullivan Cc: tls@ietf.org Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00 I'm

Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1 Definitely good enough starting point. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xiaoyin Liu Sent: Saturday, October 22, 2016 10:02 AM To: Eric Rescorla ; Stephen Farrell Cc: tls@ietf.org Subject: Re: [TLS] WG adoption of

Re: [TLS] SNI and Resumption/0-RTT

eers, Andrei -Original Message- From: Martin Rex [mailto:m...@sap.com] Sent: Friday, October 21, 2016 6:52 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org Subject: Re: [TLS] SNI and Resumption/0-RTT Andrei Popov wrote: >

Re: [TLS] SNI and Resumption/0-RTT

Rescorla [mailto:e...@rtfm.com] Sent: Thursday, October 20, 2016 5:47 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: tls@ietf.org Subject: Re: [TLS] SNI and Resumption/0-RTT On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft

  1   2   >