Re: [TLS] TLS 1.3 comments

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote: Below a long list of comments, generally minor. The document is already very good - we're making great progress!br The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - Each

Re: [TLS] 0-RTT resumption

On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: We agreed on how to do this in Prague. The sticking point was establishing the cipher suite. I have WIP text on my machine for both of these which I will be sending early next week, once I get enough sleep to be able to clean

Re: [TLS] Computation of static secret in anonymous DH

On Fri, Jun 26, 2015 at 01:41:29PM -0500, Nico Williams wrote: tls-unique depends on the Finished message strongly binding the entire transcript up to that point. I find this elegant (despite the resumption problem, which anyways, should be fixed by the session hash) and easy to understand

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

On Tue, Jul 28, 2015 at 6:28 PM David Benjamin david...@google.com wrote: Are you intending that this mechanism be enabled by default for HTTP/2 or would the prohibition against renego still apply? Without any way for the client to tie the CertificateRequest to the HTTP request that

Re: [TLS] TLS and KCI vulnerable handshakes

On Tue, Aug 11, 2015 at 11:29:12AM -0700, Martin Thomson wrote: On 11 August 2015 at 11:25, Karthikeyan Bhargavan karthik.bharga...@gmail.com wrote: No, a regular ECDSA certificate would do. That is, the attack would work as long as - a client has an ECDSA certificate, and - it enables

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

On Tue, Aug 04, 2015 at 12:37:47AM +, Andrei Popov wrote: Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. There one likely preconfigures client certificates if needed. The proposed client authentication mechanism specifically addresses the case where the client

Re: [TLS] A la carte concerns from IETF 93

On Wed, Jul 22, 2015 at 04:10:27PM -0400, Dave Garrett wrote: Consensus was my current WIP proposal is not viable, for some of the following main reasons: 1) cost/benefit analysis doesn't seem to be worth it 2) backwards compatibility handling 3) some argue harder to implement; others

Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

On Tue, Jul 21, 2015 at 04:39:17PM +0200, Johannes Merkle wrote: I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware

Re: [TLS] ban more old crap

On Thu, Jul 23, 2015 at 07:10:30PM +0200, Eric Rescorla wrote: On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: A suggestion - could we remove mention of anything that is not a MUST or SHOULD ciphersuite from the TLS1.3 document and then have someone

Re: [TLS] Does the ServerHello really need unencrypted extensions at all?

On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote: There's two issues (basically duplicates) for this topic, as well as an inline TODO. https://github.com/tlswg/tls13-spec/issues/66 https://github.com/tlswg/tls13-spec/issues/72 https://tlswg.github.io/tls13-spec/#server-hello

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote: On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: This is not really what I was intending when I suggested the feature. I was intending for their to be an indication, in the ClientHello, that the server should not do any

Re: [TLS] Negotiating with known_configuration

On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote: On 21 July 2015 at 06:08, Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: Well, if it is about supported ciphers, there could be multiple, and the proposal has slot for only one. The proposal is for what the client selects

[TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)

Let's review: draft-ietf-tls-tls13-07 This is abridged version of mail I sent earlier, but was too large for the list due to its sheer size. (Note: I omitted some stuff I saw recently discussed (e.g. pruning unused crypto algorithms) or I remember discussed. I didn't explicitly check issue list

Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote: > On 10/22/2015 01:00 PM, Salz, Rich wrote: > >> That is, the library update can be transparent to the end-user, who will > >> continue to expect normal functionality and expect everything to work. > > Should all applications suddenly

Re: [TLS] Proposal for client auth

On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote: > Folks, > > At the Seattle interim, we decided to have a small ad hoc design team > go and figure out how to harmonize the various forms of client > authentication. I've posted a WIP version of the output of that work > at: > >

Re: [TLS] Version in record MAC

On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote: > Thinking about this a little more: > > If we ever change the nonce construction to have an explicit nonce or > otherwise > not depend on the RSN (e.g., something like SIV) we're going to be sad if > we don't have the RSN in the AD.

Re: [TLS] HelloRetryRequest and stateless reject

On Wed, Oct 21, 2015 at 10:32:59AM -0700, Eric Rescorla wrote: > > It seems natural to try to merge these mechanisms, but this raises > the question of whether the handshake hashes should continue through > the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104). > The tension

Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support

On Wed, Oct 21, 2015 at 09:11:51AM +0300, Yoav Nir wrote: > LGTM. Can you push this to GitHub? > > > On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara <ilari.liusva...@welho.com> > > wrote: > > > > From: Ilari Liusvaara <ilariliusva...@welho.com> > >

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote: > This draft needs to say that Curve25519 can only be used along with > extended master secret. Alternatively we can completely remove the > cofactor and reject zero keys. X25519 and X448 specifications say zero keys MUST be rejected

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

On Wed, Nov 04, 2015 at 06:56:15AM -0500, Watson Ladd wrote: > On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara > <ilariliusva...@welho.com> wrote: > > > > X25519 and X448 specifications say zero keys MUST be rejected (and > > the functions are also internally s

[TLS] #311 (remove early_data) - Potential deadlock?

I thought of following scenario: Client: ClientHello+0RTT Server: 0RTT rejected. Fallback to 1RTT. Server: (Drains 0-RTT records) Client: Finished (corrupted in transit) Client: Appdata (request for something) Server: (Drains corrupt finished as 0-RTT record) Server: (Drains appdata as 0-RTT

[TLS] New curves work and TLS

As you might know, CFRG has been working on new curves (the document has been sent to IRSG) and is working on signatures (main issues seem to be selecting prehash for prehashed version of 448-bit signatures and KDF for 448-bit signatures). I have been thinking how to integrate this work into TLS.

[TLS] [PATCH RFC4492bis] Add EdDSA signature support

From: Ilari Liusvaara <ilariliusva...@welho.com> --- On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote: > Hi Ilari > > > - Is this document meant to also include the CFRG signatures > > work? The interfaces to functions are already known. > > That is the int

Re: [TLS] New curves work and TLS

On Sat, Oct 17, 2015 at 07:25:46PM -0400, Sean Turner wrote: > On Oct 17, 2015, at 08:30, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > > Okay, did a review of draft-ietf-tls-curve25519 (since it still > > doesn't seem to have been WGLC'd): > > Note

Re: [TLS] New curves work and TLS

On Thu, Oct 15, 2015 at 04:09:39PM +0300, Ilari Liusvaara wrote: > > Diffie-Hellman: > --- > There is already a WG draft about this. The one remaining technical > issue seems to be wheither to share the curves with signatures or > dedicate those for DH. Okay, did

Re: [TLS] I-D: CipherSuites for Kerberos + DH

On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote: > Hello, > > Thanks for the feedback. Responding to it: > > Ilari> - The signed DH share does not look to be bound to anything (crypto > Ilari> parameters negotiation, randoms, server key exchange, etc..). > > This is indeed

Re: [TLS] TRON workshop

On Mon, Oct 12, 2015 at 08:04:37AM -0700, Eric Rescorla wrote: > On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > 1) It seems to me that if server key is compromised, MITM can > > substitute 0-RTT data with its own (at

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Tue, Oct 13, 2015 at 10:12:45AM +0100, Matt Caswell wrote: > > On 30/09/15 11:06, Matt Caswell wrote: > > Hi all > > > > I have a question on how to interpret RFC 5246 with regards to the > > interleaving of app data and handshake records. > > Hello, > > Does anyone have any views on the

Re: [TLS] Fwd: Updated elliptic curve drafts

On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote: > > The following document adds new EdDSA key/signature OIDs directly: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 The certificate example seems to contain OID 1.3.101.100.1... Is that intended or should it be

Re: [TLS] DSA support in TLS 1.3.

On Tue, Sep 01, 2015 at 05:58:33PM +, Salz, Rich wrote: > There is a third option: you don't get to use TLS 1.3 until the > government requirements are updated. > > I'm fine with that. I think they already have, with NSA seemingly saying RSA3k is OK for up to TOP SECRET (unless I

Re: [TLS] '15 TLS Fall Interim Minutes

On Wed, Sep 23, 2015 at 01:43:29PM +, Dang, Quynh wrote: > I am just curious why we need the content type here? The "outer" content type is needed for backward compatiblity. The "inner" content type is needed for stuff like handshake vs. alert or appdata vs. alert. -Ilari

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

On Wed, Sep 23, 2015 at 10:33:29AM +0200, Simon Josefsson wrote: > Hi all, > > I have pushed out a new version of the document describing EdDSA public > keys, signatures and certificates for PKIX. The change in -03 include > the addition of the prehash mode, test vectors generated by GnuTLS, and

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

On Thu, Sep 24, 2015 at 04:03:28PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote: > > > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at > > all? > > Another way would to always use PureEdDSA and perform

Re: [TLS] DSA support in TLS 1.3.

On Fri, Aug 28, 2015 at 07:17:39PM +, Dang, Quynh wrote: Hi all, DSA is supported in the previous versions of TLS. It would be nice if someone who uses DSA can use it in TLS 1.3 as well. Well, at least for the web, DSA is no longer an option because major browsers have dropped support

Re: [TLS] Draft status and updates

On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC over > the handshake. As Hugo pointed out originally, this alone should > be sufficient to

Re: [TLS] Draft status and updates

On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > > > > > 3. The server provides g^y

Re: [TLS] The progress about theNegotiated FFDHE proposal

On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > Hi, > > Any one know why the negotiated FFDHE draft hang on MISSREF state for more > than 180 days? > > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Normatively depends on the false-start draft that isn't

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote: > I don't think even I agree with this idea, but I'll put it out there anyway. > > We're seeing some new secure computing modes in ARM and Intel processors. > Arm has TEE, and Intel has SGX. Both modes basically run at the same speed > as

Re: [TLS] Draft status and updates

On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: > > This clears out the big pipeline stall from PR#316, but probably has > created some bustage. Expect a series of cleanup commits and some > other things that were head-of-line blocked this week and then > draft-11 in the next week

Re: [TLS] Poly1305 vs GCM

On Thu, Dec 17, 2015 at 02:14:18PM -0500, James Cloos wrote: > Given the issues w/ gcm currently under discussion, and that poly1305 > was originally proposed to use w/ aes, should tls recommend aes-poly1305 > instead of aes-gcm for those who want to continue to use aes? > > Or does

[TLS] TLS 1.3 and OCSP stapling

When looking at stuff some more, I noticed that extension status_request_v2, which is used by OCSP stapling and is not deprecated [1]. Now, that extension uses additional handshake message type (certificate_status), which is specified to go between Certificate and SKE. Now, TLS 1.3 does not have

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Thu, Dec 31, 2015 at 06:23:08AM +, Alyssa Rowan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2015-12-31 03:30, Adam Langley wrote: > > > I don't mind if the integration of curve25519 in TLS requires a > > zero-check or not, but what property are people hoping to

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > 2. Implementations which only do new algorithms can mandate EMS and not > implement old derivation at all, provided we

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Wed, Dec 30, 2015 at 09:16:12PM -0500, Watson Ladd wrote: > On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote: > > Watson Ladd wrote: > > > > Actually, because the check for non-zero result can/should/is in the > > X25519/X448 functions

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Thu, Dec 31, 2015 at 12:55:09PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > > > On Thu, Dec 31, 2015 at 12:20 PM, Ila

Re: [TLS] Data volume limits

On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote: > I think it is a good idea to rekey AES-GCM after approximately 2^32 records, > give or take a few magnitudes. > > The question for me isn't whether AES-GCM requires frequent rekeying (it > does), but exactly how much

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote: > On 30 December 2015 at 22:16, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> Would it make sense to have session hash as a requirement in TLS > >> 1.2 when you want to use Cur

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Wed, Dec 30, 2015 at 07:23:12PM -0500, Watson Ladd wrote: > On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" <ilariliusva...@welho.com> wrote: > > > > I also think I figured out a way to truly force contributory behaviour > > without any checks: > > > >

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote: > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema > wrote: > > > For DTLS, we have to consider the packet injection threat. It is fairly > > easy to send some random bytes with a fake source to a UDP

Re: [TLS] Data volume limits

On Mon, Dec 28, 2015 at 08:51:01PM +, Blumenthal, Uri - 0553 - MITLL wrote: > When too much plaintext has been encrypted with the same key, the > key needs to be changed. When the key is changed, the change > procedure should involve new randomness.  > > What's the confusion here??? OTOH,

Re: [TLS] TLS 1.3 draft -11

On Mon, Dec 28, 2015 at 02:52:49PM -0500, Eric Rescorla wrote: > Folks, > > In the spirit of making a useful checkpoint, I just posted the latest > version of the > editor's draft as draft-11. Here's the major changes: > > > - Unify authentication modes. Add post-handshake client authentication.

Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

On Mon, Dec 28, 2015 at 06:59:48PM -0500, Eric Rescorla wrote: > On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > Also, on topic of DTLS 1.3... It occurs to me that naively doing it > > would leave it open to &quo

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

On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote: > > Are we happy that we will only be needing the PureEdDSA variants and > that no-one will be asking for the HashEdDSA versions? I ask because > I've heard it suggested (I think Karthik mentioned this) that we might > want to sign

Re: [TLS] PR#345: IANA Considerations

On Tue, Nov 17, 2015 at 07:06:52PM +, Viktor Dukhovni wrote: > On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > > > - Mark all the cipher

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

On Mon, Nov 23, 2015 at 02:20:15PM -0800, Martin Thomson wrote: > On 23 November 2015 at 14:08, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > > plus I consider interfaces that let one

Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration

On Mon, Nov 23, 2015 at 10:28:41AM -0800, Martin Thomson wrote: > >From the issue: > > I don't want to see this change to a relative time. That will mess > with our ability to create ServerConfiguration objects that live > outside of the handshake. > > I have no real objection to expanding this

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote: > > > On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote: > > > > The same concern still applies: what does it mean to allocate code > > point for the 4492bis-05 description? > > Allocating code points just means an

Re: [TLS] Fixing TLS

On Tue, Jan 12, 2016 at 02:03:53PM +, Peter Gutmann wrote: > Martin's comment reminded me of the following that I've been meaning to > post... > > In a recent discussion among some crypto folks, the topic of what TLS 1.3 > could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

On Sun, Jan 10, 2016 at 07:53:08PM -0800, Joseph Salowey wrote: > Please respond if you have concern about early code point assignment for > the curves listed in draft-ietf-tls-curve25519-01 > . Wasn't that document effectively merged to

Re: [TLS] Closing on keys used for handshake and data messages

On Sat, Jun 04, 2016 at 02:26:00AM -0400, Dave Garrett wrote: > On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote: > > Unfortunately, the TLS record framing is not easily compatible with having > > multiple keys used simultaneously: because we encrypt the content type, it > > is not

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

On Tue, Jun 14, 2016 at 11:33:11AM +0300, Yoav Nir wrote: > > > (1) +1 > One important (for me) use case for handshake messages after the > original handshake is client certificate authentication. Disclosing > that the user has just touched the magic resource that causes > certificate

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

On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > To be clear, we're being asked to trade these things off against each > other here, but there are other options which were ruled out in the > prior framing of the question

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

On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote: > > An idea for an option 4: Keep typing and keying as it currently is > (as of draft 13), but mandate a KeyUpdate immediately following > (and/or before) non-application traffic. We already have a mechanism > to use different keys in

Re: [TLS] Simpler backward compatibility rules for 0-RTT

On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson > wrote: > > > David Benjamin wrote our section on 0-RTT backward compatibility to be > > a little bit lenient about server deployment. On consideration, I

Re: [TLS] Remove EncryptedExtensions from 0-RTT

On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: > When implementing 0-RTT, an in particular the ticket_age extension, we > discovered that this greatly increases the complexity of the server > state machine. > > David Benjamin rather flippantly described a solution to this

Re: [TLS] Simpler backward compatibility rules for 0-RTT

On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > wrote: > > On 22 June 2016 at 12:01, Watson Ladd wrote: > >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > >

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

On Thu, Jun 16, 2016 at 12:13:28PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > > wasn't that rejected because it breaks boxes that do passive monitoring > > of connections? (and so expect TLS packets on specific ports, killing > > connection if

Re: [TLS] Fixing TLS

On Thu, Jan 14, 2016 at 12:14:48AM +, Peter Gutmann wrote: > Salz, Rich writes: > > >> TLS needs an LTS version that you can just push out and leave to its own > >> devices > > > >So don't you have that with TLS 1.1 and appropriate cipher and option > >choices? > > Based

Re: [TLS] Fixing TLS

On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > > > > To actually fix the known problems with TLS 1.2, you would at minimum > > need a new extension, since there is currently no way to fix the broken > > server authentication.

Re: [TLS] Fixing TLS

On Thu, Jan 14, 2016 at 12:27:07PM +0100, Martin Rex wrote: > Ilari Liusvaara wrote: > [ Charset UTF-8 unsupported, converting... ] Pfft... > > Then there's also similar problems with RSA. And then RSA PKCS #1 > > v1.5 encryption is on just about every "do not use!"

Re: [TLS] Simplifying signature algorithm negotiation

On Sat, Jan 16, 2016 at 01:10:06AM +, David Benjamin wrote: > On Fri, Jan 15, 2016 at 7:08 PM Brian Smith wrote: > > Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can > lose them. I just wrote out all 9 without thinking about it much. Apart > from

Re: [TLS] Simplifying signature algorithm negotiation

On Sat, Jan 16, 2016 at 11:01:12AM +0100, Hanno Böck wrote: > > > - rsapss_sha256 > > - rsapss_sha384 > > - rsapss_sha512 > > - ecdsa_p256_sha256 > > - ecdsa_p256_sha384 > > - ecdsa_p256_sha512 > > - ecdsa_p384_sha256 > > - ecdsa_p384_sha384 > > - ecdsa_p384_sha512 > > - ecdsa_p521_sha256 > > -

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

On Thu, Jan 28, 2016 at 05:36:22PM +, David Benjamin wrote: > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote: > > > On Tue, Jan 26, 2016 at 10:32 PM Ma

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-06.txt

On Tue, Feb 02, 2016 at 01:15:05AM +0200, Yoav Nir wrote: > Hi > > No big changes: > - Replaced the reference to the CFRG draft with RFC 7748 > - Some editorial improvements by Martin Thomson. > > So there are still a few open issues (you can see them on github: >

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

On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote: > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson > wrote: > > > > I get your point, but I don't see that as a simplification. In my > > mind, post-handshake client authentication doesn't happen. Or, I > >

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

On Fri, Jan 29, 2016 at 07:55:53PM +, David Benjamin wrote: > On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > Perhaps I misunderstood you. I read "dynamic reauth" in your message above > as the post-handshake auth mechani

Re: [TLS] Remove DH-based 0-RTT

On Wed, Feb 24, 2016 at 07:54:27AM -0800, Martin Thomson wrote: > PSK + DHE + signing Be careful with that: One can get server impersonation attacks unless one somehow binds the SS into signature (and unlike with client sigs, there is no straightforward way). -Ilari

Re: [TLS] Remove DH-based 0-RTT

On Wed, Feb 24, 2016 at 10:08:02AM -0800, Martin Thomson wrote: > On 24 February 2016 at 10:00, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > Be careful with that: One can get server impersonation attacks unless > > one somehow binds the SS into signature (and

Re: [TLS] Remove DH-based 0-RTT

On Tue, Feb 23, 2016 at 10:39:37PM -0500, Hugo Krawczyk wrote: > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett > wrote: > > ​I suggest to also define TLS 1.3-EZ. > A subset of core safe functionality that should address the majority of the > usage cases. What

Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field

On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > Hello folks, > > How this helps: In the current draft, an endpoint that sends a KeyUpdate > message and later receives a KeyUpdate message cannot know whether the > other side has actually updated its receive keys. The two messages

Re: [TLS] Simplifying signature algorithm negotiation

On Tue, Jan 19, 2016 at 06:55:49PM +, David Benjamin wrote: > On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario wrote: > > > > > Problem I am pointing out is that NamedGroup specifies not only what > > curves can be used for signing but also what curves can get signed. > > > >

Re: [TLS] Length of a variable-length vector: Could it be an odd multiple?

On Wed, Jan 20, 2016 at 06:47:12PM +, Hodges, Jeff wrote: > On 1/13/16, 12:53 PM, "Benjamin Kaduk" wrote: > >On 01/13/2016 02:44 PM, Jong-Shian Wu wrote: > >> I have a question about the even-vs-odd restrictions on the length of > >> a valid variable-length vector defined

Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ?

On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote: > Hi, > > RFC5705 section 4 "Exporter Definition" [1] states.. > >The exporter takes three input values: > >o a disambiguating label string, > >o a per-association context value provided by the application using > the

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Wed, Feb 17, 2016 at 08:49:33PM -0700, Eric Rescorla wrote: > Hi folks, > > TL;DR. > I propose that we should not change keys between the handshake > and application traffic keys. > > The general idea is that there is no strong security reason to change > change keys between handshake and

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > Regardless of whether we make this change though, I think it would be > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > generated by the handshake. During the connection lifetime, we generate > a

Re: [TLS] Simple, secure 0-RTT for the masses

On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote: > On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > - Duplication of 0-RTT data into 1-RTT data of _different_ connection. > > > > I think u

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote: > > I've been worried about this for a while now, but the recant > thread started by Kyle Nekritz [3] prompted me to send this > as I think that's likely just the tip of an iceberg. E.g., I'd > be worried about cross-protocol

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote: > > I agree with a slight tweak in wording here, Bill. I think that we > /should/ drop the parts of 0-RTT where we are not confident that an > admin who blindly enables functionality in TLS 1.3 will not end up > harming

Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

On Mon, Mar 14, 2016 at 12:32:51PM -0700, Eric Rescorla wrote: > > As far as I can tell, there's no protocol difference between "stateful" and > "stateless" resumption. > You use the same techniques (a replay cache) and the question is merely > whether the server > actually maintains one.

Re: [TLS] Simplifying signature algorithm negotiation

On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote: > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > > > I would probably characterize it less as suites vs orthogonality, but as > wanting to keep divisions in meaningful and universal places and not > splitting

Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?

On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote: > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett > wrote: > > > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > >

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

On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > I am not sure that we want to be in the business of explicitly marking > > things as insecure other than our own RFCs, though -- there could be an > > implication of

Re: [TLS] Narrowing the replay window

On Wed, Mar 30, 2016 at 08:35:31PM +1100, Martin Thomson wrote: > On 30 March 2016 at 16:15, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > Only if using 0-RTT auth, which seems is going to be removed (yay). > > My reading is that Finished is always present. That is,

Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window)

On Thu, Mar 31, 2016 at 09:57:51AM +1100, Martin Thomson wrote: > On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" <ilariliusva...@welho.com> wrote: > > Then on topic of 0-RTT, how does 0-RTT key hashes behave if > > handshake is restarted (main handshake hash contin

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Sun, Mar 20, 2016 at 06:36:09AM +, Peter Gutmann wrote: > Dave Garrett writes: > > >It would be a lot simpler, safer, and interoperable to just mandate use of > >the Extended Master Secret Extension [RFC 7627]. > > > >https://tools.ietf.org/html/rfc7627 > > Yeah,

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 10:29:06AM +0100, Karthik Bhargavan wrote: > We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with > pure PSK. > Whether or not we keep all of these, it would be good to clean up the > protocol design > so that both the client and server have a

Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

On Fri, Mar 25, 2016 at 08:33:20AM -0700, Bill Cox wrote: > Adding 1 byte EarlyDataType seems like a good idea. > > As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to > require that the cipher suite negotiated from the original 1-RTT connection > be used? TLS_PSK_* or

Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On Wed, Mar 02, 2016 at 02:08:28PM -0800, Joseph Salowey wrote: > Reserving large portions of other protocols number spaces is not a good way > to do things. This will quickly become unworkable if other protocols > decide to do the same thing. This type of behavior needs to be > discouraged.

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On Thu, Mar 03, 2016 at 09:48:00AM +1100, Martin Thomson wrote: > > [3] I actually hope that we can change DTLS 1.3 so that it won't mux > properly. That will have a size benefit that should outweigh the cost > of having to rev 5764 for 1.3. I thought about this a bit... It occurs to me that

Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

On Thu, Mar 03, 2016 at 04:44:30PM +, Salz, Rich wrote: > > > The unencrypted headers need to be kept for backward compatiblity. > > Even for a new protocol revision? Well, actually, it might be possible to compress everything except ClientHello headers. One should still avoid the 15 and 16

  1   2   3   4   5   6   7   >