John,
Thanks for your comments. It's good to know that someone has already done
this!
On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson
wrote:
> Hi,
>
> I looked through the draft, mainly focusing on the crypto parts. This is
> more or less ECIES, but with a more modern style of key derivation
Hi,
I looked through the draft, mainly focusing on the crypto parts. This is more
or less ECIES, but with a more modern style of key derivation that most
existing standards. This solution is very similar to the standardized 3GPP
identity encryption (SUCI) with the difference that the static
> Because it means that if the client does not understand DC, then it must
> reject the certificate, ...
This is the desired behavior, as far as I understand.
> ... but if client understands DC, it can accept it even in non-DC contexts.
I don't see why this is nonsensical. One way to understand
On Friday, 20 July 2018 17:41:23 CEST Walter Neto wrote:
> Hi guys, after I saw I did not express myself clearly I decided to write
> this message trying to do that.
>
> The actors:
> A - The business company that needs to emitt the invoice;
> B - The Brazilian Internal Revenue Service, who
IMHO no it doesn't. TLS is just a way to provide secure pipes between the
communicating entities. Making long-term signatures that persist after the
connection is dropped had never been on the site of TLS.
Regards,
Uri
Sent from my iPhone
> On Jul 20, 2018, at 11:42, Walter Neto wrote:
>
>
On Thu, Jul 19, 2018 at 08:39:11PM +, Patton,Christopher J wrote:
>
> Now let's check the converse. Suppose that the crit=true. Is it valid
> for strict to be false? Yes, because the extension being critical
> only means that the client has to understand DC in order to accept
> the
Hi guys, after I saw I did not express myself clearly I decided to write this
message trying to do that.
The actors:
A - The business company that needs to emitt the invoice;
B - The Brazilian Internal Revenue Service, who requires "A" to emit invoices
using "B" webservices;
C - The software
On 07/09/2018 05:40 PM, Kathleen Moriarty wrote:
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off
On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote:
>
> (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is
> probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't
> think we actually believe SHA256 and SHA384 give related output. It's just
> nice
On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > >
> > > > This is somewhat timely, as if we do want to introduce a
> > > restriction,
> > > > it
> > > > would ideally be in the form of some text in the TLS 1.3
> > > >
On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos
wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> > >
> > > > This is somewhat timely, as if we do want to introduce a
> > > restriction,
> > > > it
> > > > would ideally be in the form of some text in the TLS 1.3
> > > >
On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote:
> >
> > > This is somewhat timely, as if we do want to introduce a
> > restriction,
> > > it
> > > would ideally be in the form of some text in the TLS 1.3
> > > specification,
> > > which is very nearly done.
> > >
> > > It would be good
On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara
wrote:
> On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
> >
> >
> > On 20/07/18 10:38, Eric Rescorla wrote:
> > > The issue is not cross-protocol attacks; it's the reuse of PSKs with
> > > different KDFs, which we don't have any
On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
>
>
> On 20/07/18 10:38, Eric Rescorla wrote:
> > The issue is not cross-protocol attacks; it's the reuse of PSKs with
> > different KDFs, which we don't have any analysis for and which the TLS
> > 1.3 document prohibits.
>
> Can you
On 20/07/18 10:38, Eric Rescorla wrote:
> The issue is not cross-protocol attacks; it's the reuse of PSKs with
> different KDFs, which we don't have any analysis for and which the TLS
> 1.3 document prohibits.
Can you supply the reference for that prohibition?
Thanks
Matt
On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos
wrote:
> On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> > Hi all,
> >
> > As I mentioned at the mic today, there is a question that has been
> > raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> > directly in
The following errata report has been submitted for RFC2712,
"Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5432
--
Type:
On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote:
> Hi all,
>
> As I mentioned at the mic today, there is a question that has been
> raised about whether it's wise to reuse an existing (TLS 1.2) PSK
> directly in the TLS 1.3 key ladder. At a high level, the reason why
> one
> might want
18 matches
Mail list logo
