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

[Peter Gutmann]

Eric Rescorla  writes:

>Well, I note that the text also says "or have had very little usage,"

When the Brainpool-with-TLS RFC was published, several implementers announced
that they'd added support within 24 hours of the RFC appearing (in some cases
determined by time zones).

I think that was the fastest uptake of any security RFC I've ever seen.

Peter.

___
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

[Eric Rescorla]

On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni 
wrote:
>
> c. Testing is not a good fit at this layer, all that's
>pinned is the ability to deliver the extension, after a
>previous connection delivered DANE TLSA records and a
>non-zero extension support lifetime.  There is no TLS-layer
>mechanism for the client to inform servers that don't
>offer the extension that this extension was expected
>while continuing the connection.  The closest we get is
>the TLS 1.3 missing_extension(109) alert, which does not
>carry the id of the mission extension, and is a failure
>alert.  Out-of-band notification would require HTTP
>support in applications that can't generally be expected
>to include an HTTP implementation.
>

To the extent to which this is true, it's an argument that one should be
pinning at a different layer.

-Ekr


> ___
> 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

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

[Hubert Kario]

On Wednesday, 18 July 2018 10:52:08 CEST Peter Gutmann wrote:
> Eric Rescorla  writes:
> >Well, I note that the text also says "or have had very little usage,"
> 
> When the Brainpool-with-TLS RFC was published, several implementers
> announced that they'd added support within 24 hours of the RFC appearing
> (in some cases determined by time zones).
> 
> I think that was the fastest uptake of any security RFC I've ever seen.

just because implementations added them, doesn't mean they were deployed

last time I performed scan looking for them, they haven't crossed 10%, 4 years 
*after* the RFC7027 was published:

https://securitypitfalls.wordpress.com/2017/04/


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
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

[Shumon Huque]

On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla  wrote:

>
> To the extent to which this is true, it's an argument that one should be
> pinning at a different layer.
>
>
(I've mentioned this in private email to some of you, but for broader
input, I'm throwing it out on the list too.)

On the topic of other layers ..

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.

There could be a new DANEPIN RR type at the same TLSA record name (or TXT
if we're opposed to new types) that could carry the pinning TTL and
whatever else. This could be conveyed as just an additional record (and its
signature) in the dnssec_chain extension data (which is designed as a
sequence of RRsets), and authenticated in the same manner. It is of course
vulnerable to stripping on first contact, but so is the entire TLS
extension including any pinning fields, in the incremental deployment
scenario. So it has no worse or better security properties.

This could also express a generic DANE pinning capability that is not tied
only to a TLS channel.

Servers that don't want to be pinned would not advertise this record, and
clients that don't implement pinning would just ignore this record if it is
present in the chain.

(It is probably possible to convey this DNS info in other ways, such as
defining a new TLSA record usage field for pinning. So the TLSA RRset would
include an additional record for pinning if needed. But I suspect there
might be more arguments about such a design).

This does need the dnssec_chain extension to allow authenticated denial
chains to be delivered. Based on past list discussion, it appears to me
that there is rough consensus to allow that, and the yet unpublished draft
text in the github repo already includes it.

Shumon Huque
___
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

[Paul Wouters]

On Wed, 18 Jul 2018, Eric Rescorla wrote:


detailed response to concerns raised in the room on Monday

On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni  wrote:
          c. Testing is not a good fit at this layer, all that's
             pinned is the ability to deliver the extension, after a
             previous connection delivered DANE TLSA records and a
             non-zero extension support lifetime.  There is no TLS-layer
             mechanism for the client to inform servers that don't
             offer the extension that this extension was expected
             while continuing the connection.  The closest we get is
             the TLS 1.3 missing_extension(109) alert, which does not
             carry the id of the mission extension, and is a failure
             alert.  Out-of-band notification would require HTTP
             support in applications that can't generally be expected
             to include an HTTP implementation.


To the extent to which this is true, it's an argument that one should be
pinning at a different layer.


Those clients with clean DNS transport, like mail servers, already use
the TLSA records the moment these appear in DNS. The zone owner already
fully commited the service to this, regardless of what you do at other
layers. So you are already commited to the DATA in DNS.

Each transport has their own properties and we found that pinning the
TLS extension is needed when using TLS stappling. It is a property of
the transport lawyer, so anything about that transport layer should
not happen elsewhere.

Paul

___
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?

[Bruckert, Leonie]

As I understand from the text, the Brainpool curves itself are not prohibited, 
but the code points assigned to them. So, if people still want to use the 
Brainpool curves in conformance with the standard, I would conclude that they 
can request new code points. This would result in an IANA registry with 
duplicated entries for brainpool curves: the old, now prohibited code points 
and the new assigned ones. Is this correct?



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

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

[Richard Barnes]

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: 
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes , Owen Friel 



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

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

[Patton,Christopher J]

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  on behalf of Ilari 
Liusvaara 
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] Why are the brainpool curves not allowed in TLS 1.3?

[Salz, Rich]

> This would result in an IANA registry with duplicated entries for brainpool 
> curves: the old, now prohibited code points and the new assigned ones. Is 
> this correct?



No.  The request could ask for the existing reserved codepoints to be re-used.


___
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]

>> This would result in an IANA registry with duplicated entries for brainpool 
>> curves: the old, now prohibited code points and the new assigned ones. Is 
>> this correct?



>No.  The request could ask for the existing reserved codepoints to be re-used.



But note that the WG decision was to remove all sorts of things, including 
Brainpool curves, and it would probably be best to discuss bringing them back 
via the WG.



The TLS registries are now document-required BTW.


___
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]

> This would result in an IANA registry with duplicated entries for brainpool 
> curves: the old, now prohibited code points and the new assigned ones. Is 
> this correct?

 

No.  The request could ask for the existing reserved codepoints to be re-used.

 

No offense meant, but this does not make sense. Code points were assigned, 
probably some apps were/are using them. Now those code points are to be 
invalidated, and new ones assigned instead?!



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]

>No offense meant, but this does not make sense. Code points were assigned, 
>probably some apps were/are using them. Now those code points are to be 
>invalidated, and new ones assigned instead?!



Perhaps I am confused.



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.
___
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]

> On Jul 18, 2018, at 13:42, Salz, Rich  wrote:
> 
> >No offense meant, but this does not make sense. Code points were assigned, 
> >probably some apps were/are using them. Now those code points are to be 
> >invalidated, and new ones assigned instead?!
>  
> Perhaps I am confused.

Likelier that I am confused… It’s been a tough day.
 
> 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”.

___
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

[Benjamin Kaduk]

Hi Viktor,

Thanks for writing up your thoughts; a couple notes inline:

On Tue, Jul 17, 2018 at 10:30:39PM -0400, Viktor Dukhovni wrote:
> 
> Below I shall try to address a few of the concerns raised in writing.
> You can read just the high-level notes above my signature, diving
> into the corresponding detailed exposition below my signature as
> you see fit.  Apologies for lack of hypertext links.
> 
> 0.  The draft as approved by the IESG, describes unilateral pinning
> by the client.  We all agree that was not a good idea, but it
> was a well-intended attempt to address a real security gap.
> 
> 1.  The hypothetical "assertive use-case" Richard mentions that is

I think that the use of the shorthand terms "assertive" and "restrictive"
for use cases is only causing confusion at this point, not least because
it could apply both to the TLSA Certificate Usage values and to whether
DANE is treated as less trusted, equally trusted, or more trusted than PKIX.
If I remember the detailed discussion below correctly, you refer to the
case of "DANE is equally trusted as PKIX", for which the analysis of "all
the costs of both with no benefits" is a tolerable summary.

> based on just the current draft is a non-starter.  [ Sadly, Paul
> forgot to disabuse the audience of its possibility on Monday ]
> 
> If the WebPKI is presumed never compromised then we don't need
> a DANE alternative.  With the present draft, DANE offers no
> protection when the WebPKI is compromised.
> 
> 2.  Denial of existence reached consensus on list shortly after
> London, we just need to polish up the text.  It is also quite
> useful for the greenfield applications that can make do without
> pinning.  I was surprised to hear some suggest that denial of
> existence remains outside the WG consensus.

I would also be surprised to hear such suggestions; text on denial of
existence is already staged in github and is just waiting on a decision
to publish a new draft.  (Which is, I presume, waiting for an indication
of whether we're likely to gain consensus soon on any other issues that
could be addressed in the same update.)

-Ben

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

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

[Santosh Chokhani]

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-2D
subcerts_pull_8

&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7
fdDUvxeXGJQkwmPR2HdU&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-2D
subcerts_pull_9

&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB
7UC4Q0zyFqOLOGB3-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-2D
subcerts_pull_10

&d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A
bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUii
UNRYfsdAf9nhNCaAItZY&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

[TLS] Update from side meeting on TLS DNSSEC

[Joseph Salowey]

A group met this afternoon to discuss the TLS DNSSEC document.  I
want to thank the participants as I think it was a productive meeting.
Here
is chairs' summary of some of the important points of the discussion from
notes from the meeting.  The second section outlines some behavior that
we need to clarify in the draft.

THE NON-TLS BEHAVIOR
Consider the following TLSA record:

- domain example.com
- record for key K1
- TTL of 3600s

If I retrieved this record over DNS and then connected to example.com
over TLS and it gave me key K2, which is WebPKI certified, but is
different from K1 [0], then I would be required to terminate the
connection per RFC6698 S 2.1.1. Similarly, if I later went to connect
to example.com and it displayed K2, then assuming I still had the
records in my cache, I would be required to terminate the connection.

INTERACTION BETWEEN DNS TTLs AND THIS EXTENSION
The current document is a bit unclear on the question of the behavior
when these records are delivered via TLS as in this draft as-is, i.e.,
without
pinning to the extension. Assume that my client is not configured to
require this extension.

It seems clear that if during the connection, the server
negotiates the extension and provides this record but also key K2, I
need to terminate the connection. It's not clear how this would happen
other than misconfiguration; it wouldn't benefit an attacker.  Now,
consider what happens if I make an initial connection to the server
and it provides K1, but immediately thereafter, I make a separate
connection to the server and this time it does *not* negotiate the
extension, and displays K2.

What happens then? It seems to me that there are two answers:

1. Accept K2 (because it's WebPKI certified).
2. Reject K2 (because it doesn't match the TLSA record).

Given that these have exactly the opposite effect, it seems like
the first thing we need to do is clarify what the expected behavior.
It seems like there are three things we could do:

1. Forbid clients from applying TLSA records received in one TLS
   connection to another TLS connection. This would seem to violate
   the spirit of "this is just another way to deliver DNS records".

2. Require/encourage (for some 2119 level) that clients apply TLSA
   records for as long as tehy remain valid.

3. Say nothing.

We don't think (3) is acceptable. It's not OK for the servers not to
have any idea how clients behave as it can break things. Specifically,
if clients aren't forbidden to do this, some clients might which means
servers have to expect it.  We should start by addressing this issue.
Moreover, it's pretty unobvious that things might behave this way. We
need to decide on the behavior here.
___
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

[Hugo Krawczyk]

+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: 
> Date: Mon, Jul 16, 2018 at 3:25 PM
> Subject: New Version Notification for draft-barnes-tls-pake-04.txt
> To: Richard Barnes , Owen Friel 
>
>
>
> 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

Re: [TLS] Update from side meeting on TLS DNSSEC

[Viktor Dukhovni]

On Wed, Jul 18, 2018 at 06:28:39PM -0400, Joseph Salowey wrote:

> THE NON-TLSA BEHAVIOR
> Consider the following TLSA record:
> 
> - domain example.com
> - record for key K1
> - TTL of 3600s
> 
> If I retrieved this record over DNS and then connected to example.com
> over TLS and it gave me key K2, which is WebPKI certified, but is
> different from K1 [0], then I would be required to terminate the
> connection per RFC6698 S 2.1.1. Similarly, if I later went to connect
> to example.com and it displayed K2, then assuming I still had the
> records in my cache, I would be required to terminate the connection.

TLSA record rollover requirements (and some suggested strategies)
to effect non-disruptive key rollover are described in RFC7671
Section 8.  The short version is that a correctly operated service
will deploy dual TLSA records *ahead* of the introduction of a new
certificate with K2.  For example:

_443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K1)...>
_443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K2)...>

the actual introduction of (K2) happens *after* any cached TLSA
RRsets matching just K1 have expired.  Such "caching" includes any
delays in updating secondary nameservers + TTL of potentially stale
data delivered by secondary servers.  There are various ways of
handling this.  For example the TLSA RRset could include both a "3
1 1" record for the server key (KS) and a "2 1 1" for the issuer
key (KI):

_443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KS)...>
_443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KI)...>

If the server key KS is updated to KS' from the *same* issuer CA,
then the same TLSA RRset will still validate KS' via the shared
issuer key KI.  The hash matching KS can be replaced with the hash
matching KS' during the key rollover without worrying about DNS
caching delays.

When the issuing CA switches keys from KI to KI', the server operator
should obtain a new certificate for the *same* key KS, signed with
KI'.  And deploy that chain.  This time it continues to be valid
by matching KS.  Again DNS caching can be ignored and the TLSA
record update to match KI' concurrently with the issuer key rollover.

It may be useful to write a new DANE operational RFC, covering some
of the insights gained since the publication of 7671 section 8.

> It seems clear that if during the connection, the server negotiates the
> extension and provides this record but also key K2, I need to terminate
> the connection.

Yes.

> Now, consider what happens if I make an initial connection to the server
> and it provides K1, but immediately thereafter, I make a separate connection
> to the server and this time it does *not* negotiate the extension, and
> displays K2.

[ The subtext here is that the client is doing local DNS caching
  (normal DNS no pinning) based on the DNS TTL.  So it already knows
  the TLSA records, and does not even need to ask for the extension. ]

If the TTL on the previously provided TLSA RRs has not expired, the
client is free to apply those TLSA records, exactly as it would had
it (and it is free to try) obtained them via DNS rather than via the
extension.

> What happens then? It seems to me that there are two answers:
> 
> 1. Accept K2 (because it's WebPKI certified).

There's little point in doing that.  The client could perhaps proceed
after a user dialogue, or an audit event, on the grounds that some
attackers would hesitate at tamper-evident malfeasance, but that's
rather minimal benefit for the cost of doing DANE.  So the client
could continue as a matter of local policy, but generally should
not.

> 2. Reject K2 (because it doesn't match the TLSA record).

This is the expected behaviour with unexpired TLSA records matching
only K1.

> It seems like there are three things we could do:
> 
> 1. Forbid clients from applying TLSA records received in one TLS
>connection to another TLS connection. This would seem to violate
>the spirit of "this is just another way to deliver DNS records".

Yes, the violation of expectations is quite clear.  The client must
be at liberty to cache.  The TLSA record publisher gets to choose
suitably short TTLs, which the TLS server could further reduce at
its discretion (TTLs are of course not DNSSEC signed, only an uppper
bound on the TTL is covered by the RRSIG).

> 2. Require/encourage (for some 2119 level) that clients apply TLSA
>records for as long as tehy remain valid.

The client may of course, at its discretion, cap the TTL it obtains
from DNS at a maximum value lower than provided by the server.  A
client that does not cache TLSA records at all, effectively caps
the TTL at 0.  Clients are not obligated to cache, but may do so.
Caching amortizes the overhead of receiving and processing the
extension data on an initial connection over multiple subsequent
connections.  So caching should be encouraged, but is not required.

> 3. Say nothing.
> 
> We don't think (3) is acceptable. It's not

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

[Nico Williams]

On Wed, Jul 18, 2018 at 01:54:09AM -0700, Eric Rescorla wrote:
> On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni 
> wrote:
> >
> > c. Testing is not a good fit at this layer, all that's
> >pinned is the ability to deliver the extension, after a
> >previous connection delivered DANE TLSA records and a
> >non-zero extension support lifetime.  There is no TLS-layer
> >mechanism for the client to inform servers that don't
> >offer the extension that this extension was expected
> >while continuing the connection.  The closest we get is
> >the TLS 1.3 missing_extension(109) alert, which does not
> >carry the id of the mission extension, and is a failure
> >alert.  Out-of-band notification would require HTTP
> >support in applications that can't generally be expected
> >to include an HTTP implementation.
> >
> 
> To the extent to which this is true, it's an argument that one should be
> pinning at a different layer.

Whichever layer the pinning is to be done at, the thing to pin, and for
how long, all need to be transported, and since that thing is in TLS, so
should the "for how long".

Nico
-- 

___
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 Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque 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.

With a pin TTL in the extension the server operator can change it at
any time without further ado -- it's just a config file setting.

With a pin TTL in a DNS RR the server operator has to make a zone file
update.  That could be easy or not -- it varies.

> This could also express a generic DANE pinning capability that is not tied
> only to a TLS channel.

That's more like the other flavors of pinning we've been told have
rougher operations characteristics.

It's certainly true that we could specify and implement such a thing,
and that it would be useful for some applications.  However, it wouldn't
be as convenient as just the extension pinning in this case.

For example, with pinning to the extension + DoE, a server could
implement the extension asynchronously from deploying DANE.  In fact, it
could just be enabled by default, and always send DoE when you don't
have DANE deployed.  And then the moment you deploy DANE, presto, you're
protected.  And if you want to turn off pinning?  Just edit the server's
configuration file -- no need to go update the zone(s).

We should always look to make deployment easier, and extension pinning
does that more than a DANE pin DNS RR type would.

Surely we want our protocols to be deployable.

Nico
-- 

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