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

On Sat, 2015-07-18 at 21:22 -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 > > Th

[TLS] open issues for draft-ietf-tls-chacha20-poly1305-00

Hi, An open issue for draft-ietf-tls-chacha20-poly1305-00 raised by Eric Rescorla is that this draft doesn't use the draft-TLS 1.3 mechanism for setting the nonce per record [0]. Is there any support for switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for TLS 1.2? The altern

Re: [TLS] Call for consensus to remove anonymous DH

On Tue, 2015-09-15 at 18:00 -0700, Joseph Salowey wrote: > There has been some discussion to remove anonymous DH as described > inhttps://www.ietf.org/mail-archive/web/tls/current/msg17481.html. ; I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this

Re: [TLS] [pkix] Updated EdDSA/Ed25519 PKIX document

On Thu, 2015-09-24 at 13:23 +1000, Manger, James wrote: > The cert's notBefore field is a UTCTime value (2-digit year), while > the notAfter field is a GeneralizedTime value (4-digit year). I don't > think I has seen that before, but it is valid. Hi, Thanks for the comments, they should be addre

Re: [TLS] TLS 1.3 - Support for compression to be removed

On Thu, 2015-09-24 at 10:52 +0300, Yoav Nir wrote: > > On other lists I still see the occasional quip about suffering a > > low > > bandwidth connection. It used to be folks in some European > > countries, > > but most recently I seem to recall South American. (I think we're > > seeing the shift b

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

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 hash separtion > from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))). > The certificate signatures a

Re: [TLS] Updated EdDSA/Ed25519 PKIX document

On Thu, 2015-09-24 at 18:26 +0300, Ilari Liusvaara wrote: > 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

Re: [TLS] Design Alternatives for Kerberos + DH

- Original Message - > Hello, > 3) Similar to OpenPGP: Negotiate cert-type > > There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets. > PRO: Good integration with TLS: Tickets are transported in the > ClientCertificate, and an Authenticator is the ClientVerify. DH

Re: [TLS] Design Alternatives for Kerberos + DH

> - Original Message - >>> Hello, >>> 3) Similar to OpenPGP: Negotiate cert-type >>> >>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos >>> Tickets. >>> PRO: Good integration with TLS: Tickets are transported in the >>> ClientCertificate, and an Authenticator is the C

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote: > * I think the statement "can be implemented easily without being > vulnerable to software side-channel attacks" is too strong, unless > one wants to really litigate what "software side-channels are". > Unless I'm mistaken, as a stream c

Re: [TLS] Application data during renegotiation handshake

On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote: > I know that BoringSSL explicitly requires that application data flow > be stopped during renegotiation.  If the HTTP working group adopts > this draft, do the owners of other TLS implementations expect this to > require changes in their TLS 1

Re: [TLS] Application data during renegotiation handshake

On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote: > A question for TLS implementation owners:  During the discussion of > the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http > 2-client-certs-00, it was pointed out that HTTP/2 breaks a > simplification of the HTTP-TLS interface

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

- Original Message - > The idea of encrypting TLS record headers has come up before, the most > important purpose being to hide record lengths and boundaries and make > fingerprinting and traffic analysis harder. I had convinced myself that > goal this would be "too hard" to accomplish in

Re: [TLS] Fresh results

On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote: > On Tue, 1 Dec 2015 14:28:49 -0500 > Watson Ladd wrote: > > > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls > > 13QuicAttacks.pdf > > > > This one looks very nasty to fix. Short of disallowing the use of > > RSA > > cert

Re: [TLS] chacha/poly interop?

On Thu, 2015-12-10 at 01:02 +, Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into master.  We > pass the RFC test vectors, looking for other implementations to test > against.  Thanks. It seems to interoperate with gnutls' implementation. regards, Nikos

Re: [TLS] Data volume limits

On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > Therefore, I think we shouldn't add the rekeying mechanism as it is > unnecessary and it adds too much complexity. Any arbitrary limit for a TLS connection is almost guaranteed to cause problems in the future. We cannot predict whether 2^x

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

- Original Message - > I'm not convinced about SHA-512, but yes, they probably should use > SHA-384 at the very least. And given that the algorithm for SHA-384 and > SHA-512 is essentially the same, using just different IVs, that should > be usable for highly restricted hardware, wouldn't i

Re: [TLS] Fixing TLS

On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or > 2.0) that this WG is working on right now, why? > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). Note that

Re: [TLS] Simplifying signature algorithm negotiation

- Original Message - > Hi, > > - 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 > > - ecdsa_p521_sha384 > > - ecdsa_

Re: [TLS] [Technical Errata Reported] RFC5054 (4546)

Hi, I find the reported errata reasonable. On Sun, Jan 17, 2016 at 7:53 PM, Rick van Rein wrote: > Hello, > > Could I bring this erratum reported in November to your attention once > more? I think it calls for correction. > > Thanks, > -Rick >> RFC Errata System

Re: [TLS] ECDH_anon

On Wed, 2016-01-27 at 14:51 +1100, Martin Thomson wrote: > 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon > cipher suites. > > I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17 My understanding of DH_anon and ECDH_anon is that they were made to be used with sta

Re: [TLS] RSA-PSS in TLS 1.3

On Mon, 2016-02-29 at 09:32 -0800, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from > PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take > some hardware implementations some time to move to RSA-PSS.  After an > off list discussion with a few

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

On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > wrote: > > > FWIW: In my experience middleboxes don't ossify based on what the > > spec says, > > > they ossify based on what t

Re: [TLS] PR to clarify RSASSA-PSS requirements

On Wed, 2017-11-22 at 03:54 +, Peter Wu wrote: > Hi, > > At the moment there is still ambiguity in the requirements for PSS > with > relation to certificates. Proposal to clarify this: > https://github.com/tlswg/tls13-spec/pull/1098 > > > This PR intends to clarify the requirements for PSS s

Re: [TLS] PR to clarify RSASSA-PSS requirements

On Wed, 2017-11-22 at 12:15 +, Peter Wu wrote: > Hi Nikos, > > On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Wed, 2017-11-22 at 03:54 +, Peter Wu wrote: > > > Hi, > > > > > > At the moment there is stil

Re: [TLS] Closing on PSS. PR#1114

On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > Hi folks, > > I've put together a PR that attemps to address the PSS issue. > > See: > https://github.com/tlswg/tls13-spec/pull/1114 > > > Because there are platforms which don't have any support for PSS in > the cert validator, at all,

Re: [TLS] Closing on PSS. PR#1114

On Tue, 2017-12-05 at 12:00 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote: > > Hi folks, > > > > I've put together a PR that attemps to address the PSS issue. > > > > See: > > https://github.com/tlswg

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

On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacCárthaigh wrote: > > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. > > I think this is the wrong way to look at it. > > From wh

Re: [TLS] Multiple records in record limit (was: Secdir review)

On Mon, 2018-02-26 at 12:39 +1100, Martin Thomson wrote: > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > >PMTU governs the size of UDP datagrams, which limits the size of > records, but >does not prevent records from being smaller.

[TLS] draft-ietf-tls-tls13-24 supported_versions complexity

The TLS draft after version -21 requires TLS1.3 servers to negotiate pre-TLS1.3 versions with a new, mechanism. The document states: "If this extension is present, servers MUST ignore the ClientHello.legacy_version value and MUST use only the "supported_versions" extension to determine cl

Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity

On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote: > > I believe you are misinterpreting the text, but agree that it could > be > made more clear. > > Suppose that the ClientHello includes a supported_versions > extensions > that contains two values, TLS 1.4 and TLS 1.0, and the server >

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote: > > > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote: > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote: > > > ... > > > > we do not have a reliable mec

Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk

On Wed, 2018-04-18 at 12:25 -0400, Russ Housley wrote: > In London, I was on the agenda to talk about certificate-based > authentication with external pre-shared key (PSK). We ran out of > time, and I did not get to make the presentation. The slides are in > the proceedings; see https://datatrack

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

On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote: > All, > > This is the working group last call for the "Exported Authenticators > in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet > f-tls-exported-authenticator/. Please review the document and send > your comments to the

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > > > Do you prepend some new "magic" to the (RFC5077 or similar) > > > session > > > tickets? Or just look for a matching STEK key name and let that > > > be > > > the "magic"? >

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Wed, 2018-05-16 at 11:30 +0200, Ander Juaristi wrote: > El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > > > > > Good to know. Does any implementation other than OpenSSL support >

Re: [TLS] Universal PSKs

On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: > Hey all, > > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS > 1.3 via the external PSK mechanism, repurposing the resumption flow. > But the security proof requires PSKs be associated with a specific > hash for key s

[TLS] cost of padding removal in TLS1.3 [was: Possible timing attack on TLS 1.3 padding mechanism]

On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people

Re: [TLS] Universal PSKs

On Fri, 2018-06-15 at 14:24 +, Salz, Rich wrote: > >that's not workable. > > > It's not great, however > > >the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > TLS 1.3 is >

Re: [TLS] Universal PSKs

On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario > wrote: > > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > > Thoughts? If the WG likes this design, I would suggest: > > > > > > - Most folks who want to use TLS 1.3 with ex

Re: [TLS] Universal PSKs

On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote: > > On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > > It feels that's this is too little too late. Implementations which > > support PSKs will switch to TLS1.3 irrespective of this proposal. > > If > > t

Re: [TLS] Universal PSKs

On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > The issue with the current draft is that it leaves a single PSK with > two potential interpretations. > If the draft also changed the PSK identity value then each PSK would > have a single interpretation. > If the draft changes the ident

Re: [TLS] Broken browser behaviour with SCADA TLS

On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 07:57:41AM +, Peter Gutmann wrote: > > Ilari Liusvaara writes: > > > > > More serious problem is servers returning too small modulus due > > > lack of > > > negotiation. Which was the reason why Chrome disable

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

On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > Hi all, > > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why > one > might want to

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

On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > This is somewhat timely, as if we do want to introduce a > > restriction, > > > it > > > would ideally be in the form of some text in the TLS 1.3 > > > specification, > > > which is very nearly done. > > > > > > It would be good to

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

On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote: > > > I understand, but as I have already mentioned that argument also > > applies for RSA keys which can be used e.g., for RSA encryption > > under > > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be > > used > > with mult

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

On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote: > Ben, > > Thanks for focusing on this issue. > > Chris and I have been discussing an alternative design which we think > is more consistent with the existing structure, which we call PSK > Importers. As with your design, we have an input u

Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk

On Thu, 2018-07-26 at 15:05 -0700, Christopher Wood wrote: > The sense of the TLS@IETF102 room was that the WG should adopt > draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email > is to confirm this sense on list. If you would like for this draft to > become a WG document and you

Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk

On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: > > > > In the presentation the main driver for it seems to be quantum > > computer > > resistance as temporary measure. If that's the main argument I > > don't > > think it is really significant. PSK can hardly be used with PKI, > > and as >

Re: [TLS] The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in state "Call For Adoption By WG Issued"

On Fri, 2018-08-17 at 10:33 -0700, IETF Secretariat wrote: > The TLS WG has placed draft-moriarty-tls-oldversions-diediedie in > state > Call For Adoption By WG Issued (entered by Sean Turner) > > The document is available at > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diedi

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

On Mon, 2018-11-05 at 21:24 -0500, Viktor Dukhovni wrote: > TL;DR: Should TLS client abort DHE-RSA handshakes with a peer > certificate that *only* lists: > > X509v3 Key Usage: > Key Encipherment, Data Encipherment > > (which one might take to mean that only RSA key

Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id

On Wed, 2018-11-07 at 14:39 +0700, Joseph Salowey wrote: > This is the working group last call for the "Connection Identifiers > for DTLS 1.2" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. > Please review the document and send your comments to the list b

Re: [TLS] custom lower limit of record_size_limit

On Mon, 2019-01-21 at 16:13 +1100, Martin Thomson wrote: > On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote: > > My interpretation is that, if the client sent "record_size_limit" > > but > > didn't receive the extension from the server, that would mean the > > extension was not negotiated and the s

Re: [TLS] ticket lifetimes

On Tue, Jan 29, 2019 at 11:53 PM David Benjamin wrote: > On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar wrote: > >> > Wouldn't this issue also be mitigated by requiring the server to >> re-authenticate during resumption with the certificate once in a while? >> >> I think it's probably just easie

Re: [TLS] A flags extension

On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote: > > On 26 Mar 2019, at 9:06, Martin Thomson wrote: > > > > This needs more space for each flag. 8 bits is a pretty small > > space. If you are concerned with the size of the result, we have > > some variable-length integer encodings you could t

Re: [TLS] A flags extension

On Tue, 2019-03-26 at 10:49 +0100, Yoav Nir wrote: > > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos > > wrote: > > > > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote: > > > > On 26 Mar 2019, at 9:06, Martin Thomson > > > > wrote: > >

Re: [TLS] Distinguishing between external/resumption PSKs

On Thu, Sep 19, 2019 at 11:49 PM Nico Williams wrote: > > On Thu, Sep 19, 2019 at 04:57:17PM -0400, Richard Barnes wrote: > > I don't think anyone's asking for these cases to be differentiable on the > > wire. The question is whether the *server* can differentiate, in > > particular, the applicat

Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 2016-03-03 at 17:11 +0100, Hanno Böck wrote: > It may be worth asking the authors what's their opinion of FDH vs > > PSS > > in view of the state of the art *today*. > You may do that, but I doubt that changes much. > > I think FDH really is not an option at all here. It may very well be >

Re: [TLS] RSA-PSS in TLS 1.3

On Fri, 2016-03-04 at 13:49 +, Scott Fluhrer (sfluhrer) wrote: > Given that there probably is no long term future for RSA anyway > > > (people want ECC and postquantum is ahead) I doubt anything else > > > than > > > the primitives we already have in standards will ever be viable. > > On the co

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

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote: > > > > However, if I'm in the rough about the above, (which seems > > to me to be the case now) then my job as AD when I get a > > publication > > request that includes 0rtt, will include figuring out if that's > > safe or not. And I've no c

Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

On Sat, 2016-03-19 at 07:51 -0700, Watson Ladd wrote: > On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann > wrote: > > > > Watson Ladd writes: > > > > > > > > Then use a padding extension that solves all problems, instead of > > > relying on > > > a side effect of CBC mode. > > It's not a "side-e

[TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0

On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been > waiting for > this, I've finally got around to posting the TLS-LTS draft I > mentioned a while > back.  It's now available as: > > > http://www.ietf.org/id/draft-gutmann-tl

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

On Mon, 2016-04-25 at 08:17 -0700, Sean Turner wrote: > All, > > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that > are needed for TLS1.3.  We need to get these officially registered so > the chairs would like to hear whether there is WG support for > adopting draft-mattsson-tls-

Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

On Thu, 2016-05-05 at 12:39 -0400, Jeffrey Walton wrote: > On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell > wrote: > > > > > > Thanks all. I updated the RFC editor note to add the FIPS > > reference. > > > You might also consider mentioning the interop problems that are > going > to occur whe

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

On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need > fallback. Please not. Lets let these fallbacks die. Not every client is a browser. TLS 1.3 must be a protocol which doesn't require hacks to operate. CBC was removed, lets d

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

On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9 > f1bd4096be9393f20076 > (I cleaned up a bit when rebasing, bu

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

I'm actually surprised you mention the microsoft servers as being version negotiation tolerant. They were the most prominent examples of terminating the handshake if TLS 1.2 was offered to them (that was much time before TLS 1.2 was implemented in browsers). regards, Nikos - Original Messag

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

On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following > options you prefer by Monday June, 20, 2016  > > 1. Use the same key for handshake and application traffic (as in the > current draft-13

Re: [TLS] DTLS 1.3

- Original Message - > Hi all, > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > and you can find the result at https://github.com/tlswg/tls13-spec/pull/512 > > I have worked on a prototype implementation of DTLS 1.3 and if someone > else has something working b

Re: [TLS] DTLS 1.3

- Original Message - > On Mon, Jul 04, 2016 at 03:54:19PM -0400, Nikos Mavrogiannopoulos wrote: > > - Original Message - > > > Hi all, > > > > > > I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document > > > and you ca

Re: [TLS] DTLS 1.3

- Original Message - > On 04/07/16 20:54, Nikos Mavrogiannopoulos wrote: > > > > where id is sent by the server to the client either via an extension, or > > by simply assuming that the client will copy and keep the ID seen at the > > server packets (it doesn&#

Re: [TLS] DTLS 1.3

On Tue, 2016-07-05 at 15:24 +0100, Stephen Farrell wrote: > it doesn't contribute nor affect the security in any way). > > > Does that id need to be static? If so, then it'd act as an > > > additional way to track a user roaming over different IP and > > > ports. That'd be a pity. If such an id is

Re: [TLS] DTLS 1.3

On Thu, 2016-07-07 at 10:37 +0100, Stephen Farrell wrote: > Hiya, > > Just on this one thing... > > On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: > > > >  does not make the situation any worse > > than we have today. > I don't accept that is the corr

Re: [TLS] DTLS 1.3

On Fri, 2016-07-08 at 08:34 +, Fossati, Thomas (Nokia - GB) wrote: > Hi Nikos, Stephen, > > It seems to me that both your views (high resistance to traceability > and > low resource investment on server side) can be accommodated in a > single scheme. > Going back to the hash chain proposal tha

Re: [TLS] DTLS 1.3

On Fri, 2016-07-08 at 08:59 +, Fossati, Thomas (Nokia - GB) wrote: > > How would the hash chain matching work for a server handling > > multiple > > clients? > Sorry, I'm not sure I understand the question.  Are you asking what > happens if there is an Id collision between two separate hash ch

Re: [TLS] DTLS 1.3

On Fri, 2016-07-08 at 09:29 +, Fossati, Thomas (Nokia - GB) wrote: > > > > How would the hash chain matching work for a server handling > > > > multiple > > > > clients? > > > Sorry, I'm not sure I understand the question.  Are you asking > > > what > > > happens if there is an Id collision be

[TLS] TLS1.3 + PSK with multiple identities

Hello,  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 draft [0], and I noticed quite some deviations (IMO) from typical TLS protocol behavior. No rationale is given about them so I ask on list. To summarize, the client sends a list of identitities and the server replies with an

Re: [TLS] TLS1.3 + PSK with multiple identities

On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: > On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos > wrote: > > > > Hello, > >  I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 > > draft [0], and I not

Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA

On Mon, 2016-08-08 at 14:55 +0200, Martin Rex wrote: > > Please see the paper "Another Look at ``Provable Security''" from > > Neal > > Koblitz and Alfred Menezes. > > > > https://eprint.iacr.org/2004/152 > > > > Section 7: Conclusion > > > > "There is no need for the PSS or Katz-Wang versions

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote: > All, > > We've received a request for early IANA assignments for the 6 cipher > suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh > e-psk-aead/.  Please respond before August 23rd if you have concerns > about early code po

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

On Tue, 2016-08-30 at 14:19 -0400, Dave Garrett wrote: > I occasionally see people ask why we're calling it TLS 1.3 when so > much has changed, and I used to simply think that it was too > bikesheddy to bother changing at this point. However, now that we've > redone negotiation, we have new TLS 1.3

Re: [TLS] SHA-3 in SignatureScheme

On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote: > > > I also am not following why we need to do this now. The reason we > > defined SHA-2 in > > > a new RFC was because (a) SHA-1 was looking weak and (b) we had > > to make significant > > > changes to TLS to allow the use of SHA-2. This do

[TLS] application-specific identifier was: TLS1.3 + PSK with multiple identities

On Mon, 2016-09-19 at 14:13 -0700, Eric Rescorla wrote: > > > It is purely a matter of software architecture — the initial > > incoming > > UDP packets reach a dispatcher that needs to hand the connection > > off to > > the appropriate worker process for that client and *really* > > wants > >

[TLS] debugging tools [was: Industry Concerns about TLS 1.3]

On Fri, 2016-09-23 at 09:05 +0100, Stephen Farrell wrote: > > On 22/09/16 19:36, Yuhong Bao wrote: > > > > This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?i > > d=1188657 > > Yuk. Prioritising the needs of those debugging networks > over the maybe 5-6 orders of magnitude more f

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote: > Hi,  > > Please find the text I propose. Let me know if you have any comment > regarding the proposed text. Unless I receive comment on it, the text > will be publish as soon as draft submission is possible. > > Yours,  > Daniel > >    T

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > Regarding Niko, my understanding is that the WG preferred not to have > the definition of profiles in this document. I am not sure you wanted > the text to be removed as MUST NOT was to normative or if you would > like no recommendation at

[TLS] extending the un-authenticated DTLS header

Hi,  For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend the DTLS un-authenticated part of the DTLS record header with an additional field. That works well if this is the only draft ever extending the DTLS record header. If not, modification order would be undefined. Would it make s

Re: [TLS] extending the un-authenticated DTLS header

On Tue, 2016-11-15 at 01:10 +, Stephen Farrell wrote: > > Would it make sense to introduce an extension header for DTLS 1.3 > > in > > the lines of the IPv6 extension headers? That would allow TLS > > extension > > negotiation to add more items on the un-authenticated header, and > > potential

Re: [TLS] extending the un-authenticated DTLS header

On Tue, 2016-11-15 at 09:10 +0900, Martin Thomson wrote: > On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos m> wrote: > > > >  For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend > > the > > DTLS un-authenticated part of the DTLS record header wi

Re: [TLS] extending the un-authenticated DTLS header

On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote: > On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) > wrote: > > > > The draft proposes two ways to allocate the identifier (see 3rd > > para of > > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > > 1. Server deci

Re: [TLS] extending the un-authenticated DTLS header

On Tue, 2016-11-15 at 18:20 +0900, Martin Thomson wrote: > On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos m> wrote: > > > > > > > > I'm not seeing quite enough information here to implement > > > this.  How > > > does a serv

[TLS] record layer limits of TLS1.3

Hi,  Up to the current draft of TLS1.3 the record layer is restricted to sending 2^14 or less. Is the 2^14 number something we want to preserve? 16kb used to be a lot, but today if one wants to do fast data transfers most likely he would prefer to use larger blocks. Given that the length field allo

Re: [TLS] record layer limits of TLS1.3

On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > wrote: > > > > > Hi, > >  Up to the current draft of TLS1.3 the record layer is restricted > > to > > sending 2^14 or less. Is the

Re: [TLS] record layer limits of TLS1.3

On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > Can you send multiple records in one data transfer to achieve > whatever gains are desired?  The packetization cost still remains even if you do that. However, the question is how does the 2^14 limit comes from, and why TLS 1.3 should keep

Re: [TLS] record layer limits of TLS1.3

record > sizes, but is that something we want to rely on?  This could be a > parameter agreed upon during the handshake, but that seems bad. > > > On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos t.com> wrote: > > On Wed, 2016-11-23 at 00:39 -0800, Judson Wi

Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

On Sun, 2016-11-27 at 15:13 +, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS.  I will submit a draft > > as soon > > as I have a wo

Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote: > > Given that certificates usually take up most of the bytes exchanged > > during a > > full handshake it seems this could be useful, but I don't know if > > in > > practice the benefits are worth the added complexity. Thoughts? > > Decompre

Re: [TLS] [Technical Errata Reported] RFC7919 (4908)

On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote: > Original Text > - >    If a compatible TLS server receives a Supported Groups extension > from >    a client that includes any FFDHE group (i.e., any codepoint > between >    256 and 511, inclusive, even if unknown to the se

Re: [TLS] PSS and TLS 1.3

On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote: > Additionally PSS signatures (see RFC4055) can be used with RSA keys > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does > the RSASSA-PSS mean that both types must be accepted? That's a quite interesting finding. Altho

  1   2   >