Hello Michael,
Thank you! I was searching for options, things that should go into
DTLS, but I was unaware of the attempts of mapping it better to SCTP.
> What about using:
> https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01
This looks very good, thank you for the
Hi,
Larger frames than the MTU are not just a problem to Diameter; they also
complicate the normal handshake in DTLS which is a bit of a misfit with
DTLS delivery semantics.
Since the version is bit-swapped in DTLS, each record can easily be
distinguished as being either DTLS or TLS. Then, why
t DTLS
does to Diameter is best resolved.
I hope this is useful,
Cheers,
Rick van Rein
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hello Nico,
> I don't believe that using Kerberos helps on the _entropy_ side as much
> as on the PQ side.
Ah; I meant to (be terse and) say that it adds an independent source of entropy
that leaves no traces in the TLS flow subject to, indeed, Quantum Computer
cracking.
> Now, the biggest
Hi Rich,
Salz, Rich wrote:
> * Introduction of (anonymous) Kerberos tickets as added entropy to mix
> with ECDH, and thereby provide Quantum Relief; it generalises this idea
> to allow for other ways of adding entropy
>
> Have you seen
>
under ClientHello encryption.
* Everything applies to TLS 1.3 as well as 1.2.
Our intention is to launch this as an independent proposal.
Your insights are highly appreciated!
Best,
Rick van Rein
Tom Vrancken
A new version of I-D, draft-vanrein-tls-kdh-06.txt
has been successfully submitted
Hi,
> I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just result in
> "catastrophic failure of it's authenticity", it results in catastrophic
> failure of the entire mode, both confidentiality and
Hello Phil,
> I have a use-case for allowing an MITM to monitor traffic, but not
> impersonate a server, and to allow MITM signing for replay of
> server-responses to support caching.
>
This sounds like attack monitoring (going beyond DoS for which SNI
frequencies might already be helpful). This
g" certifying information is worth considering.
Is this something that could be discussed at IETF 95?
Cheers,
-Rick
> A new version of I-D, draft-vanrein-tls-kdh-02.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name: dra
Hi,
> Although the lack of modern cipher-suites for SRP makes it not very
> attractive these days.
>
Does anyone know if work on something like "ECSRP" is going on, anywhere?
We've recently worked on getting it working with PKCS #11,
https://github.com/arpa2/srp-pkcs11
Hi,
> Is anyone using SRP with TLS? The OpenSSL implementation in particular?
>
We're considering it too, although not necessarily through OpenSSL.
Also I'd really prefer an ECDH-based formalism; I'm note sure if work on
that is being done, or where.
-Rick
Hello Benjamin,
> No, mutual authentication requires the client to receive a message from
> the server.
Yes, I know -- the server needs to handle the session key or the subkey
to prove posession of its KDC-stored service key. By using it, the client
can be convinced or server identity.
> This
Hello Benjamin / TLS WG,
I didn't mean to drop the list, so your full response is hereby included.
>>> No, mutual authentication requires the client to receive a message from
>>> the server.
>> Yes, I know -- the server needs to handle the session key or the subkey
>> to prove posession of its
Hello,
>> What messages do you need to transfer for Kerberos? Is it only a ping-pong?
Yes, the plan is to send a Ticket + Authenticator and since the server cannot
send "pong", to use the (elongated) "Finished" message to replace the
validating function of the "pong".
> The client (or server,
Hi Karthikeyan,
> I don’t fully understand the constraints of the Kerberos+DH use-case, but
> using DHE-PSK seems like the best idea.
It certainly has some virtue to view Kerberos as a preshared key (on
steroids). But let me explain what bothers me about that appraoch :-
* PSK was designed
Hello,
Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and
Kerberos orthogonal. That simplifies matters enormously. I can now see a few
design alternatives. If you have any response to them, it is kindly
appreciated!
1) Continue to use KeyExchange
This variation
Hello Ilara / Watson / TLS WG,
Thanks again,
If I was to do things like the current proposal (as opposed to
overloading DHE-PSK), I would put in hash of entiere client and server
first flights.
Now I see what you mean. Indeed, the master secret used in Finished
does not take it into account in
Hello Benjamin,
> This would seem to require an application protocol doing some Kerberos
> exchanges up front to establish the Kerberos session key before pivoting
> into TLS-PSK in a STARTLS-esque fashion. If that's what the application
> protocol would look like, it seems like there's no reason
(technical, or WG-procedural) is kindly
welcomed. I will also send this to the Kitten WG.
Thanks,
Rick van Rein
> *From:* internet-dra...@ietf.org
> *Date:* 1 October 2015 18:54
> *To:* "Rick van Rein" <r...@openfortress.nl>, "Rick van Rein"
> <r...@
19 matches
Mail list logo
