Re: [TLS] Forward secrecy with resumption, and 0-RTT security
On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could > be used to decrypt the prior sessions. Using tickets did not work either, > because the server always kept a ticket decryption key which could be used > to decrypt all resumed sessions since the key was last rotated. > > My first question is: Do we care? > At least for session tickets, I don't care. There's a simple enough way to solve that problem: rotate the session ticket key every few days. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Forward secrecy with resumption, and 0-RTT security
Just how strict do we want to be with forward secrecy? The choices I see are: 1) Avoid 0-RTT connections, and do only 1-RTT connections when we want strict forward secrecy and strong client authentication 2) Keep server-side state for decrypting each ticket, and issue new tickets on each connection, while avoiding 0-RTT replay to the same data center. 3) Give up on first flight forward secrecy, as well as client authentication for first flight data. If tickets are reused for multiple 0-RTT resumptions, then the earlier connections can be decrypted using whatever state the server keeps to decrypt later connections. I think option 1 simple and secure, but is too slow. The choice between 2) and 3) is a security vs cost and complexity trade-off. No new functionality is required to implement 1, 2, or 3, I think. It can be up to the implementation and application. Is it worth spelling out in the spec the gory details? I'm trying out some language for implementing 2, and the downsides for 1 and 3. Not sure if it belongs... Bill ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Analysis of encrypting the headers - what is the length
> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bryan A Ford > Sent: Sunday, December 06, 2015 1:22 AM > To: tls@ietf.org > Subject: Re: [TLS] Analysis of encrypting the headers - what is the length > > On 12/4/15 9:56 PM, Jim Schaad wrote: > > I will start by re-iterating my initial position that I would prefer > > that the DTLS and TLS analysis is going to be the same in terms of > > masking the header information. So I decided to do some thought > > experiments about what happens if the length were to be encrypted and > > how many different situations does this not appear to help the situation. > > Why are you fixated on enumerating different situations where encrypting > headers doesn't help, while completely ignoring situations where it can help? > You could draw up an infinite list of scenarios in both categories. No security > provision will address every possible attack scenario - padding definitely doesn't > either! - but both header encryption and padding are complementary provisions > that each make attacks more difficult for attackers in different ways. Having a solid idea of what the limitations of a solution are can be extremely helpful in trying to determine if the solution solves the problem as presented. My understanding of the problem that you are trying to solve is to hid the length of the data by encrypting it. Knowing when this does and does not work is part and parcel of trying to do the evaluation of a solutions effectiveness and then being able to do an evaluation of the benefits and costs of such a solution. It might be helpful to have a more formal set of situations where the solution works so that it can be compared. If the solution of encrypting the header requires additional tactics as well, then it should be well understood that the encryption solution is, in itself, insufficient. Doing so would also allow for a better understanding of what other solutions can be used to address the same, or similar, problems potentially without the same costs. The question of whether padding does or does not solve the problem depends to a large extend on what the attack model you are using is. If the attack model requires that you know the exact length of the data involved, then doing a simple padding with random lengths of data, or padding out to a fixed boundary does solve the problem entirely. If the attack model is based on distinguishing very large and very small blocks of data, then padding can solve this by making all responses pad out to a very large size. Again one needs to look at the costs of this as always sending a large amount of data in response, most of which is padding, presents a problem for the network and potentially the devices sending and receiving the data (power consumption). One therefore needs to do tradeoffs of the solution vs the problems. I am assuming that your attack model more closely follows the first one presented, but given that you have never stated it in any sort of formal language that is at best a wild guess on my part. Jim > > B ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Forward secrecy with resumption, and 0-RTT security
On Sun, Dec 6, 2015 at 11:39 AM, Eric Rescorla wrote: > With PSK-DHE over 0-RTT, would we use the static DHE server share for the >> first resume flight? >> > > No. In All PSK-DHE modes, the PSK is used as SS. > That's cool. I need to re-read the spec more carefully. > >> You're talking about the single byte that indicates an empty session id? > That doesn't seem like > it's a big source of inefficiency. > Ah... I did not realize it is u8-length encoded. One byte bothers me a lot less. > > I guess another question is: Do we care about strong client authentication >> enough to support it in a 0-RTT world? The default solution when using TLS >> 1.3 is for companies that use security keys to never use 0-RTT >> authentication. That's not the end of the world, but I imagine that having >> to support 0-RTT for regular users, and forcing 1-RTT for employees and >> users who choose a higher level of security is going to be a complication. >> > > Yes, I think it's important, especially for WebRTC. > OK... one more spec to read. > >> I still think some more text describing 0-RTT implementation techniques >> would be a good thing. It really does read as if the spec is saying that >> servers SHOULD NOT support 0-RTT. I've never read a security warning like >> that which did not have a SHOULD NOT associated with it. Of course, I >> haven't read that many IETF specs yet :) >> > > I'll but it on my TODO list but I would definitely welcome a PR here. > > Thanks, > -Ekr > > I'll see if I can put together some text that would help me understand a bit better, though as you can see from my emails so far, writing is not my strong suit. Bill ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Forward secrecy with resumption, and 0-RTT security
On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox wrote: > On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > >> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: >> >>> AFAIK, there has never been a session resumed with forward secrecy. Is >>> this correct? >>> >> >> Yes, session resumption does not have PFS. Though note that with 1.3 that >> will >> no longer be true, because you can do PSK-DHE. >> > > With PSK-DHE over 0-RTT, would we use the static DHE server share for the > first resume flight? > No. In All PSK-DHE modes, the PSK is used as SS. > To have strict forward secrecy, given that the server already has to have >>> server-side state (the pre-shared key), I find the old session ID scheme >>> more palatable than the new tickets. The main point of session tickets was >>> to eliminate the server-side session cache, wasn't it? >>> >> >> The current ticket scheme is compatible with either a server-side >> database *or* having self-contained >> tickets which are encrypted with a server-side key. (This was also true >> for tickets, it's just that >> you didn't bother with tickets if that is what you wanted). If you want a >> database, you just use >> an identifier as the key name. The point is to have a mechanism which >> accomodates either >> design. >> > > I think this is a very cool aspect of TLS 1.3. Inefficiencies always bug > me, though. It is somewhat painful transmitting 0's in the SessionID > field, when we could use that to lookup saved server-side state, reducing > or eliminating the ticket while still supporting 0-RTT resume. However, I > lean pretty far on the side of efficiency. Microseconds and bytes matter, > IMO. > You're talking about the single byte that indicates an empty session id? That doesn't seem like it's a big source of inefficiency. > I haven't thought this through in as much detail as I've thought through >> the >> non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the >> problems with replay. The basic issue is the same: what happens when >> a server gets a connection attached to state which it doesn't have. So, >> what the attacker would do duplicate the ClientHello + PSK and send one >> copy to the true datacenter and one to another datacenter that doesn't >> have >> state. The right datacenter will process the 0-RTT handshake and the >> wrong one will reject it, causing the client to fall back to 1-RTT and >> retransmit >> the request. So, you still get replay. >> >> -Ekr >> > > Correct. PSK does not solve this replay issue. It only defends against > replay to the same data center. This increases the complexity of the attack > and limits the number of times a packet can be replayed, but does not solve > the replay issue. Further mitigation steps, such as making all requests > idempotent (regardless of 0-RTT or 1-RTT), should be taken above the TLS > layer, at the application layer. Datacenter bound PSK 0-RTT does solve the > uniqueness problem with ClientVerify signatures. There would be at most > one accepted flight of packets per signing operation, even in your attack > scenario. > > IMO, ClientVerify should only be supported if this weaker form of replay > protection is in place. Here's a threat model: > > A woman enters a hotel lobby, desperate for access to an online computer. > She uses a computer in the "business center" to access her online account, > which requires her to insert her security key containing her client > certificate. When she's done with her work, she logs out, removes the > security key, and just to be safe smashes the computer into useless bits. > > The attacker who previously installed malware on the computer now is able > to make a large number of new authenticated connections over several days, > with many connections in parallel, even though he no longer has access to > the security key to act as a signing oracle. > Yes, assuming the malware captures the client's DHE share. I've updated the draft to make this point clear. To be clear, the original issue with replay would still apply here as well, since the client would just sign twice. Another thing: resumption in TLS 1.2 breaks this security key scenario as > well. Malware simply exports the session state and resumption ticket, and > the attacker then resumes authenticated connections without access to the > security key. To fix this, there needs to be a new PoP per connection, not > just once on the initial handshake. > Yes, that's one reason that people require fresh signatures on subsequent connections in systems like FIDO, even though they have a token that demonstrates continuity of the client (though typically that token is a cokie). I guess another question is: Do we care about strong client authentication > enough to support it in a 0-RTT world? The default solution when using TLS > 1.3 is for companies that use security keys to never use 0-RTT > authentication. That's not the end of the world, but I imagine that having > to support 0-R
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Sunday 06 December 2015 02:33:39 Peter Gutmann wrote: > > No matter how you colour it, accepting > Application Data after a Client Hello is wrong. Is there any random, > non-formally-verified implementation that would do that? The discussion is about renegotiated handshakes, and yes there is one. Java implementation of TLS can send Application Data during subsequent handshakes. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Sunday 06 December 2015 02:48:33 Peter Gutmann wrote: > Watson Ladd writes: > >please cite the sentence of the TLS RFC which prohibits accepting > >application data records during the handshake. > > Please cite the sentence of the TLS RFC which prohibits accepting SSH > messages during the handshake. > > Please cite the sentence of the TLS RFC which prohibits executing > /usr/games/hack during the handshake. > > Please cite the sentence of the TLS RFC which prohibits reformatting > the user's hard drive during the handshake. > > (This debate is pointless and probably annoying everyone else, so I'll > bow out now). Peter, I think you should go back to the beginning of the thread. (I'm sorry for the necromancy making it a bit hard, but there was a direct question aimed at me that I didn't have time to answer earlier and I don't think we arrived at conclusion before) To summarise: RFC 5246 Section 6.2.1 states: Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. At the same time, sections like 7.4.7 state: It [Client Key Exchange message] MUST immediately follow the client certificate message, if it is sent. or, at section 7.4.9: A Finished message is always sent immediately after a change cipher spec message The question is, which one takes precedence? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
Our state machine design in miTLS was quite deliberate, and based on our interpretation of the TLS 1.2 spec. It is possible that we got this interpretation wrong, but maybe the protocol authors can clarify the intended behavior. However, I think that looking at the Handshake protocol message sequence (Figure 1) for guidance is misleading, because this sequence only concerns the first handshake and does not handle renegotiation. Otherwise, all messages would be marked as optionally encrypted. A proper interpretation of this issue must take into account the two-layer Record/Handshake split that is inherent to TLS 1.2. For example, one interpretation is that the CCS message changes Record state and Application Data can then directly interact with Record without necessarily being aware of Handshake status. In any case, a note about the miTLS security theorem. In miTLS, every application data fragment is labeled by the epoch in which it is sent and received. miTLS itself does not concatenate data from different epochs, but gives applications enough information about the two epochs so that it can choose to combine data from different epochs (say if the certificates used in the two epochs are the same.) So, the miTLS security theorem shows that sending and accepting data during a renegotiation handshake is fine, as long as: (a) this data is treated as belonging to the previous epoch, not the next one, and (b) no data is sent or accepted between CCS and Finished in either direction. Notably, this means that if the new epoch uses new certificates for the client and/or server, any application data sent during the handshake does not get to be authorized with the new certificates, since it still belongs to the old epoch. If the current handshake completes and then new data is sent, the new data will be labeled with the new epoch. Now, the application on top of TLS gets to decide whether it wants to concatenate the data streams from the two epochs. For other implementations, I do agree that sending or accepting data once renegotiation has begun but before the new handshake has finished can be dangerous, because it is sometimes unclear whether this data will be associated with the as-yet-unconfirmed parameters of the new handshake. Best, -K. > On 06 Dec 2015, at 16:50, Hubert Kario wrote: > > On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: >> Hubert Kario writes: >>> miTLS does accept Application Data when it is send between Client >>> Hello and Client Key Exchange and rejects it when it is sent between >>> Change Cipher Spec and Finished. >> >> Given that miTLS is a formally verified implementation, would this >> imply that there's a problem with the verification? "Beware of bugs >> in the above code; I have only proved it correct, not tried it"? > > This behaviour is dictated by the TLS 1.2 RFC, although partially > indirectly: > - the acceptance of application data during subsequent handshakes is > explicit > - the no application data between CCS and Finished is implicit, as it > is only stated that the Finished MUST be the next message directly > following CCS. And since CCS and Finished have different content > types, that means that the limitation is cross-content type, unlike > for other handshake messages > > So on the face of it, behaviour of miTLS is correct. > > Now, as we've discussed on the OpenSSL bug tracker. This does cause > problems if we have certificate based client authentication and the TLS > library returns client authentication data from *new* handshake while it > still has not received and processed Finished message. If that is the > case, then the attacker may force the server to process messages under > authority it still didn't verify. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech > Republic___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls signature.asc Description: Message signed with OpenPGP using GPGMail ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Saturday 05 December 2015 19:20:11 Watson Ladd wrote: > On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann wrote: > > Hubert Kario writes: > >>miTLS does accept Application Data when it is send between Client > >>Hello and Client Key Exchange and rejects it when it is sent > >>between Change Cipher Spec and Finished. > >> > > Given that miTLS is a formally verified implementation, would this > > imply that there's a problem with the verification? "Beware of > > bugs in the above code; I have only proved it correct, not tried > > it"? > > Are you saying there is a security flaw with the behavior described? > Because I don't believe there is after one adopts Extended Master > Secret. (Someone more familiar with the security should check this) Extended Master Secret doesn't come into play here at all. The attack requires just a passive observation of a legitimate exchange for the attacker to have enough information to fake its identity, provided that TLS library returns data to application from a new handshake in renegotiation before the renegotiation finished. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: > Hubert Kario writes: > >miTLS does accept Application Data when it is send between Client > >Hello and Client Key Exchange and rejects it when it is sent between > >Change Cipher Spec and Finished. > > Given that miTLS is a formally verified implementation, would this > imply that there's a problem with the verification? "Beware of bugs > in the above code; I have only proved it correct, not tried it"? This behaviour is dictated by the TLS 1.2 RFC, although partially indirectly: - the acceptance of application data during subsequent handshakes is explicit - the no application data between CCS and Finished is implicit, as it is only stated that the Finished MUST be the next message directly following CCS. And since CCS and Finished have different content types, that means that the limitation is cross-content type, unlike for other handshake messages So on the face of it, behaviour of miTLS is correct. Now, as we've discussed on the OpenSSL bug tracker. This does cause problems if we have certificate based client authentication and the TLS library returns client authentication data from *new* handshake while it still has not received and processed Finished message. If that is the case, then the attacker may force the server to process messages under authority it still didn't verify. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Forward secrecy with resumption, and 0-RTT security
On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > AFAIK, there has never been a session resumed with forward secrecy. Is > this correct? > Yes, session resumption does not have PFS. Though note that with 1.3 that will no longer be true, because you can do PSK-DHE. > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could > be used to decrypt the prior sessions. Using tickets did not work either, > because the server always kept a ticket decryption key which could be used > to decrypt all resumed sessions since the key was last rotated. > Well, the server could in principle delete the keys from the session cache and (at more cost) the decryption key But yes. > To have forward secrecy under the strict definition using the new PSK > scheme, we need to use what the new name implies: pre _shared_ keys. The > new name implies that the server remembers a unique shared key for the > connection, which is server-side state per resumable connection. If we > only store the PSK in the ticket, and go stateless on the server, then the > server-side ticket decryption key again defeats strict forward secrecy. > With a remembered server-side pre-shared secret, we can have a 0-RTT resume > with strict forward secrecy. Is this already implied in the spec? If so, > the spec could be improved, by stating this explicitly. However, the > current statement that 0-RTT does not provide forward secrecy seems to be > wrong in the case that we resume a 0-RTT connections with a > server-remembered PSK. > > To have strict forward secrecy, given that the server already has to have > server-side state (the pre-shared key), I find the old session ID scheme > more palatable than the new tickets. The main point of session tickets was > to eliminate the server-side session cache, wasn't it? > The current ticket scheme is compatible with either a server-side database *or* having self-contained tickets which are encrypted with a server-side key. (This was also true for tickets, it's just that you didn't bother with tickets if that is what you wanted). If you want a database, you just use an identifier as the key name. The point is to have a mechanism which accomodates either design. I think the current spec does not describe well enough how to implement > secure 0-RTT infrastructure. Instead, it seems to recommend against using > 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. > Well, the primary purpose of this warning isn't to warn about PFS. It's really to warn about the replay issue, which is unique to 0-RTT and which can't really be fixed by proper implementation. The issue isn't that it's not possible to have anti-replay if you're willing to store server side state, but rather how you respond to server-side state loss. Moreover, the problems exist whether or not you use certificate-based client authentication. I haven't thought this through in as much detail as I've thought through the non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the problems with replay. The basic issue is the same: what happens when a server gets a connection attached to state which it doesn't have. So, what the attacker would do duplicate the ClientHello + PSK and send one copy to the true datacenter and one to another datacenter that doesn't have state. The right datacenter will process the 0-RTT handshake and the wrong one will reject it, causing the client to fall back to 1-RTT and retransmit the request. So, you still get replay. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich wrote: > > I'm not sure I understand the design you're suggesting. > > Does the EncryptedExtensions contain the entire hello for the "next hop"? > No. It (at most) says "the stuff that is post-handshake is actually a ClientHello for the next hop". I.e., it's literally TLS in TLS. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
> I'm not sure I understand the design you're suggesting. Does the EncryptedExtensions contain the entire hello for the "next hop"? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Sun, Dec 06, 2015 at 01:18:51AM +, Peter Gutmann wrote: > > I hadn't even thought it through to that point, more that you're not supposed > to accept anything between Client Hello and Client Keyex except an optional > Client Certificate. Please read the start of the thread, that includes relevant RFC sections that seem to indicate you can do this. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
On Sun, Dec 6, 2015 at 1:59 AM, Yoav Nir wrote: > >> On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote: >> >> If you disagree, please cite the sentence of the TLS >> RFC which prohibits accepting application data records during the >> handshake. > > OK, I’ll bite. Top of page 36: > > Client Server > > ClientHello > > ServerHello > Certificate* >ServerKeyExchange* > CertificateRequest* >< ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished > >[ChangeCipherSpec] >< Finished > Application Data <---> Application Data > > Figure 1. Message flow for a full handshake > > > See? Application data goes *after* the Finished message. Not between > ClientHello and anything else. Now this swim track diagram may not look like > a formal definition, but RFCs are written to be processed by humans, not > computers. If I add some application data in the middle there like this: (Ever meet a tax lawyer?) But is it defining the flow of messages in the Handshake protocol, or on the wire? The reason I think it's the first is that the RFC several times explains that different layers above the record layer are independent. Even if that's prohibited, there is no requirement to send an alert if that happens: allowing it is not prohibited. In fact several emails in this thread show that other implementers agree with my reading, and that there exist implementations that have this behavior. I hope that whatever renegotiation replacement we have in TLS 1.3 explicitly specifies that this sort of trick is allowed. > > Client Server > > ClientHello > > ServerHello > Certificate* >ServerKeyExchange* > CertificateRequest* >< ServerHelloDone > Application Data > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished > >[ChangeCipherSpec] >< Finished > Application Data <---> Application Data > > > Any human can see that this is not the same as what’s in Figure 1, and thus > is wrong. We don’t need the RFC to provide a regular expression or a state > machine diagram to figure that out. > > Yoav > > > -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Simpler encrypted headers for DTLS (and TLS)
While I think the approach I suggested for encrypted DTLS headers would work, it does have the downsides of (a) the complexity of managing the hash table of encrypted sequence numbers, and (b) the risk of desynchronization after long bursts of missed packets. But further discussion with Philipp Jovanovic led me to the realization that the simplest and cleanest solution in the DTLS case would simply be to rely on AEAD ciphers that either support "secret message numbers" or have a "misuse-resistance" property. In particular: - Secret message numbers basically do "precisely what DTLS needs", namely allow a message/record/sequence number to be transmitted under encryption along with the AEAD payload. Secret message numbers are specified as an optional feature for AEAD submissions to the ongoing CAESAR cipher competition (see http://competitions.cr.yp.to/caesar-call.html), and further elaborated in this useful message by DJB in 2013: https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J - Another optional feature that some CAESAR competition submissions have, and *all* are required to document one way or another, is "misuse-resistance". In particular, a misuse-resistant AEAD does not rely on nonce uniqueness for security. With a misuse-resistant AEAD (which we might alternatively just refer to as a "nonceless AEAD"), you can simply move the complete DTLS header from the additional_data field into the plaintext, and leave the sequence number out of the nonce. The sequence number will still be in (encrypted) header and thus available for replay-protection purposes and such, and will automatically ensure that all DTLS plaintexts (and hence all resulting ciphertexts) are cryptographically unique. I'm not proposing necessarily that the "next version of DTLS" (presumably based on TLS 1.3) should *only* allow AEADs that support secret message numbers or misuse-resistance. Rather, I'm proposing that the next DTLS should support at least one such cipher, and that when DTLS negotiates such a cipher, it simply takes advantage of the relevant property to move the DTLS header under encryption. So the upshot is that simply "using relevant AEAD features when available" would seem to take care of the DTLS case completely, with no special fuss or additional complexity. Which means that we can focus on the TLS case now, without worrying about whether and how easily it will translate to DTLS. And given that, for the TLS case I'm inclined to prefer my second proposal, namely just reinterpreting the "length" field to be a "next-record-length" field. This requires no special mucking with the AEAD in TLS either, and no extra complexity at all in TLS implementations that pad to constant record sizes (which I hope many will). For reference, some background pointers misuse-resistant ciphers (definitely not comprehensive): - https://eprint.iacr.org/2006/221.pdf - https://eprint.iacr.org/2015/999.pdf Cheers Bryan smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Analysis of encrypting the headers - what is the length
On 12/4/15 9:56 PM, Jim Schaad wrote: > I will start by re-iterating my initial position that I would prefer that > the DTLS and TLS analysis is going to be the same in terms of masking the > header information. So I decided to do some thought experiments about what > happens if the length were to be encrypted and how many different situations > does this not appear to help the situation. Why are you fixated on enumerating different situations where encrypting headers doesn't help, while completely ignoring situations where it can help? You could draw up an infinite list of scenarios in both categories. No security provision will address every possible attack scenario - padding definitely doesn't either! - but both header encryption and padding are complementary provisions that each make attacks more difficult for attackers in different ways. B smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
On 12/6/15, Dave Garrett wrote: > On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: >> Can we embed an EncryptedExtension inside an existing EE? That would let >> us do TOR purely within TLS, right? > > If clients are allowed to send any encrypted extensions other than the > tunneling extension (that contains the tunneled hello), then we would have > to allow sending an EncryptedExtension through it, otherwise tunneled peers > would have less capabilities than non-tunneled. I don't see anything in this > design that would prohibit recursively doing this as many times as desired. > (e.g. tunnel of a tunnel of a tunnel of a...) That does sound somewhat > TOR-like, though obviously, lots more would be needed to actually do > anything with that. If this can actually be done, it sounds very promising. > I had a similar thought. There needs to be a way to blind each server that is two hops away to make it work: Alice connects to a server_0, the server routes to server_1, server_1 routes to server_2 and that passes the final TLS to Bob. Alice's TLS message needs to be passed to server_1 without every indicating in an encrypted fashion that server_2 is in the path. In this analogy, server_0 is like the Tor guard, server_1 is the middle node, and server_2 is the exit node. There are some issues with such a design - which is why Tor's design is to use TLS as an outer link layer and then internally to use 512 byte (or slightly larger) cells. I won't get into those here but I find the general idea of tls within tls to be useful. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
