Re: [TLS] Commentary on the client authentication presentation slides

capability of TLS). The proposed mechanism does not preclude this option. Cheers, Andrei -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Sunday, August 2, 2015 11:29 AM To: David Benjamin david...@chromium.org Cc: Andrei Popov andrei.po...@microsoft.com

Re: [TLS] Review of PR #209

use CertificateRequest within the handshake, and the new content type outside of it Would the client then also use this new content type for Certificate and CertificateVerify messages (when these are sent after the handshake is complete)? Cheers, Andrei -Original Message- From:

Re: [TLS] Commentary on the client authentication presentation slides

pull request. Right now I don't have a sense of how useful WG participants think this would be. Cheers, Andrei -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Saturday, August 8, 2015 2:04 AM To: Andrei Popov andrei.po...@microsoft.com Cc: David

Re: [TLS] Commentary on the client authentication presentation slides

, Andrei -Original Message- From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Monday, August 10, 2015 10:28 AM To: Andrei Popov andrei.po...@microsoft.com Cc: Ilari Liusvaara ilari.liusva...@elisanet.fi; tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides

Re: [TLS] Allow NamedGroups from the server?

To be clear, I'm in favor of introducing server-side NamedGroups in 1.3. I've no interest in making this change in any earlier protocol versions. Cheers, Andrei From: Eric Rescorla Sent: 10/22/2015 10:40 AM To: m...@sap.com Cc: Andrei Popov; tls@ietf.org Subject

Re: [TLS] Controlling use of SHA-1

I am in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not advertise SHA-1. IMHO it would be best to not allow the server to send certs using any algorithms that don’t agree with signature_algorithms, as TLS 1.2 did. But this is a step in the

Re: [TLS] Allow NamedGroups from the server?

If it's true that the only use of this indication is client auth, then option 1 makes the most sense to me. -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, October 21, 2015 5:01 PM To: Eric Rescorla Cc: tls@ietf.org

Re: [TLS] Allow NamedGroups from the server?

Would the server-side “supported elliptic curves” be used for anything other than guiding client cert selection? Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, October 22, 2015 6:29 AM To: m...@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Allow

Re: [TLS] Allow NamedGroups from the server?

Then my argument would be: why send extra bytes in each ServerHello when TLS client auth is not used most of the time? In this case, CertificateRequest seems to be a better place. From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Thursday, October 22, 2015 10:08 AM To: Andrei Popov <andrei

Re: [TLS] PR#345: IANA Considerations

What is the intended use of the "Recommended" list? I.e. how is an implementer supposed to think about this marker? Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, November 17, 2015 10:01 AM To: IETF TLS Subject: Re: [TLS] PR#345:

Re: [TLS] PR#345: IANA Considerations

are different than those “recommended” for TLS 1.2. On the other hand, something we mark “non-standard” or “vendor-specific” is generally unlikely to move to the “standard” category. From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Tuesday, November 17, 2015 10:47 AM To: Andrei Popov <andrei

[TLS] PR #290: Removing certificate_types and adding certificate_extensions

As discussed at the Interim, I've submitted a separate PR for TLS 1.3 CertificateRequest changes: https://github.com/tlswg/tls13-spec/pull/290 PR #290 includes the following changes: 1. Removes certificate_types, which are no longer needed. 2. Adds client cert selection by certificate extension

Re: [TLS] PR#345: IANA Considerations

. From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Tuesday, November 17, 2015 11:01 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Russ Housley <hous...@vigilsec.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] PR#345: IANA Considerations I would be fine with any name peopl

Re: [TLS] Should we require implementations to send alerts?

I generally agree that sending alerts is the right thing for an implementation to do, for all the reasons discussed on this thread. It is also helpful when RFCs specify the appropriate alerts for various conditions. On the other hand, it seems unimportant whether an alert is defined as a SHOULD

Re: [TLS] Review of PR #209

Liusvaara <ilari.liusva...@elisanet.fi> Cc: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] Review of PR #209 On 16 September 2015 at 08:30, Ilari Liusvaara <ilari.liusva...@elisanet.fi> wrote: > Problem with pulling client auth out of the handshake is t

Re: [TLS] Review of PR #209

From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Wednesday, September 16, 2015 11:25 AM To: Martin Thomson <martin.thom...@gmail.com> Cc: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] Review of PR #209 On Wed, Sep 16, 2015 at 10:48:27AM -07

Re: [TLS] Early code point assignments for 25519/448 curves

Thanks Sean, I support early code point assignment for these curves. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: Monday, November 23, 2015 6:21 AM To: Subject: [TLS] Early code point assignments

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

Yes, per RFC 5246: " If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." Cheers, Andrei -Original Message- From: TLS

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

Yes, our telemetry shows the same. The use of TLS 1.2 increases and the use of TLS 1.0 goes down, but it will likely be a while before we can disable TLS 1.0 by default in Windows. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson

Re: [TLS] Fixing TLS

> I hope that Google's efforts to get QUIC as-is specced out go quickly and > smoothly, and that it can be used as a basis to develop an official total > TCP/TLS replacement. If this were the path forward (and I doubt that it is), I would very much prefer Peter Gutman's evolutionary TLS 1.3.

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

It’s not that the existing version negotiation mechanism doesn’t work; the problem is that implementers got it wrong. Similarly, implementers can mess up the new negotiation mechanism. Especially since we have to support it at the same time as the old one. Cheers, Andrei From: TLS

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Jumping to the end of the thread, it looks like this is an FTP issue that repros when TLS 1.2 is negotiated. Not a TLS version intolerance. The conclusion seems to be that https://support.microsoft.com/en-us/kb/253 resolves the issue, by updating FTP binaries. Cheers, Andrei From: TLS

Re: [TLS] Consensus call for keys used in handshake and data messages

I prefer option 1. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey Sent: Monday, June 13, 2016 12:00 PM To: tls@ietf.org Subject: [TLS] Consensus call for keys used in handshake and data messages For background please see [1]. Please respond to this message

Re: [TLS] 0-RTT, server Application Data, and client Finished

Ø The CertificateVerify message is still listed as an option in the 0-RTT client's first flight at t = 0. Is this a mistake? I have not heard that anyone wants to do this, as there is no possibility of a traditional proof-of-possession in the first flight. I agree with this: client auth in

Re: [TLS] 0-RTT, server Application Data, and client Finished

No plans to implement client auth in 0-th RTT. Cheers, Andrei From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Wednesday, January 27, 2016 11:10 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Bill Cox <waywardg...@google.com>; Martin Thomson <martin.thom...@gmail.com

Re: [TLS] Remove 0-RTT client auth

I am strongly in favor of removing client auth from 0-RTT. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Sunday, February 21, 2016 11:37 AM To: Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Remove 0-RTT client auth +1

Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

[mailto:karthik.bharga...@gmail.com] Sent: Monday, March 28, 2016 2:31 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety > … because secrecy is in the control of the client,

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

Hi Henry, Extension_data field can be zero-length: opaque extension_data<0..2^16-1>; The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU and then says: "Separate specifications may define matching rules for other certificate extensions." Which means that you should be

Re: [TLS] Empty extensions don't go last

Yes, we found this a while ago as well, and had to move extensions around. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Wan-Teh Chang Sent: Thursday, March 24, 2016 12:04 AM To: Martin Thomson Cc: tls@ietf.org Subject:

Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

I'm in favor of this change, as long as it's a binary Y/N. I believe that "Y" can only possibly mean that there is rough IETF consensus to adopt. "Y" cannot mean that this cipher is "cryptographically sound" or "secure", nor can it mean that the "Y" cipher suites are MTI. The reason I'm in

Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

I support adoption of this draft. No reason to limit ECDHE_PSK to CBC. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: Monday, April 25, 2016 8:22 AM To: tls Subject: Re: [TLS] Call for WG adoption of

Re: [TLS] Can we require extensions to be sorted?

Ø The logic required to deal with inter-extension dependencies is now so complex that TLS implementations are forced to pre-parse extensions, adding even more complexity and latency. I agree about the complexity. TLS extensions are essentially sub-protocols that define their own messages, and

Re: [TLS] In-handshake CertificateRequest and 0-RTT

Ø Is the client still authenticated as the previous one too, or just the new one? I think the client that has authenticated as A and then B in the same TLS session, can’t claim to not be A anymore. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Benjamin Sent: Thursday, May 12, 2016

Re: [TLS] draft-rescorla-tls-subcerts

Naïve question: why not simply get a constrained CA certificate and issue short-validity end entity certs? Unless I’m missing something, this would work with existing TLS implementations, no extensions required. Short-lived credential approach seems more viable than

Re: [TLS] draft-rescorla-tls-subcerts

ES/KS > split, sometimes short-lived certs would be more useful. Possibly so. Cheers, Andrei -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Friday, July 15, 2016 2:14 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Eric Rescorla <e

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

AM To: Douglas Stebila <dsteb...@gmail.com> Cc: Andrei Popov <andrei.po...@microsoft.com>; Martin Thomson <martin.thom...@gmail.com>; tls@ietf.org Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate? IIRC, in TLS 1.2 the same k

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Hi Douglas, As currently defined, post-handshake client auth allows the same client to present different identities, but not to repudiate a previously presented identity. So in your example, from the TLS perspective, the client is both Alice and Bob, and therefore I think the same EKM value

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] 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

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] PR #624: Remove Supplemental Auth from TLS 1.3

Hi Eric, MS TLS stack uses the user_mapping extension (to map TLS clients to Windows domain users). We do not implement client/server_authz. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Saturday, September 3, 2016 12:54 PM To: tls@ietf.org Subject:

Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3

Yes, I think so. Cheers, Andrei From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Saturday, September 3, 2016 4:07 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: tls@ietf.org Subject: Re: [TLS] PR #624: Remove Supplemental Auth from TLS 1.3 Thanks for flagging this. Looks like it ca

Re: [TLS] CertficateRequest extension encoding

Ø And how is the value encoded? Using the same encoding as extnValue payload of respective extension in X.509 certifcates? The same encoding as the respective extension in X.509 certificates (please feel free to suggest the language to make this clearer). Ø A CertificateExtension is a hint

Re: [TLS] CertficateRequest extension encoding

gren@gmail.com] Sent: Tuesday, September 6, 2016 8:36 AM To: Peter Gutmann <pgut...@cs.auckland.ac.nz>; David Benjamin <david...@chromium.org>; Andrei Popov <andrei.po...@microsoft.com>; Ilari Liusvaara <ilariliusva...@welho.com>; tls@ietf.org Subject: Re: [TLS] Certficat

Re: [TLS] TLS 1.3 -> TLS 2.0?

This proposal makes a lot of sense to me. I've had numerous conversations explaining to folks that TLS 1.3 is really TLS 2.0. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, August 30, 2016 11:20 AM To: tls@ietf.org

Re: [TLS] Terminology clarification around SSL & TLS

+1. Let's not use a proprietary protocol name for a standard protocol. Conveniently, all SSL is broken now, long live TLS! -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, August 31, 2016 10:40 AM To: Daniel Kahn Gillmor

Re: [TLS] Version negotiation, take two

Do you mean a TLS extension code point per TLS version? One argument against this was that this makes it difficult to express the client's prioritization of TLS versions, but IMHO arguably the server should not care. Cheers, Andrei -Original Message- From: TLS

Re: [TLS] Version negotiation, take two

ons. Cheers, Andrei -Original Message- From: Hubert Kario [mailto:hka...@redhat.com] Sent: Wednesday, September 14, 2016 11:03 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: David Benjamin <david...@chromium.org>; tls@ietf.org Subject: Re: [TLS] Version negotiation, take tw

Re: [TLS] Version negotiation, take two

- From: Salz, Rich [mailto:rs...@akamai.com] Sent: Wednesday, September 14, 2016 12:09 PM To: Andrei Popov <andrei.po...@microsoft.com>; Hubert Kario <hka...@redhat.com> Cc: tls@ietf.org Subject: RE: [TLS] Version negotiation, take two Are there national TLS standards, or just nat

Re: [TLS] CertficateRequest extension encoding

With this change, we can define multiple matching rules for the same extension OID, which might be useful. Looks good to me. Cheers, Andrei From: David Benjamin [mailto:david...@chromium.org] Sent: Thursday, September 22, 2016 6:26 PM To: Andrei Popov <andrei.po...@microsoft.com>;

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

> Pushed to the extreme, the result is a sort of protocol drift, in which buggy > variants get first tolerated, and then accepted as de-facto standards. Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 4.0?), e.g. the relaxed rules around the signature_algorithms

Re: [TLS] Industry Concerns about TLS 1.3

? Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. ? So in my opinion, it makes sense to keep using TLS 1.2 internally. Won't the TLS WG stop addressing newly found protocol-level security issues in TLS 1.2 at some point in the future? I

Re: [TLS] draft-ietf-tls-tls13-16

Ø I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS. + 1 While I agree that the server should be using the server’s preferences in most cases, I see no reason for the client to not list protocol versions (and cipher suites, for that matter) in the

Re: [TLS] Exporter output size

Also, it would be difficult to remove existing functionality, and get the callers to update. E.g. deprecation of TLS_UNIQUE is not going easy for apps/protocols. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Tuesday, October 4, 2016 8:49 PM To: Martin

Re: [TLS] Version negotiation, take two

Ø Is it just that doing an additional "negotiation" within the extension body constitutes another extension point that we would have to actively defend… Yes, the proposed negotiation mechanism is based on the premise that one shall “have one joint and keep it well

Re: [TLS] Version negotiation, take two

> > The server > > will make a choice based on the server's preferences. In a way, the > > proposed version negotiation mechanism makes it slightly easier to > > implement servers that support country X-TLS alongside IETF TLS versions. > > and a list with opaque version identifiers (just int16

Re: [TLS] Version negotiation, take two

void. At the very least, if version is negotiated as extension it must be the very first extension advertised. Cheers, Vlad > On 15 Sep 2016, at 11:03, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 15 September 2016 11:51:31 CEST Benjamin Kaduk wrote: >> On

Re: [TLS] Industry Concerns about TLS 1.3

...@hotmail.com] Sent: Thursday, September 22, 2016 1:58 PM To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org; Andrei Popov <andrei.po...@microsoft.com> Subject: Re: Industry Concerns about TLS 1.3 Adding Andrei Popov. From: BITS Security

Re: [TLS] PR#625: Change alert requirements

> > the only popular stack I found that does not seem to send alerts is > > the schannel from Microsoft To clarify, schannel does generate alerts per RFC, but the HTTP stack (which actually owns the socket) sees no value in sending them. Cheers, Andrei

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] 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

Ø With that said, it does seem like there might be situations where it Ø would be useful to allow resumption/0-RTT with different SNIs. What are some example situations where resumption with a different SNI is useful? Thanks, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric

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

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] Making post-handshake messages optional in TLS 1.3 (#676)

+ Mike who has additional concerns with this. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Tuesday, October 11, 2016 10:22 AM To: Hannes Tschofenig Cc: tls@ietf.org Subject: Re: [TLS] Making post-handshake messages optional

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*

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] 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] 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] 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

Ø 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] 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] 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] 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] 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] 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] 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] 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] 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

, 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

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

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] 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] 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

* 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

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] 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,

[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] 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] 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] 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

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] 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

> 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:

  1   2   >