Re: [TLS] Connection ID Draft

[Martin Thomson]

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] Publication of draft-rhrd-tls-tls13-visibility-00

[Ion Larranaga Azcue]

> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Stephen Farrell]

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

[Ion Larranaga Azcue]

> 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

[Stephen Farrell]

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

[Ion Larranaga Azcue]

> 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

[Florian Weimer]

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] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

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