On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett writes:
>> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote:
>> > > Currently SRP cannot be used with newer crypto primitives such as
>> > > ciphers in AEAD mode
On Wed, January 27, 2016 9:47 am, Martin Thomson wrote:
> On 28 January 2016 at 02:17, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> Anon â!= Ephemeral, despite some similarities.
>
>>From a protocol perspective, they are the same. The distinction at
> the protocol level between ECDH_RSA (for ex
On Sun, January 31, 2016 10:00 pm, Martin Thomson wrote:
> On 1 February 2016 at 16:56, Dan Harkins wrote:
>>>>From a protocol perspective, they are the same. The distinction at
>>> the protocol level between ECDH_RSA (for example) and ECDH_anon is
>>> that EC
On Tue, February 16, 2016 8:34 pm, Tony Arcieri wrote:
> On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie
>
> wrote:
>
>> In Thread, it is used for local device authentication and authorisation.
>> These use cases clearly benefit from a PAKE, i.e. getting deriving a
>> shared
>> cryptographic from
Hi,
On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
> 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 wit
On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins wrote:
>>
>> Hi,
>>
>> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
>>> Hi,
>>>
>>>> Although the lack of modern cipher-su
Hi Scott,
On 3/8/21 7:09 AM, Scott Fluhrer (sfluhrer) wrote:
Again, last minute reviews…
It would appear that the exact computations that both the client and
the server need to perform needs to be explicitly spelled out, as
there are several possibilities.
Here is the one I could see th
Hi Eric,
On 3/8/21 8:00 AM, Eric Rescorla wrote:
Taking a step back from the crypto, I'm trying to make sure I
understand the desired security properties. As I understand the
situation:
- the client has a preconfigured key pair (X_c, Y_c)
- the server is anonymous (i.e., doesn't have a valid
Hi Christian,
On 3/8/21 11:49 AM, Christian Huitema wrote:
The list of requirement reminds me of two scenarios: the Anima problem
of "bringing a clean device into the new owner's network"; and the
corporate Wi-Fi problem of "connecting a device to the corporate
Wi-Fi". In the Anima proble
On 3/10/21 4:12 AM, Eric Rescorla wrote:
On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <mailto:ofr...@cisco.com>> wrote:
*From:*TLS mailto:tls-boun...@ietf.org>>
*On Behalf Of *Eric Rescorla
*Sent:* 09 March 2021 06:27
*To:* Dan Harkins mailto:dhar
Hi,
I approve of this transition to standards track and I am implementing
this as well.
regards,
Dan.
On 11/29/23 7:51 AM, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
an External Pre-Shared Key) was originally published as experimental
Hi Sean & Joe,
On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> All,
>
> To make sure weâve got a clear way forward coming out of our BA
> sessions, we need to make sure thereâs consensus on a couple of
> outstanding issues. So...
>
> It seems that there is a clear consensus not to sup
Hi Sean,
In general I support this but
A stable, publicly available document is basically an RFC.
So when the TLS WG says no that means asking an AD to sponsor
or putting it into the Independent Stream process. So what it
looks like you're doing is punting this problem into the lap of
On Sun, April 3, 2016 7:24 pm, Salz, Rich wrote:
>
>> A stable, publicly available document is basically an RFC.
>
> Not always; ISO et al.
That's why I said "basically"; it's a qualifier.
But keep in mind what kind of stable, publicly available
document needs to be published: a descripti
On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>
> If smaller devices don't use algorithms that can be used to talk to
> random servers on the Internet, then they are choosing to not try to
> get interop. That seems like a shame to me, unless there's a really
> good reason and IMO, mostl
On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:
> On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote:
>>
>>
>> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote:
>>>
>>> If smaller devices don't use algorithms that can be used to talk to
>&
On Mon, April 4, 2016 8:50 am, Phil Lello wrote:
> On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote:
>
>>
>> Usually what happens is the server generates a self-signed certificate
>> and the apps are given some "username" and "password" and the app
On Mon, April 4, 2016 10:46 am, Phil Lello wrote:
>>
>> >> Usually what happens is the server generates a self-signed
>> certificate
>> >> and the apps are given some "username" and "password" and the app
>> >> ignores the unauthenticated nature of the TLS connection and sends
>> >> the u/p crede
On Tue, April 5, 2016 7:42 am, Adam Langley wrote:
> On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann
> wrote:
>> How hard can it be to implement TLS-PSK? I did it in a few hours in my
>> crypto
>> library.
>
> This is getting off topic (which is my fault) but, for us, it wouldn't
> be "just" imple
Hello,
On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote:
> For background please see [1].
>
> Please respond to this message indicating which of the following options
> you prefer by Monday June, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the
> current dra
I'm glad I have to opportunity to make you happy Sean :-)
On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I think I can take this bit:
>
> On Jul 10, 2016, at 06:51, Peter Dettman
> wrote:
>>
>> I'm also curious whether there is a precedent in other RFCs for an
>> explicit minimum curve bi
Hi Robert,
This draft moves the NamedCurve/EllipticCurveList into the
ClientHello, and since the client sends X1 and ZKP(X1) in the
ClientHello it means that is going to be a list of 1. It basically
moves the client's key exchange portion from ClientKeyExchange into
ClientHello. So basically,
is TLS"
> though and whether this approach flouts conventional thinking about TLS
> (which, IMHO, it doesn't).
>
> Robert
>
> On 18 July 2016 at 11:06, Dan Harkins wrote:
>
>>
>> Hi Robert,
>>
>> This draft moves the NamedCurve/EllipticCurveL
To answer Joe's question, yes I support 4 separate adoption calls
for the I-Ds in question.
On 12/16/24 2:21 PM, Martin Thomson wrote:
On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote:
Is the WG consensus to run four separate adoption calls for the
individual I-Ds in question?
I would like
+1 for adoption
Dan.
On 12/12/24 2:06 PM, Filippo Valsorda wrote:
2024-12-07 18:36 GMT+01:00 Watson Ladd :
Having MLKEM without a hybrid as an option in TLS when the
interoperable choice is a hybrid is not going to exclude people.
Furthermore we didn't hybridize x25519 and RSA. It's cle
I agree with Scott (and Uri). We have the bandwidth to handle this
and the disagreement is over whether "recommended" is Y or N. That
contentious point is not going to resolve itself over any reasonable
amount of time. Let's just do these two and address that point when
the drafts are mature en
26 matches
Mail list logo
