It is not quite as simple as saying "(1) makes proofs more complicated"
since it depends on what you are trying to prove.
(1) makes some styles of standard AKE property proofs (key secrecy,
authentication) harder
(2) might make some privacy proofs harder
Given that the proof-effort has mostly foc
Hi,
After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.
Best,
Cas
On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila wrote:
> With Hugo
n
after exchanging further messages.
To avoid problems at the application level, we would prefer this agreement
to be ensured.
Best wishes,
Cas Cremers,
Marko Horvat,
Jonathan Hoyland,
Sam Scott, and
Thyla van der Merwe.
___
TLS mailing list
lient wishes to obtain such a guarantee, it
has to be informed by the server’s application.
Best,
Cas Cremers,
Marko Horvat,
Jonathan Hoyland,
Thyla van der Merwe, and
Sam Scott
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi,
I think the idea that "this is the best we can do" depends on quite a
number of assumptions. In theory, I think it is easy to fix, but of course
in the design space we're in, the trade offs are more complex.
We also have to consider the non-web use cases where one might expect more
symmetric
Dear all,
Disclaimer: I am not a proponent of the idea behind draft
visibility/green/rhrd; I think such a mechanism should not be part of the
TLS 1.3 standard.
I have a technical problem with the current design, whose goal is to
allow eavesdropping for inspection, i.e., selectively decrea
erc-double-07
>
> That would be less invasive than mcTLS, while still getting the properties
> you describe.
>
> --Richard
>
>
> On Nov 3, 2017 09:43, "Cas Cremers" wrote:
>
> Dear all,
>
> Disclaimer: I am not a proponent of the idea behind draf
ege or spoofing resulting in a loss of
>>> integrity/authenticity in the application. For example, the use bearer
>>> tokens such as passwords or session cookies is widespread. It will take
>>> much more work to make applications resilient to loss of confidentiality.
>&g
Hi Usama,
I think there is some possible misunderstanding of the panel's comments
from your side. The panel did not discuss using any tool over any other. If
someone writes "a Tamarin-like" analysis then this doesn't necessarily
mean Tamarin.
I think the consensus on the panel was that a more in-d
