Re: [TLS] Connection ID Draft
On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > This is quite similar to the trial and error / heuristic that I was > mentioning in [1]. You didn't mention 5-tuples. And it isn't trial and error: you use 5-tuple as your primary key and use connection ID to latch. > 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. As I said before, any connection without a connection ID monopolizes that 5-tuple making it inaccessible to other connections. I think that in this case: too bad. > And the already discussed limitations: > - Fragility on corner cases (e.g., the 5-tuple swap above); I don't see how you can avoid this in the general case. Any connection without connection ID is going to be hard to correlate if it moves. As for the connection that does have a connection ID but moves on top of a connection that doesn't, I don't think that is an acceptable loss. > - Forcing middleware to keep state; > - Breaking wireshark & co unless they can see the whole session; Both of these are acceptable to me. Unless you can describe a middlebox use case that needs access to this information and can't deal with the solution that I described. Wireshark and co will need to see the handshake if they want to decrypt and that's the only case that is important. > - (Depending on the use case, the cost of the two lookups per record > on the parsing might have a performance impact.) The second lookup only happens after a migration. I neglected to mention that successful use of a connection ID causes the 5-tuple to be assigned to that connection; there's a trick there in that you need to watch for reordering, but it saves the double lookup. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On Wed, 2017-10-18 at 06:43 +, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Nikos, > > On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" -boun...@ietf.org on behalf of n...@redhat.com> 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? I had in mind scenarios of using these bytes to make the peer of talk another protocol with an unsuspecting party, or using the peer to attack a middle box which parses packets, e.g, by attempting buffer overflows to it. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
This makes me think about if this is feasible/desirable to use
connection id to do load balancing.
I think about use cases where you have a cluster of server behind only
one IP address. Often traffic will be load balanced by IP.
But with UDP and Nat environment, the IP can change.
Thx to CID, if client is redirected to the same server in the cluster,
even if its IP has changed it will be able to communicate without new
handshake.
But if its IP has changed there is little chance than load balancer will
balance it on the same server and so new handshake is needed. (unless
server share their connection state)
Any thought about that ?
Le 17/10/2017 à 23:35, Martin Thomson a écrit :
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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Connection ID Draft
On Wed, Oct 18, 2017 at 9:39 AM, Simon Bernard
wrote:
> This makes me think about if this is feasible/desirable to use connection
> id to do load balancing.
>
> I think about use cases where you have a cluster of server behind only one
> IP address. Often traffic will be load balanced by IP.
> But with UDP and Nat environment, the IP can change.
>
> Thx to CID, if client is redirected to the same server in the cluster,
> even if its IP has changed it will be able to communicate without new
> handshake.
> But if its IP has changed there is little chance than load balancer will
> balance it on the same server and so new handshake is needed. (unless
> server share their connection state)
>
The usual procedure is for the server and load balancer to coordinate on
the CID algorithm.
A trivial version would be for the server to generate the connection ID as
|| .
-Ekr
>
> Any thought about that ?
>
>
>
> Le 17/10/2017 à 23:35, Martin Thomson a écrit :
>
>> 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[c
>> onnection_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
>>
>
> ___
> 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] Publication of draft-rhrd-tls-tls13-visibility-00
On 10/02/2017 03:31 PM, Ralph Droms wrote: > We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS > extension defined in this I-D takes into account what we heard from the > discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 > in Prague. Specifically, it provides an opt-in capability for both the TLS > client and server and makes it clear on the wire that visibility will be > enabled for the session. The new mechanism does not depend on static > handshake or session keys. > This draft does not seem to have anything to address the concern that, once a visible ClientHello extension is needed to enable wiretapping, certain parties (e.g., national border firewalls) would reject/drop *all* ClientHellos not containing that extension, thereby extorting all clients into "opting in" to the wiretapping and effectively rendering the "opt-in" requirement useless for those clients. As a more general comment, I think that this concern is so squarely at odds with the concern that the client must be able to opt-in to the wiretapping [and, optionally, be guaranteed by the key schedule to know when wiretapping is happening] that I do not see any potential for a workable solution. -Ben P.S. I agree with Rich; can we try to defer these conversations until after 1.3 is actually published? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should CCM_8 CSs be Recommended?
I agree with "everyone"; it seems like these fall into what "not recommended" is intended to encompass. I don't have a preference for whether there's an extra annotation about IoT usage. -Ben On 10/09/2017 06:05 PM, Sean Turner wrote: > Anybody else has thoughts on this? > > spt > >> On Oct 3, 2017, at 18:53, Sean Turner wrote: >> >> In the IANA registries draft >> (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added >> a recommended column to the Cipher Suites (CSs) registry (and some others). >> Right now, the criteria for getting a recommended mark is AEAD ciphers with >> strong authentication standards track ciphers. While that’s great >> generally, the list we’ve got five CSs that gave Joe and I pause: >> >> TLS_DHE_RSA_WITH_AES_128_CCM_8 >> TLS_DHE_RSA_WITH_AES_256_CCM_8 >> TLS_PSK_DHE_WITH_AES_128_CCM_8 >> TLS_PSK_DHE_WITH_AES_256_CCM_8 >> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 >> >> The CCM_8 CSs have a significantly truncated authentication tag that >> represents a security trade-off that may not be appropriate for general >> environment. In other words, this might be great for some IoT device but we >> should not generally be recommending these. >> >> We’re recommending that these five suites be dropped from the recommended >> list. Please let us know what you think. >> >> J&S >> (editor hats on) > ___ > 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
