[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

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

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

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

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

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

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

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

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,

[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

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

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

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

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

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

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

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

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't

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 correct g

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

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

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

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

[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

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 noticed

Re: [TLS] PSS and TLS 1.3

- Original Message - > On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote: > > > > The issue is that we cannot tell for sure. Any proof of security > > assumes that the keys are restricted to a single scheme. So I think we > > got in

Re: [TLS] PSS and TLS 1.3

On Mon, 2017-01-23 at 12:52 +0200, Ilari Liusvaara wrote: > On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2017-01-20 at 17:43 +, Dr Stephen Henson wrote: > > > > > Additionally PSS signatures (see RFC4055) can

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.

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

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

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

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

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

[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

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

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 <n...@redhat.co > m> wrote: > > > >  For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend > > the > > DTLS un-authenti

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

[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

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 <n...@redhat.com> > wrote: > > > > > Hi, > >  Up to the current draft of TLS1.3 the record layer is restricted > > to > > se

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 <nmav@redha > t.com> wrote: > > On Wed, 2016-11-23 at 00:39 -

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

[TLS] comments on draft-ietf-tls-tls13-19

Hi, In this mail I summarize my comments for draft-ietf-tls-tls13-19 (which I have read but not implemented). They include both editorial comments and content comments. Overall this is a very good document, congratulations to everyone involved. On the following text, I use the format Section:

Re: [TLS] comments on draft-ietf-tls-tls13-19

On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote: > A more general note on the section/document, is that although the > PKIX > identity (certificate) is protected from passive adversaries, the PSK > identity is not. This is a discrepancy in terms of protecting

Re: [TLS] RFC 6066 - Max fragment length negotiation

On Tue, 2017-03-21 at 14:15 +0100, Thomas Pornin wrote: > On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote: > > I'd even go so far as to specify it: > > > > https://martinthomson.github.io/tls-record-limit/ > > > > I'll submit an I-D once the blackout ends if people are interested

Re: [TLS] comments on draft-ietf-tls-tls13-19

On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > server? I assume only a single one, but it maybe good to make it > > explicit. > > This is forbidden in S 4.1.4. >

Re: [TLS] "Spec Compliance" and the older TLS protocols

On Fri, 2017-03-03 at 15:32 -0800, Bradford Wetmore wrote: > An interpretation question for our older RFCs, in particular TLSv1  > [RFC2246] and TLSv1.1 [RFC4346] in the context of recent > developments  > [SWEET32]. > > In particular, likely for minimal interoperability reasons, specific  >

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

On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla <e...@rtfm.com> wrote: > > On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> Imagine the following scenario, where the server and client have this >> repeated communi

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

On Fri, Aug 11, 2017 at 5:17 PM, Short, Todd wrote: > The application can solve this by having its own padding. If it’s going to > force all messages to be padded out to 1024 bytes by TLS, why not just make > that part of the application protocol? Its not as though it’s trying

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

Imagine the following scenario, where the server and client have this repeated communication N times per day: client server --X--> <--Y-- the client puts in X a message A of 1 byte or B of 1024 bytes, and pads it to the maximum size of TLS record. The server replies with the

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

On Fri, 2017-08-11 at 14:45 -0400, Daniel Kahn Gillmor wrote: > On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > > 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 appl

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Mon, 2017-07-10 at 13:54 +, Polk, Tim (Fed) wrote: > First, I do not see this as a “wiretapping discussion” based on my > reading of 2804, although others may disagree. >   > Second, I believe that this discussion should go forward based on > several points: > this proposal does not involve

Re: [TLS] signature algorithm ID re-use

On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > > So my question is why not go for the simpler approach and create new > > identifiers for the new signa

[TLS] signature algorithm ID re-use

Hi,  The latest TLS 1.3 draft re-uses the sha256(4), sha384(5), sha512(6) with ecdsa(3) signature algorithms IDs for the following signature algorithms: /* ECDSA algorithms */ ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), ecdsa_secp521r1_sha512(0x0603), These are

Re: [TLS] comments on draft-ietf-tls-tls13-19

On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote: > > > > As for what the TLS library I have written does if OCSP staple > > lacks > > NextUpdate, it outright causes handshake failure and fatal alert. > > So far, the preference on our end has been for a TLS library that > doesn't have to

Re: [TLS] comments on draft-ietf-tls-tls13-19

On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote: > > > On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat > .com> wrote: > > That's intentional.  > > And misguided. It violates the layering. That's a respectable opinion. I disagree.

Re: [TLS] Connection ID Draft

On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote: > Hi folks, > > I have just posted a first cut at a connection ID draft. > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 I believe the major issue with that is the fact that the record packet format changes, but there

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

On Mon, 2017-09-11 at 11:42 -0700, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed > to reflect both the capabilities of your TLS stack and the > capabilities of your PKI verifier [0]. So, yes, if you advertise this > it is supposed to work.

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

On Tue, 2017-09-12 at 14:41 +0100, Dr Stephen Henson wrote: > On 11/09/2017 19:42, Eric Rescorla wrote: > > Ugh. > > > > Generally, the idea with signature schemes is that they are > > supposed to reflect > > both the capabilities of your TLS stack and the capabilities of > > your PKI > >

Re: [TLS] Connection ID Draft

On Wed, 2017-10-18 at 06:43 +, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Nikos, > > On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" -boun...@ietf.org on behalf of n...@redhat.com> wrote: > > Another worrying feature is that th

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

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

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

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/tls1

Re: [TLS] DTLS 1.3 ACKs

On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > The one thing we ran into was the potential need to ACK in cases > where you > can't process *any* records (e.g., you receive what's actually EE, > but you > can't

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

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

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

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 > > this p

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

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

Re: [TLS] Preshared Keypairs for (D)TLS 1.2

On Thu, 2017-10-26 at 15:03 +, Tony Putman wrote: > Hi all, > > I've recently started working in the IoT space and wish to > standardize > our transport security by introducing the use of DTLS. It seems that > the > usual practice is to use PSK for mutual authentication, but I'm not > happy

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

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 >

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

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

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

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

[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

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

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

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.

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

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

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

  1   2   >