Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
See below. I think the next thing to do is to get a signal from the working group about whether we do or don’t want to allow unsolicited server flags, because prohibiting it will require a significant change in the draft. I’m happy to make such a change, because I still can’t come up with such a flag. > On 23 Apr 2020, at 3:07, Martin Thomson wrote: > > On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: >>> Third, more substantially, and invalidating the above, I don't think that >>> we should make flags introduce a new style of negotiation just because it >>> can. I would strongly prefer that this function as close as possible to >>> "empty ClientHello extension; empty EncryptedExtensions extension". Aside >>> from that, the utility of an advertisement from the server that a client >>> cannot respond to is pretty marginal. >> >> If this is what the group prefers, I’m fine with it, but then there’s >> never any point in sending an empty extension, either from the client >> of form the server. The absence of an individual flag is always implied >> from the absence of the extension. > > When you say "empty extension" here, do you mean "empty flags extension" or > are you speaking more generally? > > If the server can't add flags, then I agree that having the client send an > empty flags extension has little value. Same for the server sending an empty > flags extension in that case. I mean the flags extension. An empty extension conveys just that the sender supports the extension. An empty CH flags extension just says the client supports the flags extension. Unless the server is allowed to send unsolicited flags, an empty flags extension in CH does not convey any useful information. > >>> Are we confident that sending the same extension in both places is safe? I >>> know that clients have to implement this and so should be able to test that >>> this works, but it seems awkward. And it might not be necessary. It's >>> also not sufficient, as we currently allow responses to ClientHello >>> extensions to appear in Certificate (and for CertificateRequest to carry >>> "requests" in the other direction). >> >> I don’t think the two extensions ever carry the same flags. Each server >> side flag should be one of three: serverHello, encrpytedExtensions, or >> neither (if we are not expecting a response) > > So the intersection of flags in different responses must be zero? i.e. > flags[ServerHello] & flags[EncryptedExtensions] == 0 (and the same for any > combination that we allow, including Certificate and NewSessionTicket, I > guess). I can’t think of any flag that will have a different meaning when sent in SH or EE so that you might want to send both. Just in case, the flag registry should have a field similar to the extension registry which says where the field is valid. > >> As for Certificate, I don’t see why we’d need to add bit responses to >> Certificate. They can safely be sent in either serverHello or >> encryptedExtensions. > > The obvious thing here is when the extension applies on a per-certificate > basis as opposed to the entire chain. But I don't have an example you can > use; see below. > >> I’m trying to come up with key exchange bits that might be useful. >> Perhaps a new, improved alternative to HKDF? Support for Quantum Key >> Exchange? > > This might require an understanding of the overall strategy. If the goal is > to provide an analogue of a generic "empty extension", then sure, put it in > ServerHello. But put it in Certificate and NewSessionTicket too. But if you > make this more narrowly applicable and say that you have a different flags > extension for each type of exchange (ClientHello -> ServerHello, ClientHello > -> EncryptedExtensions, ClientHello -> NewSessionTicket, > ClientHello/CertificateRequest -> Certificate), then you might avoid > answering this question for now. > > Right now, it seems like the obvious use here is for EncryptedExtensions, so > we could decide to defer that architectural question by saying that it is > limited to EncryptedExtensions for now. Then we can either expand the one > flags extensions to allow it in NewSessionTicket when we need to, or define a > new one. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
> So far I fail to understand, on an intuitive level, why it easier to > analyze the protocol when the AAD can take multiple forms potentially > truncating or omitting the underlying data, but then I don't know the > details and you're the expert here. If you have time though to explain a > bit more where the flaw in my thinking below is, that would be great, > provided it's possible. > I don't know that there's a flaw in your thinking. At the moment, all that I can speak to is how authenticating the header (or not) might impact security of DTLS. We can't directly extrapolate from what we know about TLS, because the security goal is not to the same. That said what I know about TLS is the following: the contents of the record header doesn't matter for security goal considered in [1], as long as (1) the header is authenticated; and (2) it correctly encodes the length of the next ciphertext. But since the security goal of DTLS is not the same, the details of the spec that are (ir)relevant to security are likely to differ. > For example, another thing which I would expect to be more complicated to > verify in full rigor is epoch authentication: If the epoch is reduced to > its two low order bits in the DTLS 1.3 header and thus (at the moment) also > in the AAD, arguing that decryption can only succeed for the correctly > expanded epoch involves knowing that all epochs having different keys. > That's of course true but this fact wouldn't be needed if the full numeric > epoch was always explicitly authenticated in the AAD. This isn't a real > issue in the end, but I would expect it to be a nuisance in a formal proof? > In terms of what you mentioned regarding decoding details, it seems that > adding the underlying logical header to the AAD ensures more directly that > decryption can only succeed if header decoding (that is, filling in > implicit data or expanding truncated data) was done correctly, whereas it > is less clear with the truncated or omitted data in AAD, as in the epoch > example above. Is it possible to explain what the flaw is here intuitively? > I'm afraid I would need to absorb spec and think about its intended security properties in order to answer these specific questions. I'm sorry if this answer is unhelpful; Ekr asked that I chime due to my prior work on TLS. But I don't think there's a simple answer here, and unfortunately I don't have the time to think it through at the moment. For now, I'll just leave you with this. I'm a fan of the following design principle: whenever there is a branch in your code that depends on a bit read from the wire, that bit should be authenticated if possible. To your example, if a decision you're about to make depends on you agreeing with the peer on the current epoch, the principle says that the epoch had better be authenticated. Whether it's necessary or appropriate to do so here (via AEAD decryption) depends very much on the context, i.e., the protocol details and the security goal. Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 25/04/2020, 11:11, "Thomas Fossati" wrote: > On 25/04/2020, 01:30, "Christopher Wood" wrote: > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > > 1. Allowing implicit CIDs is very recent (it was introduced in > > > -34) > > > 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. > > > I haven't really heard a very compelling argument for this and I > > > note that QUIC forbids it [and in fact has much worse problems > > > when you mix epochs because the long header is so long] > > > > > > So, given that the simplest and most consistent thing is to simply > > > forbid it: can someone make an argument for why this is important > > > to permit? > > > > Thanks to everyone who participated in this thread so far! Given the > > points above, the chairs would like to hear arguments in favor of > > implicit CIDs. Absent substantial rationale, we'll assume rough > > consensus for explicit CIDs. > > Hi Chris, I think implicit CID needs to be considered in the wider > scope of unified_hdr compression, together with implicit length and > shortened epoch. In particular, from Chris P's emails I understand > that being able to authenticate records' length is a core assumption > in the security proof of TLS. Therefore leaving it out from DTLS AAD > when it's not in the header looks like a pretty bad idea. If this is > the case (i.e. the fact that the wire image by itself is not > sufficient input to the AAD), then authenticating implicit CIDs should > just come in the same bundle. Sorry, scratch that for the moment - I had missed the most recent emails on this thread :-( IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
On 24/04/2020, 22:35, "Eric Rescorla" wrote: > On Fri, Apr 24, 2020 at 2:29 PM chris - wrote: > > I would need to study the specs in order to provide an intelligent > > answer here. Off the hip, it would seem to depend on how the > > boundaries between record headers and ciphertexts are determined. > > Taking a quick look at draft-37, Fig. 4: the "full" header includes > > three values that are excluded from the "minimal" header, the length > > of the ciphertext being one of the fields. Presumably, when using > > the "minimal" header, the length is a parameter that the sender and > > receiver already agree on. > > Yes. It's "the rest of the UDP datagram". I might be missing something but this doesn't look to me like the definition of "agreed upon" by the TLS principals: an attacker can modify what "the rest of the datagram" is at will, no? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 25/04/2020, 01:30, "Christopher Wood" wrote: > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > 1. Allowing implicit CIDs is very recent (it was introduced in -34) > > 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. I > > haven't really heard a very compelling argument for this and I note > > that QUIC forbids it [and in fact has much worse problems when you > > mix epochs because the long header is so long] > > > > So, given that the simplest and most consistent thing is to simply > > forbid it: can someone make an argument for why this is important to > > permit? > > Thanks to everyone who participated in this thread so far! Given the > points above, the chairs would like to hear arguments in favor of > implicit CIDs. Absent substantial rationale, we'll assume rough > consensus for explicit CIDs. Hi Chris, I think implicit CID needs to be considered in the wider scope of unified_hdr compression, together with implicit length and shortened epoch. In particular, from Chris P's emails I understand that being able to authenticate records' length is a core assumption in the security proof of TLS. Therefore leaving it out from DTLS AAD when it's not in the header looks like a pretty bad idea. If this is the case (i.e. the fact that the wire image by itself is not sufficient input to the AAD), then authenticating implicit CIDs should just come in the same bundle. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
