Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

[Johannes Merkle]

>> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.  
>> Those “you should not send these for 1.3” could be re-used for TLS 1.3, if 
>> that was desired.
> 
> Yes this makes sense. And I think that they should, documented as something 
> other than “Recommended”.
> 

I still don't get it. If the existing code points are re-used, the TLS 1.3 
standard is violated.

Johannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

[Blumenthal, Uri - 0553 - MITLL]

SHOULD NOT would probably be fine. MUST NOT is too strong, and probably needs 
revisiting.

Regards,
Uri

Sent from my iPhone

On Jul 19, 2018, at 06:32, Johannes Merkle  wrote:

>>> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.  
>>> Those “you should not send these for 1.3” could be re-used for TLS 1.3, if 
>>> that was desired.
>> 
>> Yes this makes sense. And I think that they should, documented as something 
>> other than “Recommended”.
>> 
> 
> I still don't get it. If the existing code points are re-used, the TLS 1.3 
> standard is violated.
> 
> Johannes
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

[Salz, Rich]

>I still don't get it. If the existing code points are re-used, the TLS 1.3 
> standard is violated.
  
Right.  So a document will have to be written that updates the RFC to use them. 
 Or, go for other codepoints.

Either way, I think it will be an uphill struggle to convince the WG, who would 
probably defer to CFRG so convince them as well, that Brainpool curves are 
necessary for TLS 1.3.  just some advice.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

[Tim Hollebeek]

Unfortunately, I haven’t had time to review the document, but +1 for 
interesting problem, and +1 for anything Richard writes as a good starting 
point, even if I haven’t read it.

 

-Tim

 

From: TLS  On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: Richard Barnes 
Cc:  
Subject: Re: [TLS] Fwd: New Version Notification for 
draft-barnes-tls-pake-04.txt

 

+1 for this work.

 

If you are one of those that think, as I did 20 years ago, that password 
authentication is dying and practical replacements are just around the corner, 
do not support this document. Otherwise, please do. 

 

Asymmetric or augmented PAKE (aPAKE) protocols provide secure password 
authentication in the common client-server case (where the server stores a 
one-way mapping of the password) without relying on PKI - except during 
user/password registration. Passwords remain secure regardless of which 
middleboxes or endpoints spy into your decrypted TLS streams.  The server never 
sees the password, not even during password registration. 

 

To see real deployment of such protocols, they need to be integrated with TLS 
which is what Barnes's draft facilitates. Not only this improve significantly 
the protection of passwords and password authentication, but aPAKE protocols 
also provide an hedge against PKI failures by enabling mutual client-server 
authentication without relying on regular server certificates.

 

Hugo

 

 

On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes mailto:r...@ipv.sx> > wrote:

Hey TLS WG,

 

In response to some of the list discussion since the last IETF, Owen and I 
revised our TLS PAKE draft.  In the current version, instead of binding to a 
single PAKE (SPAKE2+), it defines a general container that can carry messages 
for any PAKE that has the right shape.  And we think that "right shape" covers 
several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, 

 

The chairs have graciously allotted us 5min on the agenda for Thursday, where 
I'd like to ask for the WG to adopt the document.  So please speak up if you 
think this is an interesting problem for the TLS WG to work on, and if you 
think the approach in this document is a good starting point.  Happy for 
comments here or at the microphone on Thursday!

 

Thanks,

--Richard

 

 

-- Forwarded message -
From: mailto:internet-dra...@ietf.org> >
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes mailto:r...@ipv.sx> >, Owen Friel 
mailto:ofr...@cisco.com> >




A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:   draft-barnes-tls-pake
Revision:   04
Title:  Usage of PAKE with TLS 1.3
Document date:  2018-07-16
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt
Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:   https://tools.ietf.org/html/draft-barnes-tls-pake-04
Htmlized:   https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff:   https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04

Abstract:
   The pre-shared key mechanism available in TLS 1.3 is not suitable for
   usage with low-entropy keys, such as passwords entered by users.
   This document describes an extension that enables the use of
   password-authenticated key exchange protocols with TLS 1.3.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat


___
TLS mailing list
TLS@ietf.org  
https://www.ietf.org/mailman/listinfo/tls

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday

[Viktor Dukhovni]

On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:

> > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > information could be conveyed via the DNS. That way you would not need new
> > holes/fields in the TLS extension. Paul said it doesn't work. But Willem
> > Toorop and I discussed it after the meeting, and think that it does.
> 
> I agree that it _could_ be done with a DNS RR.  However, that has two
> negative effects: 1) it will bloat the extension's payload more than the
> two bytes we're asking for, 2) it complicates deployment / the
> operator's life.

In any realistic deployment, the publisher of the TLSA records is
the *same* entity that provisions the certificate chain, anything
else is operationally untenable.

In absence of indirection via SRV records, the only way to combine
DANE with hosting by a provider that is not also managing the
domain's DNS records is to use CNAMEs as follows:

Customer1 DNSSEC zone:

www.example.com. IN CNAME dane-host.example.net.
_443._tcp.www.example.com. IN CNAME _443._tcp.dane-host.example.net.

Provider DNSSEC zone:

dane-host.example.net. IN A 192.0.2.1
_443._tcp.dane-host.example.net. IN TLSA 3 1 1 
b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
_443._tcp.dane-host.example.net. IN TLSA 3 1 1 
8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f

The client will send an SNI of "www.example.com", which the server
needs to be pre-configured to accept.  The server will then return
the corresponding cached CNAME and shared TLSA RRset with all
approrpriate signatures, DNSKEY and DS records.

; per-customer CNAME RR, cached on server.
;
_443._tcp.www.example.org. IN CNAME _443._tcp.dane-host.example.net.

; shared target TLSA RRset, cached on servr.
;
_443._tcp.dane-host.example.net. IN TLSA 3 1 1 
b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34
_443._tcp.dane-host.example.net. IN TLSA 3 1 1 
8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f

With the DANE TLSA records published by the provider, and extension
support deployment across the various server farms also in the hands
of the provider, there is little point in fetching the extension
support lifetime from DNS.  Either way the *provider* includes it
with the chain data, but it is much easier to manage it as just
configuration.

The extension support lifetime is a TLS-specific property, and has
no relevance for clients that can (afford to) do direct DNS lookups.
It belongs in the TLS extension and not in DNS.

--
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Patton,Christopher J]

Thanks both of you for the feedback.


I've revised the PR:

https://github.com/tlswg/tls-subcerts/pull/9


There's now a "strict" flag that, if set, requires the server to offer a DC.. 
In Sec. 6.1, I describe why I think this is sufficient. Let me know what you 
think!


Best,

Chris


From: Santosh Chokhani 
Sent: Wednesday, July 18, 2018 6:00 PM
To: Patton,Christopher J; 'Ilari Liusvaara'
Cc: tls@ietf.org
Subject: RE: [TLS] Proposed changes to draft-ietf-tls-subcerts


I do not think you can change an extension syntax or semantic.  It is three 
tuple: extn ID, criticality flag, and value.



You can add the syntax and semantics  within the extension value as to what it 
means.   That may not help those who do not understand the extension and cannot 
process the value.



From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Patton,Christopher J
Sent: Wednesday, July 18, 2018 1:33 PM
To: Ilari Liusvaara 
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts



Hi Ilari, I suppose you mean that this condition violates the critical bit 
semantics: "If the extension is marked critical, then the server MUST NOT offer 
the certificate unless it offers a delegated credential as well."



Your suggesting adding a "must-use-DC" flag to the extension body? The 
condition would be: "If the  flag of the extension is set, then 
the server MUST NOT offer the certificate unless ..."









From: ilariliusva...@welho.com 
mailto:ilariliusva...@welho.com>> on behalf of Ilari 
Liusvaara mailto:ilariliusva...@welho.com>>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts



On Wed, Jul 18, 2018 at 01:17:44AM +, Patton,Christopher J wrote:
> Hi all,
>
>
> I've added a few pull requests to the draft "Delegated credentials for TLS" 
> that address the proposals discussed at IETF.
>
> Specifically:
>
>   *   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_8&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e=
>  -- Creates a tighter binding of the DC to the handshake parameters;
>   *   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e=
>  -- Permits mandatory delegation-key isolation, addresses the 
> proposed"must-use-DC" TLS feature extension;
>   *   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_10&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e=
>  -- drops support for TLS 1.2.
>
> Comments on these changes are welcome; feel free to chime in on GitHub..

The way mandatory delegation-key usage is specified seems to violate how
X.509 critical bit is supposed to work. The bit is not supposed to alter
processing of recogized extensions, it is only supposed to alter processing
of unrecognized extensions from ignore to reject.

If you want to actually alter the processing to require such
certificate to always only be used for DC, you need a flag somewhere
else, which might be payload of the extension (and that extension
should _also_ be marked critical to ensure that clients that do not
understand DC do not accept it).


-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday

[Nico Williams]

On Thu, Jul 19, 2018 at 12:16:18PM -0400, Viktor Dukhovni wrote:
> On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote:
> > > At yesterday's WG meeting, Sam Weiler suggested that the pinning
> > > information could be conveyed via the DNS. That way you would not need new
> > > holes/fields in the TLS extension. Paul said it doesn't work. But Willem
> > > Toorop and I discussed it after the meeting, and think that it does.
> > 
> > I agree that it _could_ be done with a DNS RR.  However, that has two
> > negative effects: 1) it will bloat the extension's payload more than the
> > two bytes we're asking for, 2) it complicates deployment / the
> > operator's life.
> 
> In any realistic deployment, the publisher of the TLSA records is
> the *same* entity that provisions the certificate chain, anything
> else is operationally untenable.

To make it short, the problem is that with A RRs the customer has to
update TLSA RRs to match the hosting site's, and has to do this on a
timely basis.  That can certainly be arranged, but I agree that at least
initially, and until this is generally automated, that will indeed be a
problem.  But I'm not too concerned because it is just a matter of
automation.

My issues with a new DNS RR for specification of pinning remain.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Ilari Liusvaara]

On Thu, Jul 19, 2018 at 07:04:31PM +, Patton,Christopher J wrote:
> Thanks both of you for the feedback.
> 
> 
> I've revised the PR:
> 
> https://github.com/tlswg/tls-subcerts/pull/9
> 
> 
> There's now a "strict" flag that, if set, requires the server to
> offer a DC. In Sec. 6.1, I describe why I think this is sufficient.
> Let me know what you think!

Ugh, it occurs to me that to have proper processing in all cases,
including client that does not support DC and client that does and
ignores criticality of supported extensions, you need to have
critical flag and strict flag mirror each other.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Patton,Christopher J]

So you think we need that the extension is marked critical if and only if the 
strict flag is set? That wouldn't be ideal. Can you explain your thinking? 
Which case presents a problem?


From: ilariliusva...@welho.com  on behalf of Ilari 
Liusvaara 
Sent: Thursday, July 19, 2018 3:39 PM
To: Patton,Christopher J
Cc: Santosh Chokhani; tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

On Thu, Jul 19, 2018 at 07:04:31PM +, Patton,Christopher J wrote:
> Thanks both of you for the feedback.
>
>
> I've revised the PR:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2Dsubcerts_pull_9&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3Abwfg&m=_AoKRFspNsT-b4Jjhi1qtaEQ7O68i_qvVS7Gwt9TkB0&s=fZWPg8E9BJ_dXERlQXMDWwzI0uzp5mFFkN9roNzSXpk&e=

>
>
> There's now a "strict" flag that, if set, requires the server to
> offer a DC. In Sec. 6.1, I describe why I think this is sufficient.
> Let me know what you think!

Ugh, it occurs to me that to have proper processing in all cases,
including client that does not support DC and client that does and
ignores criticality of supported extensions, you need to have
critical flag and strict flag mirror each other.


-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Ilari Liusvaara]

On Thu, Jul 19, 2018 at 07:56:05PM +, Patton,Christopher J wrote:
> So you think we need that the extension is marked critical if and
> only if the strict flag is set? That wouldn't be ideal. Can you
> explain your thinking? Which case presents a problem?

There are two types of clients:

1) Clients that do not know about DC.

- These clients never use DC.
- These do not understand the DC extension.
- If you want non-strict certificate, it has to have critical=false
  on DC extension.
- If you want strict certificate, it has to have critical=true on
  DC extension.

2) Clients that support DC.

- These clients may or may not use DC.
- These understand the DC extension.
- As consequence, criticality of DC extension is ignored by X.509
  rules.
- So to specify if certificate is strict, you need a flag inside
  the extension.


And in the end, the two flags always end up mirroring each other,
but signifying different things.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

[Patton,Christopher J]

Suppose that strict delegation usage is required (strict=true). Is it valid for 
the extension to be non-critical (crit=false)? No, because the server has to 
serve a DC, even if the client doesn't request one. Thus, strict=true implies 
that crit=true.


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 certificate. But this 
doesn't mean they must negotiate a DC.


So I agree with one case you point out: If strict delegation usage is required, 
then the extension must be critical. However, if the extension is critical, 
both strict and non-strict delegation usage are valid.


Do you agree? If so, I'll amend the draft accordingly.


Chris



From: ilariliusva...@welho.com  on behalf of Ilari 
Liusvaara 
Sent: Thursday, July 19, 2018 4:18 PM
To: Patton,Christopher J
Cc: Santosh Chokhani; tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

On Thu, Jul 19, 2018 at 07:56:05PM +, Patton,Christopher J wrote:
> So you think we need that the extension is marked critical if and
> only if the strict flag is set? That wouldn't be ideal. Can you
> explain your thinking? Which case presents a problem?

There are two types of clients:

1) Clients that do not know about DC.

- These clients never use DC.
- These do not understand the DC extension.
- If you want non-strict certificate, it has to have critical=false
  on DC extension.
- If you want strict certificate, it has to have critical=true on
  DC extension.

2) Clients that support DC.

- These clients may or may not use DC.
- These understand the DC extension.
- As consequence, criticality of DC extension is ignored by X.509
  rules.
- So to specify if certificate is strict, you need a flag inside
  the extension.


And in the end, the two flags always end up mirroring each other,
but signifying different things.


-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

[Benjamin Kaduk]

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 to restrict this is that the security proofs for TLS 1.3 rely
on the pre-shared key being only used with a single key-derivation
function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
key-derivation function, so formally the proofs do not hold.  We don't
currently know of a specifc attack against such reuse, of course, but
perhaps it is prudent to restrict our usage to adhere to the verified
scenarios.

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 to hear more opinions on this question, particularly
from those who have worked on the formal verification directly.

If I can attempt to summarize some discussion that occurred in the mic
line today, Hannes was surprised that we would care, likening this case
to the regular version negotiation, where we are happy to use the same
certificate to sign messages for both TLS 1.2 and 1.3.  David Benjamin
points out that we explicitly go to the trouble of putting 64 bytes of
0x20 padding at the front of the content that gets signed for
CertificateVerify, to enforce separation between the TLS versions.

My own personal opinion is that we should enforce a domain separation
between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs"
proposal seems like a potential mechanism by which to do so without
doubling the provisioning needs.

-Ben (with no hat)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

[Yaron Sheffer]

I strongly support this work.

Also, having made this mistake myself in the past: please make sure that 
we have one fully specified PAKE in this document, and not only a 
generic envelope. This will ensure that TLS libraries have at least one 
working, and interoperable, PAKE,


Thanks,
Yaron

On 19/07/18 10:10, Tim Hollebeek wrote:
Unfortunately, I haven’t had time to review the document, but +1 for 
interesting problem, and +1 for anything Richard writes as a good 
starting point, even if I haven’t read it.


-Tim

*From:* TLS  *On Behalf Of *Hugo Krawczyk
*Sent:* Wednesday, July 18, 2018 7:13 PM
*To:* Richard Barnes 
*Cc:*  
*Subject:* Re: [TLS] Fwd: New Version Notification for 
draft-barnes-tls-pake-04.txt


+1 for this work.

If you are one of those that think, as I did 20 years ago, that password 
authentication is dying and practical replacements are just around the 
corner, do not support this document. Otherwise, please do.


Asymmetric or augmented PAKE (aPAKE) protocols provide secure password 
authentication in the common client-server case (where the server stores 
a one-way mapping of the password) without relying on PKI - except 
during user/password registration. Passwords remain secure regardless of 
which middleboxes or endpoints spy into your decrypted TLS streams.  The 
server never sees the password, not even during password registration.


To see real deployment of such protocols, they need to be integrated 
with TLS which is what Barnes's draft facilitates. Not only this improve 
significantly the protection of passwords and password authentication, 
but aPAKE protocols also provide an hedge against PKI failures by 
enabling mutual client-server authentication without relying on regular 
server certificates.


Hugo

On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes > wrote:


Hey TLS WG,

In response to some of the list discussion since the last IETF, Owen
and I revised our TLS PAKE draft.  In the current version, instead
of binding to a single PAKE (SPAKE2+), it defines a general
container that can carry messages for any PAKE that has the right
shape.  And we think that "right shape" covers several current
PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, .

The chairs have graciously allotted us 5min on the agenda for
Thursday, where I'd like to ask for the WG to adopt the document. 
So please speak up if you think this is an interesting problem for

the TLS WG to work on, and if you think the approach in this
document is a good starting point.  Happy for comments here or at
the microphone on Thursday!

Thanks,

--Richard

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes mailto:r...@ipv.sx>>, Owen Friel
mailto:ofr...@cisco.com>>




A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-tls-pake
Revision:       04
Title:          Usage of PAKE with TLS 1.3
Document date:  2018-07-16
Group:          Individual Submission
Pages:          11
URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt
Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04

Abstract:
    The pre-shared key mechanism available in TLS 1.3 is not
suitable for
    usage with low-entropy keys, such as passwords entered by users.
    This document describes an extension that enables the use of
    password-authenticated key exchange protocols with TLS 1.3.




Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
.

The IETF Secretariat


___
TLS mailing list
TLS@ietf.org 
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls