Re: [TLS] Connection ID Draft
Hi Martin, On 17/10/2017, 00:42, "Martin Thomson" wrote: > Thomas mentioned a heuristic, but I don't think that we need that. > The only case that is difficult, and it's one that you might not care > about, is one where a connection migrates to the same 5-tuple as an > another connection. There, you will match to an existing connection > and find that the packet doesn't decrypt. If the connection that you > have associated with the 5-tuple supports and uses a connection ID, > you can recover without trial decryption. Otherwise, you just have to > drop the packet when it doesn't decrypt. (You could look up all the > connections without connection IDs and use trial decryption, but why > bother spending the effort and undermine the strength of your ciphers > in that way.) The following case (NAT box reboot) is problematic: 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on host B (B.1); 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; 3. The NAT box reboots (all previous 5-tuple mappings are lost); 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the meanwhile); How is B.1 supposed to correctly interpret the bytes starting at offset +11? (For what it knows, it could be CID from A.1 or the length field from A.2.) That's where the heuristic I mentioned in the other email comes in, I think. > Packet inspection boxes will have maintain state, I don't see a way > around that. The point here being that you need state to know how > long the connection ID is, as well as how long it is. I might be missing something fundamental here, but isn't the length encoded in the CID field on the wire? Cheers ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On 10/13/2017 02:45 PM, Stephen Farrell wrote: So the problems with that are numerous but include: - there can be >1 carol, (and maybe all the carols also need to "approve" of one another), if we were crazy enough to try do this we'd have at least: - corporate outbound snooper - data-centre snooper (if you buy those supposed use-cases) - government snooper(s) in places where they don't care about doing that openly ...port 80 would suddenly be quicker than 443 again;-( And any authorized eavesdropper is not allowed to be able to infer if they are the only ones listening in. I don't understand why this complicated approach is needed. Why can't the server provide an OOB interface to look up sessions keys, or maybe export them proactively? The proposed draft needs a protocol like this anyway because SSWrapDH1 keys need to be distributed, and periodic key regeneration is needed because it is the only way to implement revocation of access privileges without revealing the existence of other authorized parties. I don't buy the argument that there are too many session keys for proactive export. Obviously, you already have sufficient capacity to send these keys (or an equivalent) over the wire once, so sending another copy or two shouldn't be a problem. Thanks, Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> I don't understand why this complicated approach is needed. Why can't the > server provide an OOB > interface to look up sessions keys, or maybe export them proactively? The > proposed draft needs a > protocol like this anyway because SSWrapDH1 keys need to be distributed, and > periodic key > regeneration is needed because it is the only way to implement revocation of > access privileges > without revealing the existence of other authorized parties. In my opinion, the proposed draft does not define a protocol because it expects that SSWrapDH1 keys will be distributed manually (I may be wrong with this, but that's what I understood as the draft does not specify any key exchange protocol between server and third-party). That's why I think that SSWrapDH1 keys will be very long-lived (administrators will hate having to manually distribute the new key in an hourly or even daily schedule), jeopardizing perfect forward secrecy for a long time. The problem I see with a "server to third party" OOB look up or export of the keys is that the client will not be notified of this export taking place and so will lose the chance to reject surveillance... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On 17/10/17 16:46, Ion Larranaga Azcue wrote: > The problem I see with a "server to third party" OOB look up or > export of the keys is that the client will not be notified of this > export taking place and so will lose the chance to reject > surveillance... IIUC, with the draft-rehired proposal, the client can in any case not be told - the TLS protocol extensions are mere politeness and the client does not get to know what snooper(s) are involved, nor can the client influence the snooping keys. Once, any infrastructure for this was deployed, I think it'd be used without telling clients for sure. (And we would be fully complicit in helping that happen, if the WG adopted this stuff, because we know that such abuses would be inevitable.) I think this WG was correct years ago when we passed on the DNT proposal which had the same "just politeness" aspect - the web is not really such a friendly place that one can depend on the kindness of strangers. Nor are many of the many other applications using TLS. S. signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> IIUC, with the draft-rehired proposal, the client > can in any case not be told - the TLS protocol > extensions are mere politeness and the client does > not get to know what snooper(s) are involved, nor > can the client influence the snooping keys. Once, > any infrastructure for this was deployed, I think > it'd be used without telling clients for sure. (And > we would be fully complicit in helping that happen, > if the WG adopted this stuff, because we know that > such abuses would be inevitable.) Not really. The draft relies on the server sending a non-encrypted extension containing critical information (the session keys encrypted using a shared key between server and third party). The third party is expected to intercept this non-encrypted extension and decrypt it using Ke in order to obtain the session keys. Without this information the third party is unable to fully decrypt the TLS connection. If the extension is not sent, the client does not realize there is a third party, but the third party does not have the session keys either, and the server has to provide them in a different way (for instance, using an OOB lookup as Florian suggested). In any case, it's not the same scenario as the draft proposes (the keys are shared in a different way) and can happen with or without this draft being accepted. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On 17/10/17 19:34, Ion Larranaga Azcue wrote: > If the extension is not sent, the client does not realize there is a > third party, but the third party does not have the session keys > either, and the server has to provide them in a different way (for > instance, using an OOB lookup as Florian suggested). In any case, > it's not the same scenario as the draft proposes (the keys are shared > in a different way) and can happen with or without this draft being > accepted. I agree. My point is that if this draft were accepted, then the infrastructure for the above scenario would all be in place (the DH value for the snooper and the code to expose session information to that snooper) and the above scenario would be more likely to happen, more often. IOW, by standardising draft-rehired, we'd *also* be putting in place standard building blocks for an OOB, client is never told mechanism. S. signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> I agree. > > My point is that if this draft were accepted, then the > infrastructure for the above scenario would all be in > place (the DH value for the snooper and the code to expose > session information to that snooper) and the above > scenario would be more likely to happen, more often. > IOW, by standardising draft-rehired, we'd *also* be > putting in place standard building blocks for an OOB, > client is never told mechanism. I don't see it that way... For me, using the capabilities provided by this draft in order to get an OOB-only "no client involved" mechanism is more difficult and probably less efficient than creating one from scratch... That being said... One thing that bothers me from my last emails is that I seem to find myself on the draft-defending side of the discussion while I don't really like the draft itself due to the concerns I pointed out in my first email... I'm not fully against adding monitoring capabilities to the protocol, but I would prefer a "no-monitoring-allowed" TLS if the alternative was going with an insecure tapping mechanism. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK) wrote:
> The following case (NAT box reboot) is problematic:
>
> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>host B (B.1);
> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
>meanwhile);
>
> How is B.1 supposed to correctly interpret the bytes starting at offset
> +11? (For what it knows, it could be CID from A.1 or the length field
> from A.2.)
I don't think that this is a problem.
connection = five_tuples.lookup(packet.five_tuple)
if (!connection) {
connection =
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
}
if (!connection) {
// is this a ClientHello? otherwise drop it
}
Of course this doesn't help you with A.2, but that's why this draft exists.
If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:
connection =
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
if (!connection) {
// is this a ClientHello? otherwise drop it
}
> I might be missing something fundamental here, but isn't the length
> encoded in the CID field on the wire?
Not by my understanding. There isn't any need (the intent is to have
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
Hi Nikos, On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" wrote: > Another worrying feature is that the client can make the server send > up to 255 verbatim bytes on the wire of his choice. Why was this > feature added? Are there use cases related with it (intro doesn't > mention any), or it was only thought as a make it as generic as > possible approach? If it is the latter, I'd recommend to provide a > simple approach that covers the described use cases. > > The same argument applies to the server being able to set such a long > sequence of verbatim bytes to each of the client packets. I'd like to get a better understanding of your concern here. Is it size? Or is that it creates a potential sub-channel for sending identifying information? If the latter, it doesn't look much different from Random (except it's larger)? And then it gets hashed in the finished message, so, the room for a third party to fiddle with it seems really limited. Exactly, what risk do you foresee? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On 17/10/2017, 22:35, "Martin Thomson" wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) wrote:
> > The following case (NAT box reboot) is problematic:
> >
> > 1. Application '1' on host A (A.1) uses DTLS+CID with application
> >'1' on host B (B.1);
> > 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> > 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> > 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
> >meanwhile);
> >
> > How is B.1 supposed to correctly interpret the bytes starting at
> > offset +11? (For what it knows, it could be CID from A.1 or the
> > length field from A.2.)
>
> I don't think that this is a problem.
>
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
> connection =
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
> }
> if (!connection) {
> // is this a ClientHello? otherwise drop it
> }
This is quite similar to the trial and error / heuristic that I was
mentioning in [1].
Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
recognise A.1 as CID-enabled and sends it forward to the crypto handler
when it shouldn't.
It looks simple, but it introduces subtle complexity in that parsing is
not self-contained anymore: it depends on a couple of things (the
connection_ids and five_tuples stores) that in principle should have
nothing to do with making sense of an incoming record.
And the already discussed limitations:
- Fragility on corner cases (e.g., the 5-tuple swap above);
- Forcing middleware to keep state;
- Breaking wireshark & co unless they can see the whole session;
- (Depending on the use case, the cost of the two lookups per record
on the parsing might have a performance impact.)
> > I might be missing something fundamental here, but isn't the length
> > encoded in the CID field on the wire?
>
> Not by my understanding. There isn't any need (the intent is to have
> the CID only consumable by the entity that created it, and any others
> that it collaborates with, like a load balancer).
You are right. For some reasons, I was implying cid was encoded as a
variable-length array. That said, I don't think saving 1 byte here is
worth the self-inflicted pain of making tshark unusable :-)
Cheers
[1] https://www.ietf.org/mail-archive/web/tls/current/msg24575.html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
