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,
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
> 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 k
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,
> 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 deploye
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 su
> 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.
> I
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
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
> mentio
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.
10 matches
Mail list logo
