Ted
You may be aware that most enterprises have been migrating away from 3270 for
20 years or more. Very little still exists. What little does exist is
usually implemented via tn3270. In the browser scenario you describe I would
expect the Server side to be a tn3270 server, but you will
On 20/07/17 18:10, Benjamin Kaduk wrote:
> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>> I note in draft-21 the following text:
>>
>>When clients use a PSK obtained externally to send early data, then
>>the following additional information MUST be provisioned to both
>>parties:
>>
>>
As I said in the previous message, the 3270 was the original web browser.
What I mean by that is that the 3270 transaction model is basically a
primitive version of http: you throw up a page, the user enters some data,
then the user hits send and all the data goes to the server at once. The
reaso
Hi,
The email seems to be missing some text that was in the etherpad (or
reordered maybe), so here it is again:
IETF99 TLS WG 2nd session (19-July-2017)
(all errors are JLH's)
Agenda/Administrivia
Exported Authenticators (EKR)
draft 21, hopefully close
WGLC #2 ended yesterday
Changes since
Signature Algorithms for ECDSA now define both the curve and the hash
algorithm:
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
This is in contrast to the TLS 1.2 protocol, where any hash can be used with
any curve.
On 07/21/2017 08:23 AM, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash
> algorithm:
>
> ecdsa_secp256r1_sha256(0x0403),
> ecdsa_secp384r1_sha384(0x0503),
> ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS
On 21/07/2017 14:23, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash
> algorithm:
>
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS 1.2 protocol, where any hash can
Nick:
Thanks for this summary. This resolves my previous concerns.
Russ
> On Jul 18, 2017, at 7:06 AM, Nick Sullivan
> wrote:
>
> Sean,
>
> We've had some additional discussions in person here at IETF 99 with folks
> who were in the proxy certificates and short-lived certs camp, and we th
On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> >
> > algorithm:
> > ecdsa_secp256r1_sha256(0x0403),
> > ecdsa_secp384r1_sha384(0x0503),
> >
On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
> > Signature Algorithms for ECDSA now define both the curve and the hash
> > algorithm:
> >
> > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> > ecdsa_secp521r1_sha51
On Fri, Jul 21, 2017 at 8:00 AM, Ilari Liusvaara
wrote:
> On Fri, Jul 21, 2017 at 02:41:50PM +0100, Dr Stephen Henson wrote:
> > On 21/07/2017 14:23, Hubert Kario wrote:
> > > Signature Algorithms for ECDSA now define both the curve and the hash
> > > algorithm:
> > >
> > > ecdsa_secp256r1_sha256
I put some proposed tidying in
https://github.com/tlswg/tls13-spec/pull/1061 .
More inline.
On 07/21/2017 05:14 AM, Matt Caswell wrote:
> On 20/07/17 18:10, Benjamin Kaduk wrote:
>> On 07/20/2017 04:51 AM, Matt Caswell wrote:
>>> I note in draft-21 the following text:
>>>
>>>When clients use
On 07/21/2017 09:34 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
>> On 07/21/2017 08:23 AM, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the hash
>>>
>>> algorithm:
>>> ecdsa_secp256r1_sha256(0x0403),
>>>
On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
> On 21/07/2017 14:23, Hubert Kario wrote:
>> Signature Algorithms for ECDSA now define both the curve and the hash
>> algorithm:
>>
>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
>> ecdsa_secp521r1_sha512(0x0603),
>>
>> This is
Unrelated to Ilari's questions, I wonder if we want to say anything
about certificate_request_context values being unique across both in-TLS
post-handshake auth and exported authenticators.
-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail
--
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
>> On 21/07/2017 14:23, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define both the curve and the
On 21/07/2017 16:00, Ilari Liusvaara wrote:
>
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
>
That is potentially a problem yes.
On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
> Unrelated to Ilari's questions, I wonder if we want to say anything about
> certificate_request_context values being unique across both in-TLS
> post-handshake auth and exported authenticators.
This context is not a security sensitive thin
On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
> > Unrelated to Ilari's questions, I wonder if we want to say anything about
> > certificate_request_context values being unique across both in-TLS
> > post-handshake auth and ex
On Fri, Jul 21, 2017 at 10:34 PM, Ilari Liusvaara
wrote:
> On Fri, Jul 21, 2017 at 10:17:08PM -0700, Watson Ladd wrote:
>> On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk wrote:
>> > Unrelated to Ilari's questions, I wonder if we want to say anything about
>> > certificate_request_context values
20 matches
Mail list logo
