Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote: > Alan DeKok writes: > > >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages > >*after* the Finished message. i.e. the Session Ticket, etc. When an > >application calls SSL_Read(), all of the TLS data is processed, instead of > >just the "TLS finished" message. They've made this the default, because most > >applications get it wrong. > > Asking as the author of a TLS library that has always done this, why would you > stop immediately after the Finished and leave metadata messages sitting unread > in the input stream? Was it just some arbitrary implementation decision, or > is there a technical reason for it? I expect (but did not attempt to validate) that this was SSLeay-vintage logic involving only reading a single record from the wire per call to SSL_read(). If that record was a handshake record and not application data, well, then the SSL_read() didn't do something useful and so the special "try again" code was returned and the application was supposed to call SSL_read() again. There's no technical reason that I'm aware of. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Alan DeKok writes: >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages >*after* the Finished message. i.e. the Session Ticket, etc. When an >application calls SSL_Read(), all of the TLS data is processed, instead of >just the "TLS finished" message. They've made this the default, because most >applications get it wrong. Asking as the author of a TLS library that has always done this, why would you stop immediately after the Finished and leave metadata messages sitting unread in the input stream? Was it just some arbitrary implementation decision, or is there a technical reason for it? Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk wrote: > On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > > DISCUSS: the EAP-TLS draft should also explain that session tickets > may be sent either before or after the 0x00 octet. Does the packet flow > look any different for the two cases? If so, what does that mean? > > > > > > [Joe] I believe the flow of the message flights would be the same, but > the on-the-wire format of those flights could be reversed. I don't think > this will necessarily cause a problem since the application data is > consumed by the EAP TLS and the NewSessionTicket is consumed by TLS, > However I think the draft should be clear that this can happen. > > > > I think so, too. > > I think we should talk about that, yes. > But I haven't managed to convince myself yet that it is 100% safe in the > face of fragmentation -- can we rule out a case where we end up delivering > an EAP-TLS message that ends exactly at the end of the application data > record (say, if bundled along with the tail end of the server handshake > flight) and there is a NewSessionTicket queued that would get fragmented > into the next EAP-TLS message? > > [Joe] As Alan points out, the peer should parse all fragments to get the complete message and pass them all to the TLS layer. It would be good to call this out, but I don't think it should be a problem for implementations. For example, if the peer is notified that application data is available before it has finished passing all the data to the TLS layer it should pass the rest of the data to the TLS layer before responding. > > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note > that this examples does not include Session Tickets. Section 2.1.2 should > be updated to note that there are more rounds than for the previous section. > > > > > > [Joe] Yes. It might be helpful to say that the commitment message may > be sent before or after the client authentication is verified, but in the > case that resumption is used it will always be after. > > > > I think that's a good idea. The current draft doesn't make this > explicit. > > > > But... if the commitment message is sent before the client > certificates have been authenticated, what does that commitment message > *mean*? > > > > i.e. can the server send the commitment message, ignore the client > cert information, and send an EAP-Success? Even if the client certs have > expired, been revoked, etc.? Can the client detect a rogue server which > always answers "yes"? > > That's a scenario that I was starting to puzzle over this weekend as well > -- with EAP-Success "completely unauthenticated", it would be fairly easy > for an on-path attacker to send the EAP-Success the EAP peer was expecting > and make the EAP peer think things succeeded even if the server had > rejected the client cert. Now, a server that has rejected the client cert > is hopefully not going to be exporting the keys and continuing to run the > next steps of protocol operation, but to some extent it seems that the > security of the system as a whole relies on the server operating correctly > in this regard. Strictlys speaking, it need not do so -- we could have > defined a mechanism where the exported keys depend, cryptographically, on > the client authentication flight such that the TLS layer will not produce > the needed keys on failed authentication. [0] > > [Joe] This could be also a difference between EAP-TLS 1.2 and EAP-TLS 1.3. In 1.2, the server's finished came second so, if the server rejected the peer certificate it could abort before sending the finished and the client's state machine would not be able to continue. However, 5216 section 2.1.3, suggests that errors should be sent after the finished which means they could be removed from the conversation and the peer would be none the wiser. It seems the behavior between 1.2 and 1.3 would be similar in this regard. I'm assuming that people will not be terribly keen on switching to such a > scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter > variant that includes the full transcript hash, [1] not just up to Server > Finished, which would incur at a minimum several months' delay. It might > be worth asking the teams that did formal analysis work on TLS 1.3 how they > modelled client authentication and what assumptions on server behavior they > made. > > So, if we do not wait for a cryptographic method to assure successful > client authentication, and thus are going to be stuck requiring some amount > of trust that the server is doing the right thing with the keys, how is it > different to say that the server is going to not export the keys if the > client authentication fails vs saying that the server is going to not > export the keys if it is not done sending handshake messages? There is > perhaps some detail in terms of how EAP-TLS interacts with
Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt
Do you think this would be clearer: The maximum validity period is set to 7 days unless an application profile standard specifies a shorter period. spt > On Jan 25, 2021, at 11:14, Russ Housley wrote: > > I have reviewed the recent update, and I notice one inconsistency. > > Section 2 says: > > In the absence of an application profile standard > specifying otherwise, the maximum validity period is set to 7 days. > > Section 4.1.3 says: > > 1. Validate that DelegatedCredential.cred.valid_time is no more than > 7 days. > > I think that Section 2 is trying to say that an application profile can make > it even shorter than 7 days, but on my first reading I got the opposite. > > Russ > > >> On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Layer Security WG of the IETF. >> >> Title : Delegated Credentials for TLS >> Authors : Richard Barnes >> Subodh Iyengar >> Nick Sullivan >> Eric Rescorla >> Filename: draft-ietf-tls-subcerts-10.txt >> Pages : 19 >> Date: 2021-01-24 >> >> Abstract: >> The organizational separation between the operator of a TLS endpoint >> and the certification authority can create limitations. For example, >> the lifetime of certificates, how they may be used, and the >> algorithms they support are ultimately determined by the >> certification authority. This document describes a mechanism by >> which operators may delegate their own credentials for use in TLS, >> without breaking compatibility with peers that do not support this >> specification. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, With my apologies to everyone on the thread for so many mails in succession... On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote: > > With respect to the exporter usage, I do see you had asked about using the > > type-code as the exporter context value that Martin didn't see much value > > in, but I am willing to accept that as a boon for safety of portability to > > other TLS-using EAP mechanisms. > > OK. > > > (I do note that the current editor's copy > > shows calls to TLS-Exporter() with only two arguments, but three are > > required; the construction there also seems to include a propspect for > > violation of the requirement that "one label is not a prefix of any other > > label" when both regular one-byte and extended type codes are used, but if > > the type code is meant to be the context argument I believe that risk goes > > away.) > > The EAP type codes are one octet: 0x00 through 0xfd. The "expanded" type > codes begin with 0xfe. So there is no prefix issue, even if the type codes > form part of the label. Ah, of course I should have realized that the 0xfe octet separates them. You are correct; there is no issue with prefixes, and sorry for the confusion. Thanks, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Mohit, The quoting in your note is not coming across usefully in my MUA, so I'm trimming to (what I think are) just your remarks without other history. On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote: > Hi Ben, > > RFC 5705 says: > >If no context is provided, it then computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random >)[length] > >If context is provided, it computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random + >context_value_length + context_value >)[length] > > > We use only two arguments and say "No context data is used in the TLS > exporter interface.". We could show the context argument as empty in the > calls to make things clearer. By the way, this is what is done by TEAP also. > RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined > in [RFC5705] to derive the session_key_seed. The label used in the > derivation is "EXPORTER: teap session key seed". The length of the session > key seed material is 40 octets. No context data is used in the export > process." We're using the TLS 1.3 exporter, though, so the RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument form seems most relevant. Note that there is no difference in TLS 1.3 between an absent context and a zero-length context. > The change of moving the type-code from the context to the label was made > based on your review (comments from Martin) and the fact that some libraries > such as wolfssl don't support passing a context (so far). See: > https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996 I'm not going to get super hung-up on label vs context (but it's clearly a bug if WolfSSL doesn't support contexts). I guess Martin even wanted the type code to be in the label part in the first place, so having it in the label is "better"; we just need to actually show that there's an empty context argument. > I think there was a misunderstanding that an authenticated signal of > authentication completed was needed. Only a signal of no more post handshake > messages was needed. I think Alan's summary might also explain the situation > better. I note that Alan seems to also be a bit unclear about exactly what purpose the commitment message serves; I look forward to seeing how the questions he has listed get answered. Thanks, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > > sent either before or after the 0x00 octet. Does the packet flow look any > > different for the two cases? If so, what does that mean? > > > > [Joe] I believe the flow of the message flights would be the same, but the > > on-the-wire format of those flights could be reversed. I don't think this > > will necessarily cause a problem since the application data is consumed by > > the EAP TLS and the NewSessionTicket is consumed by TLS, However I think > > the draft should be clear that this can happen. > > I think so, too. I think we should talk about that, yes. But I haven't managed to convince myself yet that it is 100% safe in the face of fragmentation -- can we rule out a case where we end up delivering an EAP-TLS message that ends exactly at the end of the application data record (say, if bundled along with the tail end of the server handshake flight) and there is a NewSessionTicket queued that would get fragmented into the next EAP-TLS message? > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that > > this examples does not include Session Tickets. Section 2.1.2 should be > > updated to note that there are more rounds than for the previous section. > > > > [Joe] Yes. It might be helpful to say that the commitment message may be > > sent before or after the client authentication is verified, but in the case > > that resumption is used it will always be after. > > I think that's a good idea. The current draft doesn't make this explicit. > > But... if the commitment message is sent before the client certificates > have been authenticated, what does that commitment message *mean*? > > i.e. can the server send the commitment message, ignore the client cert > information, and send an EAP-Success? Even if the client certs have expired, > been revoked, etc.? Can the client detect a rogue server which always > answers "yes"? That's a scenario that I was starting to puzzle over this weekend as well -- with EAP-Success "completely unauthenticated", it would be fairly easy for an on-path attacker to send the EAP-Success the EAP peer was expecting and make the EAP peer think things succeeded even if the server had rejected the client cert. Now, a server that has rejected the client cert is hopefully not going to be exporting the keys and continuing to run the next steps of protocol operation, but to some extent it seems that the security of the system as a whole relies on the server operating correctly in this regard. Strictlys speaking, it need not do so -- we could have defined a mechanism where the exported keys depend, cryptographically, on the client authentication flight such that the TLS layer will not produce the needed keys on failed authentication. [0] I'm assuming that people will not be terribly keen on switching to such a scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter variant that includes the full transcript hash, [1] not just up to Server Finished, which would incur at a minimum several months' delay. It might be worth asking the teams that did formal analysis work on TLS 1.3 how they modelled client authentication and what assumptions on server behavior they made. So, if we do not wait for a cryptographic method to assure successful client authentication, and thus are going to be stuck requiring some amount of trust that the server is doing the right thing with the keys, how is it different to say that the server is going to not export the keys if the client authentication fails vs saying that the server is going to not export the keys if it is not done sending handshake messages? There is perhaps some detail in terms of how EAP-TLS interacts with the TLS layer and what information is available when, but it seems that if you have an interface with TLS of "provide input bytes; get output bytes out" [2] you could achieve this by not exporting keys until you've sent all those bytes into EAP-TLS messages. > RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine > for EAP peer and server. Does this work follow that? A good question! > > [Joe] If we are going to make a change in the key derivation we should do > > it now. Personally, I think we should update the key derivation to > > separate the MSK and EMSK, but it is workable as is. > > I think there are potential issues around the ordering of the 0x00 octet > > and other messages, but I don't think this will require changes to > > implementations in the short term, but the spec needs to clarify this. > > I agree. I wonder if (assuming that 0x00 goes forward instead of "close_notify") we should also go further and say that this mechanism does not use stock TLS 1.3, but rather a variant of the protocol that imposes an
Re: [TLS] ALPS and TLS 1.3 half-RTT data
On Sat, Jan 30, 2021, at 10:38, David Benjamin wrote: > How does NSS expose the late client authentication to the application? > I thought NSS didn't support half-RTT at all when the server requests > client certificates, but perhaps I misunderstood. There are three states we use with respect to client authentication; those guide what might be done: 1. No CertificateRequest (0.5-RTT is therefore always safe to send) 2. Request a client certificate, but don't require it (positions differ here) 3. Require a client certificate (0.5-RTT is arguably unsafe to send, unless you can be sure it is not conditional on client authentication) I originally decided to allow 0.5-RTT in cases 1 and 2. My logic was that a server in that posture always needed to check for a certificate before sending anything. That is, the server was already in the appropriate posture and enabling 0.5-RTT could not make things worse. However, Ekr was unhappy with that idea and I decided not to fight it (that doesn't make him any more right, but he was definitely right to insist on stronger justification; I just didn't have the energy to provide that justification, more so because we don't really make a server and all I really wanted to know was that we correctly handled 0.5-RTT at the client). Back to the main subject... On reflection, the buffering thing was a false trail. The reason we have buffering for 0-RTT is primarily because that is followed by handshake-critical data. We have to clear 0-RTT aside to get to handshake data, because there is a risk that it fills the congestion window and prevents the Finished from ever being sent. Unless you support blocking writes that also block reads, I don't believe that 0.5-RTT has the same problem. For me, this whole question is down to imposing constraints on usage. We have this artificial constraint that says an extension or handshake message (like ALPS) can't contain anything that is conditioned on application data. That is a useful constraint, because it makes the handshake easier to reason about. But the same constraint can be applied to 0.5-RTT if we chose, making all versions of it safe to use in the same way (even case 3 above). At that point, the question becomes whether you think that covering this data with the handshake transcript is worth the head-of-line blocking exposure. (And other miscellany, I guess, like what your priors are regarding adding more extension points.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > sent either before or after the 0x00 octet. Does the packet flow look any > different for the two cases? If so, what does that mean? > > [Joe] I believe the flow of the message flights would be the same, but the > on-the-wire format of those flights could be reversed. I don't think this > will necessarily cause a problem since the application data is consumed by > the EAP TLS and the NewSessionTicket is consumed by TLS, However I think the > draft should be clear that this can happen. I think so, too. > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this > examples does not include Session Tickets. Section 2.1.2 should be updated > to note that there are more rounds than for the previous section. > > [Joe] Yes. It might be helpful to say that the commitment message may be > sent before or after the client authentication is verified, but in the case > that resumption is used it will always be after. I think that's a good idea. The current draft doesn't make this explicit. But... if the commitment message is sent before the client certificates have been authenticated, what does that commitment message *mean*? i.e. can the server send the commitment message, ignore the client cert information, and send an EAP-Success? Even if the client certs have expired, been revoked, etc.? Can the client detect a rogue server which always answers "yes"? RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine for EAP peer and server. Does this work follow that? > [Joe] If we are going to make a change in the key derivation we should do it > now. Personally, I think we should update the key derivation to separate the > MSK and EMSK, but it is workable as is. > I think there are potential issues around the ordering of the 0x00 octet and > other messages, but I don't think this will require changes to > implementations in the short term, but the spec needs to clarify this. I agree. There's also the question of *why* the commitment message is there. It's not in EAP-TLS for TLS 1.2. The draft doesn't explain why it's not needed in TLS 1.2, but is needed for TLS 1.3. Such an explanation would go a long way to clarifying many issues around the commitment message. > So if we later discover that EAP-TLS is flawed, we can only deprecated > EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code. > > [Joe] Perhaps we could use an expanded EAP-Type for the alpha? Or perhaps > experimental or a temporary experimental allocation could be made (not sure > if that would be possible). I think the issue for MS is less "alpha" code than "shipping" code. If we use an experimental type, it doesn't matter if it's interoperable, because people won't deploy it in production. Implementors are already verifying code behind the scenes in builds which aren't shipped to customers. So the type code is less of an issue, because that interoperability is "inter-engineer", and not "inter-customer". Alan DeKok. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
