This was infact the idea, even I thought of the gain much more in terms
of removing something useless than in gaining a few bytes.
Anyway, thanks for your opinions and your time !
--
Arnaud
On 04/04/2017 03:10 AM, Eric Rescorla wrote:
> I agree with David. This seems like a low value change
>
Hello Harlan,
thank you for the information. I will go back to the discussion and read it to
get a better understanding about the reasoning. I had a peek into 3 or 4 emails
and there were centered around the deprecation of RSA encrypted key exchange.
This is different from what I had in mind.
I've gone through my review of the draft as well, and I think this version
looks good!
Thanks,
Tommy
> On Apr 3, 2017, at 11:25 AM, David Schinazi wrote:
>
> Thanks for the update!
>
> I've reviewed -04 and I think the draft is ready to move forward.
>
> Regards,
> David Schinazi
>
>
>> On
On Mon, 3 Apr 2017 16:17:45 +
"Fries, Steffen" wrote:
> The reason I'm asking is that in industrial communication it is often
> sufficient to have source authentication and message integrity while
> probes on the network are still able to monitor the traffic for
> certain properties or verify
Hi folks,
As discussed in the meeting, and with an assist from MT, I've prepared
two small PRs:
* An extension by the client to negotiated post-handshake client auth:
https://github.com/tlswg/tls13-spec/pull/933
* Explicitly describing how RFC 7250 Raw Public Keys work with TLS
1.3 and removing
On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote:
>
> * Explicitly describing how RFC 7250 Raw Public Keys work with TLS
> 1.3 and removing extensions which no longer work from the table.
> https://github.com/tlswg/tls13-spec/pull/932
The things that seem missing:
- Specifying that
On Tue, Apr 4, 2017 at 10:29 AM, Ilari Liusvaara
wrote:
> On Tue, Apr 04, 2017 at 10:09:16AM -0700, Eric Rescorla wrote:
> >
> > * Explicitly describing how RFC 7250 Raw Public Keys work with TLS
> > 1.3 and removing extensions which no longer work from the table.
> > https://github.com/tlswg/tls
> On Apr 4, 2017, at 13:09, Eric Rescorla wrote:
>
> and removing extensions which no longer work from the table.
I’ll make sure to add these to the “orphaned” list of registries in
draft-ietf-tls-iana-registry-updates.
spt
___
TLS mailing list
TLS@
On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
> Thanks for your question Brian.
>
> The motivation behind delegated credentials is to create a more
> reasonable deployment model for short lived credentials.
My apologies for being blunt, but that text reads like a solution in
search of a problem.
On 03/31/2017 08:40 AM, Hubert Kario wrote:
> On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
>> On 3/13/17, 12:30, "Sean Turner" wrote:
>> Do we want to add some commentary about the extant SHA1 collisions when we
>> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
>
> There s
On 03/29/2017 10:29 AM, Subodh Iyengar wrote:
>
>
>
> > Do we want to leave the valid SignatureSchemes as all that are
> defined, or mention the Recommended column in the registry, or narrow
> things even further? In other words, should we give some guidance for
> how to select a scheme to use?
>
Hello,
How is Certificate Compression advantageous over tls cached-info extension?
Only case I can think of is - when the certificate is being sent for the first
time,
it can be compressed. Since the client doesn't have a copy of the certificate,
cached-info can't be used. Are there more cases whe
12 matches
Mail list logo
