(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" , "Rick van Rein"
>
> *Subject:* New Version Notification for d
Hello,
Thanks for the feedback. Responding to it:
Ilari> - The signed DH share does not look to be bound to anything (crypto
Ilari> parameters negotiation, randoms, server key exchange, etc..).
This is indeed easy to miss; it relies on Kerberos infra to deliver a
short-lived session key to
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
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 Paul,
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>> Tickets.
>
> How is this type of TLS connection prevented from being MITM'ed by
> someone replaying kerberos tickets (which it cannot read itself)
In Kerberos, t
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 t
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 KD
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 c
4,
> "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546
>
> -------
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
__
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
https://github.com/arpa2/s
Hello,
g/html/draft-ietf-tls-pwd-
>> The real
>> problem here is that there is no reason not to use certificates in a
>> lot of cases.
>
> when TLS
> is used to protect non-browser traffic there are plenty of cases
> where you won't have an implicit trust anchor database or you're
> going to som
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
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 n
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 pointer
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 by
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
> https://datatracker.ietf.org/doc/draft-irtf-cf
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 pro
uot; 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
Hello,
I wrote a straightforward I-D to permit Symmetric TLS, by which I mean
letting go of predefined client/server roles. This is useful if the
layers on top and/or below TLS are neutral in this respect. The
approach is through a TLS Extension that holds a tie-breaker; both ends
send a ClientH
Hello,
> In Yokohama, we discussed changing the IANA registry assignment rules
> for cipher suites
Has a similar thing been discussed for TLS Extensions as well? That
list now requires "IETF Consensus", and it doesn't even have Private and
Experimental allocations, let alone a portion with "Spec
Hi,
In general I think this is a good form of relaxation. However,
>
> Cipher suites marked with a “Y” the IETF has consensus on
An alternative could be to mark the entry with the RFC 5226 level of the
documentation, and indicate what levels are acceptable. A black/white
distinction will prob
Hi,
> I am just a little bit worried that everything developed for the IoT
> enviroment is quite likely labled as not recommended by the IETF in this
> registry because of the Web focus in this group.
>
RFC 5246 speaks of "Application Profiles" and it seems like this
discussion that started to sim
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
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 integrity/au
27 matches
Mail list logo
