Re: [TLS] Are we holding TLS wrong?
Hi everyone, Thanks again for your feedback, we've updated the document to reflect it: https://tools.ietf.org/html/draft-ietf-babel-dtls-02 https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-02 David On Tue, Nov 13, 2018 at 1:41 PM Juliusz Chroboczek wrote: > > - s2.5 Not sure what the ceremonies around flushing a neighbor are, > > but I'd make explicit signalling EOD at least a SHOULD? It seems more > > polite :-) > > > I agree, I upgraded politeness to a SHOULD. > > Note however that a neighbour is usually discarded when we loose too many > Hellos from it. At that point, we've lost contact with the neighbour, > it's too late to be polite. > > -- Juliusz > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
> - s2.5 Not sure what the ceremonies around flushing a neighbor are, > but I'd make explicit signalling EOD at least a SHOULD? It seems more > polite :-) > I agree, I upgraded politeness to a SHOULD. Note however that a neighbour is usually discarded when we loose too many Hellos from it. At that point, we've lost contact with the neighbour, it's too late to be polite. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
> Yep, all of which speaks to some serious shortcomings of the > HMAC-based protocol. The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to implement the strict minimum of features that make it useful. Any deployment that needs features beyond what Babel-HMAC provides should use Babel-DTLS instead. > If N^2 is feasible, it would be good to hear how those keys are managed. Not in Babel-HMAC, no. We've tried to be very clear about that in Section 1.1 of draft-ietf-babel-hmac-00 : The protocol defined in this document assumes that all interfaces on a given link are equally trusted and share a small set of symmetric keys (usually just one, two during key rotation). The protocol is inapplicable in situations where asymmetric keying is required, where the trust relationship is partial, or where large numbers of trusted keys are provisioned on a single link at the same time. This protocol supports incremental deployment (where an insecure Babel network is made secure with no service interruption), and it supports graceful key rotation (where the set of keys is changed with no service interruption). This protocol does not require synchronised clocks, it does not require persistently monotonic clocks, and it does not require any form of persistent storage. If you believe this deserves further clarification, we'll be grateful for your guidance. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
On Tue, Nov 13, 2018 at 12:33 PM David Schinazi wrote: > Our threat model should be described in the introduction. From your > comments I'm guessing it isn't clear, so we should fix that. The basic > idea is that any on-link device can change the routing of the entire > network, and that's bad for hopefully obvious reasons. The goal of > Babel over DTLS is to prevent that. Can you suggest a better way > to convey that? It might pay to describe who is involved, and what prior information is assumed. There might be a few different deployment assumptions, which probably means pointing at other documents. Your list of PSK options (below) assumes a range of options, each assuming a different threat model. I hadn't even considered that option - the draft mentions asymmetric-key-based authentication. Which you should probably pin down to either certificates or raw public keys. Not choosing is a different sort of choosing. > PSK can either be used with: > - one key for the entire network, which does not allow revocation In this case, you would assume that there is no possibility of compromise or defection of any entity in a "network". That doesn't seem like a reasonable threat model. > - one key per node (N), but that requires all nodes to know all keys > which allows impersonation > - pairwise (N^2) keys, which does not scale well Yep, all of which speaks to some serious shortcomings of the HMAC-based protocol. If N^2 is feasible, it would be good to hear how those keys are managed. 1 and N similarly don't seem feasible from a deployment and operational perspective. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
Hi Martin, Thanks for looking into this. Our threat model should be described in the introduction. From your comments I'm guessing it isn't clear, so we should fix that. The basic idea is that any on-link device can change the routing of the entire network, and that's bad for hopefully obvious reasons. The goal of Babel over DTLS is to prevent that. Can you suggest a better way to convey that? I've removed the mention of the certificate status request extension, as I don't think it's relevant and don't remember why it was added. PSK can either be used with: - one key for the entire network, which does not allow revocation - one key per node (N), but that requires all nodes to know all keys which allows impersonation - pairwise (N^2) keys, which does not scale well so PSK would be suited in the simple case where revocation is not wanted, but in that use-case we recommend Babel-HMAC. I'll let the Babel-HMAC authors start a separate thread. David On Fri, Nov 9, 2018 at 4:26 AM Martin Thomson wrote: > Hi David, > > I couldn't find any description of the threat model involved here, nor > could I find any analysis of the security against that model. Without > that, I can't really say whether this is right or not. For instance, > there is specific mention of the certificate status request extension, > but there is no mention of why. > > Given the configuration that I might infer from the hmac draft, I'm a > little surprised that this doesn't use PSK. > > I'm somewhat dismayed by the firm recommendation to use the HMAC > mechanism, which doesn't seem particularly robust. Offhand, it seems > like replays are possible if you allow the possibility of the node > crashing and dumping state. The same applies during a rollover of the > 32-bit counter. Of course, that might not be permitted by the threat > model. > On Thu, Nov 8, 2018 at 9:15 AM David Schinazi > wrote: > > > > Hi everyone, > > > > Over in the Babel working group we have a draft about securing Babel > with DTLS: > > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > > > It's 5 pages long, could any TLS experts please give it a quick read and > let us know if we're using DTLS correctly? > > > > Also, should the document contain guidance such as which DTLS version to > use? > > > > Thanks, > > David > > ___ > > 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] Are we holding TLS wrong?
Thanks for the feedback Thomas! Responses inline. On Wed, Nov 7, 2018 at 8:30 PM Fossati, Thomas (Nokia - GB/Cambridge) < thomas.foss...@nokia.com> wrote: > One high level thing which I can't extrapolate from the draft (which is > probably due to my ignorance with Babel) is whether you envisage that > *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes > are excluded from the mesh? Or would it be acceptable to mesh HMAC and > DTLS neighbours? What about clear-text speakers? (It'd seem unwise to > let them in an otherwise secured enclave.) > The main use-case would be that the entire mesh runs over DTLS and cleartext nodes are excluded. However, if a deployment has specific properties, one could configure this per-interface: a router could require DTLS over the Wi-Fi interface but allow non-DTLS on the secure VPN interface. That would allow cleartext speakers over VPN into the DTLS-secured enclave, but that should only be used by someone who wants that property. I've added a subsection. > You should probably provide some guidance about the kind of > credentials do you plan to use (certs, raw pkeys)? > We actually don't currently have guidance to give, as it might depend on the use-case. For example, there will be a document specifying how HOMENET uses Babel over DTLS, and I suspect that document will provide very specific guidance on what credentials to use and how they are provisioned. > It seems to me that the P2P nature of the protocol requires mutual > authentication, could you confirm it? This seems to be a critical thing > to prevent a rogue node to spoof the lowest (highest, I have already > forgot, sorry) L-L address in a clear-text multicast Hello and bypass > authentication. > Absolutely, this requires mutual authentication, I'll add a specific note to the draft. > - s2.1 > "Nodes SHOULD ensure that new client DTLS connections use different > ephemeral ports from recently used connections to allow servers to > differentiate between the new and old DTLS connections." > > Maybe you could suggest using a sufficiently entropic connection id here > as a more robust alternative. > Good point, I added text. > - s2.5 > Not sure what the ceremonies around flushing a neighbor are, but I'd > make explicit signalling EOD at least a SHOULD? It seems more polite > :-) > I agree, I upgraded politeness to a SHOULD. > - s.3 > Not sure which TLS stack Babel nodes will use (are you targeting > extremely constrained devices with custom TLS implementations?), but all > the stacks I know of let the application set the MTU and take care of > splitting the messages in MTU sized chunks transparently. > The goal is for this to work on general-purpose stacks as well as embedded ones. Since Babel datagrams are comprised of a sequence of TLVs, it's best to fragment at the Babel layer because that way a single fragment is still parseable in the presence of packet loss. I added text to clarify this. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
Thanks for your comment Hannes! One of the motivations for Babel-HMAC (the custom format only offering integrity protection) is to have a simple mechanism with smaller dependencies for inclusion in small embedded devices that do not necessarily have a DTLS stack. We could define a mechanism that performs Babel-DTLS and then leverages a keying material exporter to have keys for Babel-HMAC and use that for multicast, but potentially in a later draft -- we're trying to minimize complexity for this current pass. David On Wed, Nov 7, 2018 at 8:53 PM Hannes Tschofenig wrote: > I took a quick look at the document and I don't know Babel. > > I see that you have two different proposals for securing Babel messages, > namely > * DTLS, and > * a custom format offering integrity protection only. > > You correctly note in the document that DTLS offers more features. It is > an authentication and key exchange protocol. > > One option to explore is to use DTLS to perform authentication and key > exchange then use your custom format for integrity protection of packets > with the keys exported from DTLS. Design-wise this approach is similiar to > what we have done with DTLS-SRTP. This would also allow you to cover the > multicast security case. > > Ciao > Hannes > > *Gesendet:* Donnerstag, 08. November 2018 um 11:30 Uhr > *Von:* "Fossati, Thomas (Nokia - GB/Cambridge)" > *An:* "David Schinazi" > *Cc:* "draft-ietf-babel-d...@ietf.org" , " > tls@ietf.org" > *Betreff:* Re: [TLS] Are we holding TLS wrong? > Hi David, > > A few quick notes below. > > Cheers > > The 11/08/2018 09:14, David Schinazi wrote: > > Hi everyone, > > > > Over in the Babel working group we have a draft about securing Babel with > > DTLS: > > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > > > It's 5 pages long, could any TLS experts please give it a quick read and > > let us know if we're using DTLS correctly? > > > > Also, should the document contain guidance such as which DTLS version to > > use? > > > > Thanks, > > David > > Premise: I don't know Babel -- apologies for any nonsense! > > One high level thing which I can't extrapolate from the draft (which is > probably due to my ignorance with Babel) is whether you envisage that > *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes > are excluded from the mesh? Or would it be acceptable to mesh HMAC and > DTLS neighbours? What about clear-text speakers? (It'd seem unwise to > let them in an otherwise secured enclave.) > > You should probably provide some guidance about the kind of > credentials do you plan to use (certs, raw pkeys)? > > It seems to me that the P2P nature of the protocol requires mutual > authentication, could you confirm it? This seems to be a critical thing > to prevent a rogue node to spoof the lowest (highest, I have already > forgot, sorry) L-L address in a clear-text multicast Hello and bypass > authentication. > > - s2.1 > "Nodes SHOULD ensure that new client DTLS connections use different > ephemeral ports from recently used connections to allow servers to > differentiate between the new and old DTLS connections." > > Maybe you could suggest using a sufficiently entropic connection id here > as a more robust alternative. > > - s2.5 > Not sure what the ceremonies around flushing a neighbor are, but I'd > make explicit signalling EOD at least a SHOULD? It seems more polite > :-) > > - s.3 > Not sure which TLS stack Babel nodes will use (are you targeting > extremely constrained devices with custom TLS implementations?), but all > the stacks I know of let the application set the MTU and take care of > splitting the messages in MTU sized chunks transparently. > > -- > Thomas > ___ > 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] Are we holding TLS wrong?
On Fri, Nov 9, 2018 at 11:10 PM Juliusz Chroboczek wrote: > > Offhand, it seems like replays are possible if you allow the possibility > > of the node crashing and dumping state. > > Unless I've missed something -- they are not, assuming you have > a sufficiently strong random number generator. The challenge mechanism > rebuilds the shared state in a secure manner, and the index mechanism > ensures that an (index, seqno) pair is never reused. I had a really hard time understanding this, even with this help. Right now, I don't know what key is used for HMAC. I think that the expectation is that each peer has a fixed HMAC key, but the contents of the packet always change, thereby ensuring that the resulting MAC is different for every packet. Given how non-intuitive this whole thing is, I would suggest that a formal analysis would be a good idea. Or you could just use DTLS and get things like post compromise security and nice things like that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
> I'm somewhat dismayed by the firm recommendation to use the HMAC > mechanism, Yeah, this could probably be loosened somewhat. > which doesn't seem particularly robust. It's designed to be fairly robust. Of course, we may have done things wrong. > Offhand, it seems like replays are possible if you allow the possibility > of the node crashing and dumping state. Unless I've missed something -- they are not, assuming you have a sufficiently strong random number generator. The challenge mechanism rebuilds the shared state in a secure manner, and the index mechanism ensures that an (index, seqno) pair is never reused. > The same applies during a rollover of the 32-bit counter. You generate a new index when the counter overflows, and send a new challenge. First point of Section 4.2 of the HMAC draft. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
Hi David, I couldn't find any description of the threat model involved here, nor could I find any analysis of the security against that model. Without that, I can't really say whether this is right or not. For instance, there is specific mention of the certificate status request extension, but there is no mention of why. Given the configuration that I might infer from the hmac draft, I'm a little surprised that this doesn't use PSK. I'm somewhat dismayed by the firm recommendation to use the HMAC mechanism, which doesn't seem particularly robust. Offhand, it seems like replays are possible if you allow the possibility of the node crashing and dumping state. The same applies during a rollover of the 32-bit counter. Of course, that might not be permitted by the threat model. On Thu, Nov 8, 2018 at 9:15 AM David Schinazi wrote: > > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please give it a quick read and let > us know if we're using DTLS correctly? > > Also, should the document contain guidance such as which DTLS version to use? > > Thanks, > David > ___ > 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] Are we holding TLS wrong?
I took a quick look at the document and I don't know Babel. I see that you have two different proposals for securing Babel messages, namely * DTLS, and * a custom format offering integrity protection only. You correctly note in the document that DTLS offers more features. It is an authentication and key exchange protocol. One option to explore is to use DTLS to perform authentication and key exchange then use your custom format for integrity protection of packets with the keys exported from DTLS. Design-wise this approach is similiar to what we have done with DTLS-SRTP. This would also allow you to cover the multicast security case. Ciao Hannes Gesendet: Donnerstag, 08. November 2018 um 11:30 Uhr Von: "Fossati, Thomas (Nokia - GB/Cambridge)" An: "David Schinazi" Cc: "draft-ietf-babel-d...@ietf.org" , "tls@ietf.org" Betreff: Re: [TLS] Are we holding TLS wrong? Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please give it a quick read and > let us know if we're using DTLS correctly? > > Also, should the document contain guidance such as which DTLS version to > use? > > Thanks, > David Premise: I don't know Babel -- apologies for any nonsense! One high level thing which I can't extrapolate from the draft (which is probably due to my ignorance with Babel) is whether you envisage that *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes are excluded from the mesh? Or would it be acceptable to mesh HMAC and DTLS neighbours? What about clear-text speakers? (It'd seem unwise to let them in an otherwise secured enclave.) You should probably provide some guidance about the kind of credentials do you plan to use (certs, raw pkeys)? It seems to me that the P2P nature of the protocol requires mutual authentication, could you confirm it? This seems to be a critical thing to prevent a rogue node to spoof the lowest (highest, I have already forgot, sorry) L-L address in a clear-text multicast Hello and bypass authentication. - s2.1 "Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections." Maybe you could suggest using a sufficiently entropic connection id here as a more robust alternative. - s2.5 Not sure what the ceremonies around flushing a neighbor are, but I'd make explicit signalling EOD at least a SHOULD? It seems more polite :-) - s.3 Not sure which TLS stack Babel nodes will use (are you targeting extremely constrained devices with custom TLS implementations?), but all the stacks I know of let the application set the MTU and take care of splitting the messages in MTU sized chunks transparently. -- Thomas ___ 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] Are we holding TLS wrong?
Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please give it a quick read and > let us know if we're using DTLS correctly? > > Also, should the document contain guidance such as which DTLS version to > use? > > Thanks, > David Premise: I don't know Babel -- apologies for any nonsense! One high level thing which I can't extrapolate from the draft (which is probably due to my ignorance with Babel) is whether you envisage that *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes are excluded from the mesh? Or would it be acceptable to mesh HMAC and DTLS neighbours? What about clear-text speakers? (It'd seem unwise to let them in an otherwise secured enclave.) You should probably provide some guidance about the kind of credentials do you plan to use (certs, raw pkeys)? It seems to me that the P2P nature of the protocol requires mutual authentication, could you confirm it? This seems to be a critical thing to prevent a rogue node to spoof the lowest (highest, I have already forgot, sorry) L-L address in a clear-text multicast Hello and bypass authentication. - s2.1 "Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections." Maybe you could suggest using a sufficiently entropic connection id here as a more robust alternative. - s2.5 Not sure what the ceremonies around flushing a neighbor are, but I'd make explicit signalling EOD at least a SHOULD? It seems more polite :-) - s.3 Not sure which TLS stack Babel nodes will use (are you targeting extremely constrained devices with custom TLS implementations?), but all the stacks I know of let the application set the MTU and take care of splitting the messages in MTU sized chunks transparently. -- Thomas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
