[TLS] I-D: CipherSuites for Kerberos + DH
Hello TLS WG, I would like to propose new CipherSuites for TLS. The cryptography is founded on Kerberos authentication and DH encryption, cryptographically bound together. The mechanism uses mutual authentication, although clients may use anonymous tickets. Any feedback that you may have (technical, or WG-procedural) is kindly welcomed. I will also send this to the Kitten WG. Thanks, Rick van Rein > *From:* internet-dra...@ietf.org > *Date:* 1 October 2015 18:54 > *To:* "Rick van Rein" , "Rick van Rein" > > *Subject:* New Version Notification for draft-vanrein-tls-kdh-00.txt > A new version of I-D, draft-vanrein-tls-kdh-00.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-tls-kdh > Revision: 00 > Title:TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date:2015-10-01 > Group:Individual Submission > Pages:26 > URL: > https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-00.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-00 > > > Abstract: >This specification extends TLS with a Kerberos-based method of mutual >authentication, and binds in Diffie-Hellman to achieve Perfect >Forward Secrecy for the session. > The IETF Secretariat > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
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 easy to miss; it relies on Kerberos infra to deliver a short-lived session key to only the proper TLS client and TLS server. The ticket is part of this key delivery, and can travel over untrusted networks. An Authenticator is built especially for each connection, and encrypted with the session key by the TLS client. The only other that can decrypt it is the TLS server. With the client DH key only known to TLS client and TLS server, only they can construct the DH shared secret. What remains is MITM on the server side. This is detected when the Finished messages are off (these have more bytes for TLS-KDH). A alternative option to fighting MITM could be to include (a hash of) the server-sent DH offer in the Authenticator. Only the Kerberos- authenticated TLS server can decrypt it, making it detect MITM. Is that considered benefial? Ilari> I can't Ilari> offhand say what that would lead to, but it looks even worse than Ilari> TLS ServerKeyExchange, which has known vulernabilities due to Ilari> lack of binding to things like ciphersuite. Have I taken away these concerns? Pointers to the known vulnerabilities are welcome, of course. I'm not sure what you would like to bind to CipherSuites. Watson> I would suggest piggybacking on the PSK mode, using the key Kerberos Watson> provides at both ends as the PSK key. This would address all of these Watson> issues in TLS 1.3 You mean to add the short-lived session key to the pre-master secret, right? I have a (weak) preference to leave that key behind the API to help it being better protected. Also, I don't think it adds much to the security explained above. It might be an idea to add protected fields from the Authenticator though, such as the usec timestamp, seq-number, client name@realm. Ilari> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC Ilari> (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2]. Yes, this is a naive/initial list, I knew I would need to interact here to get it pruned. Thanks, your suggestions will be taken care of! Ilari> - Even use of DH is questionable. This is mod-exp DH, on account of its need for very large keys, right? I would love to take it out, and only leave ECDH; I put up mod-exp DH initially because it might be desired for backward compatibility. If I hear no warm-felt desire for mod-exp DH I will gladly remove it. Thanks! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
Hello Ilara / Watson / TLS WG, Thanks again, If I was to do things like the current proposal (as opposed to overloading DHE-PSK), I would put in hash of entiere client and server first flights. Now I see what you mean. Indeed, the master secret used in Finished does not take it into account in TLS 1.2, except under RFC 7627. > > > The SKE security issue (SKE isn't bound to the ciphersuite) has surfaced > at least three times: > > 1) The DHE/ECDHE confusion. > 2) FREAK > 3) Logjam Thanks, those are very good reasons indeed :) >> Watson> I would suggest piggybacking on the PSK mode, using the key >> Kerberos >> Watson> provides at both ends as the PSK key. This would address all of >> these >> Watson> issues in TLS 1.3 > I think he means stuffing the key from kerberos as PSK input in > (EC)DHE-PSK ciphersuite. That is not going to work for this. PSK communicates untyped blobs, which makes the server take a leap of faith, and so it is pretty much limited to internal use. I'm working on getting Kerberos to crossover between realms, and TLS-KDH might become the killer app for that. The key-handling approach of PSK got me thinking though (pre-master = DH-shared-secret + preshared-key). It is a strikingly simple method to make (EC)DH orthogonal to the authentication exchange. It means all the DH-specifics can go... perhaps 75% of my text! >> Ilari> - Even use of DH is questionable. >> >> This is mod-exp DH, on account of its need for very large keys, right? >> >> I would love to take it out, and only leave ECDH; I put up mod-exp DH >> initially because it might be desired for backward compatibility. If >> I hear no warm-felt desire for mod-exp DH I will gladly remove it. > > Backward compatiblity? I don't think you need such thing with proposal > like this. I am now preparing a new form, with ClientCertificate := krbTicket and CertificateVerify := krbAuthenticator. That seems to integrate really well with the rest of TLS, also for 1.3. * the Authenticator hashes all prior messages and stores them in "checksum", leading to the requested binding * the CertificateRequest can ask for various forms of authentication, even mixing Kerberos and X.509 * there will be Kerberos-only CipherSuites (mutual exclusion, so this authenticates the server) but it can also work with TLS_ECDHE_RSA_ et al * the TicketRequirementFlags will be a TLS Extension during ClientHello / ServerHello Rather different -- so a new text is coming up. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: CipherSuites for Kerberos + DH
Hello Benjamin, > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason not to go > full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges and TLS cannot carry that. An attempt for SASL-in-TLS was made in draft-williams-tls-app-sasl-opt, but it ends up piggybacking on TLS but continue afterwards -- loosing the cryptographic binding between auth from Kerberos with PFS from (EC)DH. > This proposal (as complicated as it is, and I'm not sure that I'm > entirely comfortable with it yet) has the comparative advantage that the > application speaks TLS from the start, with the Kerberos messages > included in the TLS CKE. In that sense, at least, it is elegant. Thanks. The proposed changes greatly simplify the spec, making all DH orthogonal to the spec. Watson convinced me and now I can pull a lot from the I-D, which is also more complex than I like. > This proposal also includes a generic mechanism for the server to > indicate what service type and hostname should be used in constructing > the host-based service principal name for Kerberos, which is useful -- > the convention for that would otherwise have to be baked into the > application protocol. > Actually, I did not specify such a mechanism. * Client and server assume that the application context knows what protocol it is using. AFAIK that always makes sense -- on top of TLS we're running something like imap, and imap knows that its tickets start with "imap/". * The hostname is known to the client too, it is usually included in the SNI extension, looked up in DNS, ... * However, the realm is "supposed to be derived independently" which can be done with the DNSSEC-assured _kerberos TXT that we discussed on Kitten. > The considerations around client anonymity and a > protocol for the server to convey its expectations are also interesting, > though I'm not sure I would have put it in the -00 if it was my own > document. OK :) but this was simpler than the loose end in predecessors -- sending no ticket and deciding how the server would respond to that. But it is a new idea, to have authenticated clients with unknown identities... > There are some nits in the Kerberos bits that I might mention over on > kitten. Great, thanks! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Design Alternatives for Kerberos + DH
Hello, Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and Kerberos orthogonal. That simplifies matters enormously. I can now see a few design alternatives. If you have any response to them, it is kindly appreciated! 1) Continue to use KeyExchange This variation sends a Ticket + Authenticator in the ClientKeyExchange, but DH is now mentioned in plaintext instead of encrypted in the Authenticator. PRO: Prior handshake can be taken into account in an Authenticator hash (a.k.a. "checksum"). CON: Special case for KeyExchange; doesn't integrate automatically with TLS 1.3. 2) Embed the Ticket + Authenticator in a PSK This uses the binary blurb of the PSK to wrap the Ticket and Authenticator. PRO: Client authenticates very early, in the ClientHello. CON: PSK is untyped, so it requires separate agreement on the contents. It is impossible to incorporate ServerHello information in the exchange. The server has not indicated if it supports Kerberos, so the client must make a leap of faith. PSK replies the selected PSK identifier, rather than send a response message; it is not designed for messaging purposes. 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 is independent and can move to the earlier phase for TLS 1.3. CON: Decision on client credential type must be made in ClientHello, when not all data may be available (namely, the sequence of tickets leading to the TLS-protected service). Also impacts the cert-type used in the ServerCert. 4) Define an X.509 embedding for Tickets Certificates provide an id/key binding with a signature by a trusted party; although the AlgorithmIdentifiers used here are new, they do fit in the X.509 framework. This is rather out-of-the-box thinking, so I tested the idea, see https://github.com/arpa2/kerberos2pkix PRO: Minimal changes to TLS, since Kerberos is now a signing algorithm. The server can independently authenticate using RSA & co (on top of Kerberos' mutual authentication). Ticket + timestamp-Authenticator go into an X.509 ClientCertificate, and an Authenticator including the hash over prior TLS messages can go into ClientVerify. CertificateRequest can mix options for Kerberos, RSA, and so on, and client selects whatever it can get to locally, giving the best user experience. We can also support user-to-user connections and S4U2Proxy a.k.a. "Constrained Delegation". CON: These certificates are symmetrically keyed, which is uncommon. Certificates are not readable to anyone, but only to the remote peer. Certificate owner is ideally read from the embedded ticket, rather than from the subject field. My money is on the last two, but option 4. really needs feedback because it is a bit wild. When I get an idea where to go, I will be happy to write a new draft version... a much smaller and simpler one this time! Cheers, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Design Alternatives for Kerberos + DH
Hello Paul, >> 3) Similar to OpenPGP: Negotiate cert-type >> >> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos >> Tickets. > > How is this type of TLS connection prevented from being MITM'ed by > someone replaying kerberos tickets (which it cannot read itself) In Kerberos, the KDC-generated and client-cached Tickets are always sent with an additional Authenticator; this is client-signed message that is generated while sending and holds a timestamp to the ms level. The combination is rejected when the timestamp is more off than a small clock skew window at the server. Replay is avoided in Kerberos by observing the Authenticator's uniqueness within that small window. This however, has scaling problems, for instance in redundant server farms. An Authenticator can hold a "checksum", which is a hash nowadays. We can use this field to store a hash of the prior TLS messages, including the ECDH exchange and ServerRandom. This is already done by default in the ClientVerify, so nothing special needs to be done for that. The hashes are typed, with an IANA registry; unkeyed hashes are possible, though none beyond SHA1 appears to have been needed for its current uses, but we can expand that. Finally, the pre-master secret for all four design alternatives consists of the ECDH session key and the session key exchanged by the Ticket. Replay of ECDH is impossible if the server continually refreshes its offers, at least not to be repeated within the clock skew window, which has been a major focus point in my 00 draft. Lacking the session key, an attacker that attempts replay of a Ticket will not be able to generate the proper Finished messages. FWIW, I am proposing to extend the sizes of those hashes. Thanks, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Design Alternatives for Kerberos + DH
Hello, >> What messages do you need to transfer for Kerberos? Is it only a ping-pong? Yes, the plan is to send a Ticket + Authenticator and since the server cannot send "pong", to use the (elongated) "Finished" message to replace the validating function of the "pong". > The client (or server, or both) can pick > a subsession key encrypted by the session key in the Ticket, Currently, only the client could do this. We might pile the subsession key into the pre-master secret if we decide that it adds to security. If we really want the server to send one too, it might send a random string of the right size, and it could be decrypted to a key. That's possible with symmetric algorithms after all... and after receiving the Ticket, the server can do the same to discover its secret subsession key :) > if > another message is passed that uses a subsession key for > confidentiality/integrity (such as a response from the server to perform > "mutual" (i.e., server) authentication, then there is less need for a > replay cache. The key idea in 00 was to not use a subsession key but instead rely on Diffie-Hellman for the same function, to avoid replay caches. Because a replay cache would be a devastating part of a TLS infrastructure that could block these CipherSuites from being rolled out. > An additional key-confirmation message to validate the > server-selected subsession key (such as actual application traffic being > encrypted in that key) is helpful for the security analysis, but not > always available depending on the constraints of the application protocol. It still surprises me, but Kerberos is able to send a message one-way and achieve mutual authentication. The trick is of course that prior key exchanges have setup links that make this possible. That's already been taken care of in client apps and libraries, so I'm trying to make good use of it in TLS. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Design Alternatives for Kerberos + DH
Hi Karthikeyan, > I don’t fully understand the constraints of the Kerberos+DH use-case, but > using DHE-PSK seems like the best idea. It certainly has some virtue to view Kerberos as a preshared key (on steroids). But let me explain what bothers me about that appraoch :- * PSK was designed to carry "hints", not "wrapped-up keys". It feels like we'd not be using it entirely properly. * To avoid replay without (distributed) replay-protection caches, we need a ping-pong exchange. PSK sends back a literal copy of what it got sent, which means that we cannot send back a cryptographic reply. Normally, we would do just that in the Kerberos Application Protocol. When we have an Authenticator in a separate ClientVerify message, it automatically ranges over all past TLS messages, incorporating DH, server random and the Ticket that is being proposed. With the PSK approach, it all gets stuffed into one TLS message and we'll be defining things that are not in line with generic structures for TLS. * PSK carries untyped information. This means that a client and server need out-of-band agreement on the meaning of the PSK format. And we probably agree that educated guesses based on magic numbers are not good for a security protocol. This means that use of PSK is limited to pre-arranged client/server combinations. Meanwhile, Kerberos is hoping to expand to make clients and services authenticate even when they have never met before. > The planned session resumption mechanism for TLS 1.3 also uses DHE-PSK, and > uses a session ticket mechanism > that is not so far from the Kerberos ticket. The Kerberos session key would > then get mixed in (as a semi-static secret) > to the ECDHE shared secret and both client and server would obtain mutual > authentication (based on the Kerberos key). Yes, that is nice and orthogonal. However, we do need the entropy of ECDHE and server random to be mixed in with the Authenticator to make replay undoable. The best way to do that orthogonally is to rely on a hash of prior exchanges, which is not possible, at least under 1.2, with structures that mix Diffie-Hellman and PSK fields. Combined with this being a variation of PSK, I would expect it to lead to more exceptional code than what is being proposed as 3) and 4) -- and exceptional code often is badly-tested code. > It may be best to try and fit Kerberos into this existing mechanism, unless > there is some fundamental incompatibility. I follow the same line of thought, but think integration with the ClientCertificate / ClientVerify is more natural. Tickets are not just keys, they also carry identity, and bind them together. Once again, the reasoning is that this directs the questions to a TLS stack to the right place, without a need to bypass it to elsewhere for this one usecase. Thanks! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Design Alternatives for Kerberos + DH
Hello Benjamin / TLS WG, I didn't mean to drop the list, so your full response is hereby included. >>> No, mutual authentication requires the client to receive a message from >>> the server. >> Yes, I know -- the server needs to handle the session key or the subkey >> to prove posession of its KDC-stored service key. By using it, the client >> can be convinced or server identity. > > Good to hear. Other readers, perhaps, did not. >>> This could be implicit >> I think it automatically is with TLS, since the Finished messages won't >> succeed until both parties have derived the same master secret, which >> if it involves the session key or subkey proves the server's identity in an >> implicit manner. > > From just your short descriptions, it was unclear to me what exactly > went into the master secret from the Kerberos side, so I wanted to be sure. Yes, balancing with terseness. The master secret is calculated as always, incorporating the pre-master secret as well as client/server random and, under RFC 7627, all of the handshake messages up to and including ClientKeyExchange. The pre-master is the combination of the ECDH shared secret and the session key(s) from Kerberos. For the latter, we can choose one or more from: * The session key generated by the KDC for this client/server combination session (lasting as long as the service ticket, usually about a day) * A subkey inserted into the Authenticator by the client for this particular connection (which can avoid replay during ticket life) * Possibly: a random byte string from the server, "decrypted" with the session key, to form a connection-specific key that hinges on server-side entropy I think my preference would be a combination of 2nd and 3rd because that incorporates entropy from both sides; although entropy from both sides is also incorporated through the ClientHello and ServerHello Random bytes, these are not encrypted to conceal it from MITM as in the 2nd and 3rd options. This is a bit paranoid perhaps --the ECDH mechanism achieves a similar thing already-- but the appeal of 2nd and 3rd as very light-weight and makes it much more difficult to crack. >> I do believe a long-enough Finished message is required though. For >> the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth >> to match the required certainty from the message; if we mix Kerberos >> client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then >> a client SHOULD negotiate a high-enough value and the server MUST >> support that. It requires TLS 1.2 to do these things. >> > > Well, hmm, that's an interesting question. (Note, of course, that the > current Kerberos AES enctypes only use 96 bits of HMAC-SHA1 for their > MIC.) Keyed hashes such as HMAC-SHA1 don't seem to add much here, and they would have a grave impact on how the hashes are calculated in TLS stacks (because the key is only known later in the exchange). I would suggest that we follow TLS' hash preferences, since we are going to rely on those hashes having been computed through the prior exchange of TLS messages, and add those to the IANA Registry for Kerberos Checksum Type Numbers; this currently includes SHA1 and I doubt that anyone would protest to extensions with stronger unkeyed hashes. > The client can obtain information indicating that the server has > the correct Kerberos key both from the decrypted contents of the > Finished message I assume you meant "by matching the Finished message with one generated locally". > and also from the integrity protection of the > TLSCiphertext, since both use material derived from the master secret. Yes, TLSCiphertext is also protected, but my main concern is with Finished, because I would not like accept a TLS connection under doubtful circumstances, just to be OK when an application only sets up TLS as a means of authentication. With the longer Finished messages, that would not happen. > So I guess I'm not yet convinced that the verify_data_length should be > twice the bitlength of the negotiated symmetric cipher, but perhaps I'm > missing something obvious. I'm not sure if it should be 1x or 2x the cipher length. Most important to me is that it must be longer than the 12 bytes that were standard up to TLS 1.1 and default in TLS 1.2. -RIck ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Design Alternatives for Kerberos + DH
Hello Benjamin, > No, mutual authentication requires the client to receive a message from > the server. Yes, I know -- the server needs to handle the session key or the subkey to prove posession of its KDC-stored service key. By using it, the client can be convinced or server identity. > This could be implicit I think it automatically is with TLS, since the Finished messages won't succeed until both parties have derived the same master secret, which if it involves the session key or subkey proves the server's identity in an implicit manner. I do believe a long-enough Finished message is required though. For the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth to match the required certainty from the message; if we mix Kerberos client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then a client SHOULD negotiate a high-enough value and the server MUST support that. It requires TLS 1.2 to do these things. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC5054 (4546)
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 <mailto:rfc-edi...@rfc-editor.org> > 30 November 2015 at 17:02 > The following errata report has been submitted for RFC5054, > "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546 > > ---------- > Type: Technical > Reported by: Rick van Rein > > Section: 2.6 > > Original Text > - > B = k*v + g^b % N > > Corrected Text > -- > B = ( k*v + g^b ) % N > > Notes > - > The customary binding is that + has lower priority than % and so the > default reading of the expression would be > B = k*v + ( g^b % N ) > That is inconsistent with the existence of PAD(B) and the size of B in > the test vectors, so the context hints at proper brackets, but this > may still lead to implementation errors (of which I actually ran into > an example). > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -- > RFC5054 (draft-ietf-tls-srp-14) > -- > Title : Using the Secure Remote Password (SRP) Protocol for TLS > Authentication > Publication Date : November 2007 > Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin > Category : INFORMATIONAL > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SRP ?
Hi, > Is anyone using SRP with TLS? The OpenSSL implementation in particular? > We're considering it too, although not necessarily through OpenSSL. Also I'd really prefer an ECDH-based formalism; I'm note sure if work on that is being done, or where. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SRP ?
Hi, > Although the lack of modern cipher-suites for SRP makes it not very > attractive these days. > Does anyone know if work on something like "ECSRP" is going on, anywhere? We've recently worked on getting it working with PKCS #11, https://github.com/arpa2/srp-pkcs11 https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf It could be interesting to see if this translates to the Elliptic Curve arena. I heard rumours of alternatives being weighed against one another, but failed to find anything concrete. Links are quite welcome! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SRP ?
Hello, g/html/draft-ietf-tls-pwd- >> The real >> problem here is that there is no reason not to use certificates in a >> lot of cases. > > when TLS > is used to protect non-browser traffic there are plenty of cases > where you won't have an implicit trust anchor database or you're > going to some server administered by someone who most likely only > has a self-signed cert +1 -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DTLS/SCTP and fragmentation
Hello, I was looking into DTLS/SCTP as a carrier for Diameter. Lengths in Diameter are 24 bit to avoid ever having to bother about that, but when run over the preferred DTLS/SCTP carrier this may yet be a concern, so that its only option is to fallback to a _separate_ TLS/TCP connection: * For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there is no PMTU limitation. However, the upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes. SCTP can offer better guarantees than UDP; this relaxation may provide leverage to split a large application message into a sequence of DTLS frames carried under specific guarantees. 1. To handle a larger application message, it is split into pieces of 2^14 bytes, followed by one that has <2^14 (possibly 0) bytes. Fragments are sent to the same stream, without interleaving other content, and in-order. Upon reception, the DTLS frames are each decoded and the result concatenated to recover the message. 2. Since delivery is reliable for SCTP, it would (also) be possible to send the same sequence number for the fragments. The sequence number field is not as useful for SCTP as it is for UDP. 3. It may be an idea to allocate one stream for all fragmentation. But even within a stream, it is possible to combine in-order and out-of-order. It is probably good to continue in-order sending until the <2^14 sized DTLS frame is acknowledged. The application or DTLS handshake may further constrain this. These are three possible ways of relaxing this. If we pick a simple one, like the 1st, we might pass more SCTP semantics over to the application that wants DTLS but not its size constraints. What DTLS does to Diameter is best resolved. I hope this is useful, Cheers, Rick van Rein ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
Hi, Larger frames than the MTU are not just a problem to Diameter; they also complicate the normal handshake in DTLS which is a bit of a misfit with DTLS delivery semantics. Since the version is bit-swapped in DTLS, each record can easily be distinguished as being either DTLS or TLS. Then, why not allow the mixing of those records in a stream, and map them differently to the transport protocol? I suppose the records could be marked as being the first and/or last in a large user message, and this could be meaningfully translated to properties and behaviour of the transport. Below the DTLS MTU, information is sent as DTLS, and above it, it is sent as a sequence of TLS frames -- or are rejected, if the transport cannot handle that. Plain TLS could be a special case where the DTLS MTU is set to 0. Datagrams may have a number of meanings, too, that translate to different transport meanings. Diameter differs from RTP in that it wants reliable delivery (which is why it does not carry over UDP) but it is like RTP in that it does not want ordered delivery. Plain TLS applications would present the usecase of reliable ordered delivery. Hopefully helpful, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
Hello Michael, Thank you! I was searching for options, things that should go into DTLS, but I was unaware of the attempts of mapping it better to SCTP. > What about using: > https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01 This looks very good, thank you for the pointer! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
Hello, We have prepared the following draft, and request feedback on it. The main points are * Introduction of (anonymous) Kerberos tickets as added entropy to mix with ECDH, and thereby provide Quantum Relief; it generalises this idea to allow for other ways of adding entropy * Introduction of Kerberos Tickets for Certificate and CertificateVerify messages * User identity on the server side; how TLS can be relayed to a peer, which Kerberos can handle with its user-to-user authentication mechanism; it generalises this idea, and perhaps it might be better as a separate TLS Extension under ClientHello encryption. * Everything applies to TLS 1.3 as well as 1.2. Our intention is to launch this as an independent proposal. Your insights are highly appreciated! Best, Rick van Rein Tom Vrancken A new version of I-D, draft-vanrein-tls-kdh-06.txt has been successfully submitted by Rick van Rein and posted to the IETF repository. Name: draft-vanrein-tls-kdh Revision: 06 Title: Quantum Relief with TLS and Kerberos Document date: 2020-01-22 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-06.txt Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanrein-tls-kdh Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-kdh-06 Abstract: This specification describes a mechanism to use Kerberos authentication within the TLS protocol. This gives users of TLS a strong alternative to classic PKI-based authentication, and at the same introduces a way to insert entropy into TLS' key schedule such that the resulting protocol becomes resistant against attacks from quantum computers. We call this Quantum Relief, and specify it as part of a more general framework to make it easier for other technologies to achieve similar benefits. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
Hi Rich, Salz, Rich wrote: > * Introduction of (anonymous) Kerberos tickets as added entropy to mix > with ECDH, and thereby provide Quantum Relief; it generalises this idea > to allow for other ways of adding entropy > > Have you seen > https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/ ? I hadn't. Are you suggesting to insert the session key, or anything derived from it, into this CPRNG-alternative mechanism? The spec speaks of ways of communicating entropy, not necessarily having them available on two ends yet. That's a mild generalistion over the idea of passing a Kerberos ticket, which is essentially the pupose of this proposal. I am however listening here if the generalisation is useful. (I do have a few immature ideas that could use it.) -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D: TLS += Kerberos (provides Quantum Relief for DH)
Hello Nico, > I don't believe that using Kerberos helps on the _entropy_ side as much > as on the PQ side. Ah; I meant to (be terse and) say that it adds an independent source of entropy that leaves no traces in the TLS flow subject to, indeed, Quantum Computer cracking. > Now, the biggest problem with Kerberos is that with manually-keyed > cross-realm trusts doesn't scale to Internet scale. But there's a way > to fix that too: use PQ PK with PKINIT as a form of "PKCROSS", and now > Kerberos can function as a way of amortizing PQ PK costs. Indeed :- though I'd have mentioned KXOVER or Kerberos Realm Crossover, https://gitlab.com/arpa2/kxover This is founded on DNSSEC, DANE and TLS. Thanks, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Kerberos + ECDHE in TLS (v02)
Hello, I revised my TLS-KDH draft to include comments from this group. Thanks! The changes can be summarised as: * Integration with "normal" X.509 certificates; client may use krb5 certificate * Kerberos Ticket as X.509 pubkeyinfo; Authenticator as signature mechanism * Define TLS-standardised hashes as ChecksumTypes for use in an Authenticator * Moved TicketRequestFlags to a TLS Extension; negotiation with min/max flags * Taken out protocol-bound DH; this saves about 75% of the complexity * Pre-master secret now incorporates Kerberos session key and DH shared secret * Added descriptions of how to support backend servers in Ticket AuthData I am aware that embedding Kerberos in an X.509 certificate is uncommon; but it simplifies the rest incredibly, and suddenly everything "clicks" smoothly into the rest of TLS. I therefore think this form of "tunneling" certifying information is worth considering. Is this something that could be discussed at IETF 95? Cheers, -Rick > A new version of I-D, draft-vanrein-tls-kdh-02.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-tls-kdh > Revision: 02 > Title:TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date:2016-03-11 > Group:Individual Submission > Pages:23 > URL: > https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-02.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-kdh-02 > > Abstract: >This specification defines a TLS message flow with Kerberos-based >(mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to >achieve Forward Secrecy for the session. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New Draft: Symmetric TLS
Hello, I wrote a straightforward I-D to permit Symmetric TLS, by which I mean letting go of predefined client/server roles. This is useful if the layers on top and/or below TLS are neutral in this respect. The approach is through a TLS Extension that holds a tie-breaker; both ends send a ClientHello containing such a random value. > Name: draft-vanrein-tls-symmetry > Revision: 01 > Title:Symmetry for Transport Layer Security > Document date:2016-03-11 > Group:Individual Submission > Pages:11 > URL: > https://www.ietf.org/internet-drafts/draft-vanrein-tls-symmetry-01.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-symmetry/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-symmetry-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-symmetry-01 > > Abstract: >TLS connections can be run over various transports, and can in turn >carry many application protocols. All current transports and at >least some application protocols are capable of running between >symmetric end points, in what could be called peer-to-peer mode, but >the use of TLS introduces a requirement to always assign a client and >server role. This specification defines a TLS Extension to remedy >that stringency of TLS. Cheers, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
Hello, > In Yokohama, we discussed changing the IANA registry assignment rules > for cipher suites Has a similar thing been discussed for TLS Extensions as well? That list now requires "IETF Consensus", and it doesn't even have Private and Experimental allocations, let alone a portion with "Specification Required". It can be difficult to get enough traction on this busy list for an extension that is only useful in a niche (which could be said of my draft-vanrein-tls-symmetry that gained no response at all) that is however very interesting in such a niche. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
Hi, In general I think this is a good form of relaxation. However, > > Cipher suites marked with a “Y” the IETF has consensus on An alternative could be to mark the entry with the RFC 5226 level of the documentation, and indicate what levels are acceptable. A black/white distinction will probably lead to a lot of discussion, and different implementation purposes could call for more subtlety. > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. This is a vague one, and may unleash more discussion than it saves. Also, this should not turn into a suggestion of using implementations rather than specifications as leading. I've seen a lot of that around Kerberos, where sane changes can get bogged down because there is (or may be) an implementation that couldn't live with it. > > Please indicate whether or not you could support this plan. > Yes, in broad lines, but I have the noted concerns / suggestions. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
Hi, > I am just a little bit worried that everything developed for the IoT > enviroment is quite likely labled as not recommended by the IETF in this > registry because of the Web focus in this group. > RFC 5246 speaks of "Application Profiles" and it seems like this discussion that started to simplify the WG load is now getting mixed with that idea: In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). The worry about IoT above makes me suspect there might be a use for an IoT application profile, presumably geared towards simplicity and compactness. Such a profile could make its own choices, possibly as a subset from the Y markers and possibly enhanced with industry-driven desires. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Asymmetric TLS
Hello Phil, > I have a use-case for allowing an MITM to monitor traffic, but not > impersonate a server, and to allow MITM signing for replay of > server-responses to support caching. > This sounds like attack monitoring (going beyond DoS for which SNI frequencies might already be helpful). This used to be possible by passing certificate private keys, until we all embraced (EC)DHE. This is still an option for you of course, since you're violating the idea of (EC)DHE anyway, at least between the monitor and its related TLS peer. > As far as I'm aware, TLS currently only supports a shared-secret once > session initialisation is complete, so I'd need to extend the protocol to > support asymmetric encryption for the session. > I wonder if you'd need to extend the *protocol* or rather its *implementation* to share private/secret key material. You could probably create a side-channel over which you communicate this efficienctly, based on the random pieces in Hello, for instance. Any such implementation would sound the alarm bells for this option (and probably not make it a default option) that the TLS protocol can't ring because it is just a protocol. My suggestion would be to let the monitor supply the private/secret key material its related TLS peer, so it has more control; also, for TLS implementations the import of key material is perhaps less scary than the export (or more possible, if PKCS #11 is used). Your monitor might decide to let go of monitoring traffic, to monitor other traffic and perhaps to share key material between certain sessions when under attack. Be careful with all of this though! > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? > Clearly, the WG does not like this idea. Same with me. But if you tried something implementation-specific, or perhaps even standardise an explicit side-channel protocol, you may be more likely to get the work done because that would constitute an explicit and independent choice on the part of the administrators. TLS is so full of options that the eyes of admins already glaze over -- what you are proposing is explicit weakening of TLS, and it could slip into a configuration too easily as part of the confusion that the complexity of the protocol already causes. It could be interesting to let the WG know what your course of action will be, so we can positively reference any such requests in the future. Cheers, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC5288 (4694)
Hi, > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number > used once", and secondly nonce re-use in AES-GCM doesn't just result in > "catastrophic failure of it's authenticity", it results in catastrophic > failure of the entire mode, both confidentiality and integrity/authenticity. I'd like to add that I don't see a difference between a "failure" and a "catastrophic failure". It's probably better to stay away from subjective words like that. -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
