[TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Sean Turner]

All,

draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 [0], 
and the authors have been biding their time while the WG thrashed out TLS1.3s' 
issues.  At IETF 95, they presented again [1], but this time the chairs took a 
sense of the room about whether the WG was in favor of adopting the draft.  
According to the minutes, there were “crickets” against and “lots of noise” for 
adoption.  But, we need to take it to the list so please indicate whether you:

- Support adoption and are willing to review/comment on the draft by 201600429. 
 Note that the extensions is pretty straight forward, but the chairs still need 
people to comment on the draft as we’re processing it down the path.

- Object to the adoption of this draft as a WG item, please respond to the list 
indicating why by 201600510.

Cheers,

J&S

[0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf
[1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

[Sean Turner]

All,

draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed 
for TLS1.3.  We need to get these officially registered so the chairs would 
like to hear whether there is WG support for adopting 
draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you:

- Support adoption and are willing to review/comment on the draft by 201600429; 
the chairs still need people to review the draft to show there’s support for it 
as we process it down the path.

- Object to the adoption of this draft as a WG item, please respond to the list 
indicating why by 201600429.

Note 1: This draft will get published using the new rules we’ve been concocting 
on the list so the IANA considerations section will get tweaked as we settle on 
what words need to be included.

Note 2: The other option is to put the registrations in the TLS1.3 spec, but 
that would add four pages that I’m pretty sure no implementer is going to read 
so there seems to be little point in included the registrations in the TLS1.3 
spec.  And, these cipher suites do apply to TLS1.2.

Cheers,

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

Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

[Sean Turner]

sigh and here as well - they should have been 20160510.

spt

> On Apr 25, 2016, at 08:17, Sean Turner  wrote:
> 
> All,
> 
> draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed 
> for TLS1.3.  We need to get these officially registered so the chairs would 
> like to hear whether there is WG support for adopting 
> draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you:
> 
> - Support adoption and are willing to review/comment on the draft by 
> 201600429; the chairs still need people to review the draft to show there’s 
> support for it as we process it down the path.
> 
> - Object to the adoption of this draft as a WG item, please respond to the 
> list indicating why by 201600429.
> 
> Note 1: This draft will get published using the new rules we’ve been 
> concocting on the list so the IANA considerations section will get tweaked as 
> we settle on what words need to be included.
> 
> Note 2: The other option is to put the registrations in the TLS1.3 spec, but 
> that would add four pages that I’m pretty sure no implementer is going to 
> read so there seems to be little point in included the registrations in the 
> TLS1.3 spec.  And, these cipher suites do apply to TLS1.2.
> 
> Cheers,
> 
> J&S

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

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Paul Wouters]

On Mon, 25 Apr 2016, Sean Turner wrote:


draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 [0], 
and the authors have been biding their time while the WG thrashed out TLS1.3s' 
issues.  At IETF 95, they presented again [1], but this time the chairs took a 
sense of the room about whether the WG was in favor of adopting the draft.  
According to the minutes, there were “crickets” against and “lots of noise” for 
adoption.  But, we need to take it to the list so please indicate whether you:

- Support adoption and are willing to review/comment on the draft by 201600429. 
 Note that the extensions is pretty straight forward, but the chairs still need 
people to comment on the draft as we’re processing it down the path.


I support and will review the document. I think it is a great idea that
will help deploying DNSSEC and TLSA for browsers.

Paul

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

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Sean Turner]

I got the dates wrong.  They should both have been 20160510.

spt

> On Apr 25, 2016, at 08:12, Sean Turner  wrote:
> 
> All,
> 
> draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 
> [0], and the authors have been biding their time while the WG thrashed out 
> TLS1.3s' issues.  At IETF 95, they presented again [1], but this time the 
> chairs took a sense of the room about whether the WG was in favor of adopting 
> the draft.  According to the minutes, there were “crickets” against and “lots 
> of noise” for adoption.  But, we need to take it to the list so please 
> indicate whether you:
> 
> - Support adoption and are willing to review/comment on the draft by 
> 201600429.  Note that the extensions is pretty straight forward, but the 
> chairs still need people to comment on the draft as we’re processing it down 
> the path.
> 
> - Object to the adoption of this draft as a WG item, please respond to the 
> list indicating why by 201600510.
> 
> Cheers,
> 
> J&S
> 
> [0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf
> [1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf

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

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Russ Housley]

On Apr 25, 2016, at 11:19 AM, Paul Wouters  wrote:

> On Mon, 25 Apr 2016, Sean Turner wrote:
> 
>> draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 
>> [0], and the authors have been biding their time while the WG thrashed out 
>> TLS1.3s' issues.  At IETF 95, they presented again [1], but this time the 
>> chairs took a sense of the room about whether the WG was in favor of 
>> adopting the draft.  According to the minutes, there were “crickets” against 
>> and “lots of noise” for adoption.  But, we need to take it to the list so 
>> please indicate whether you:
>> 
>> - Support adoption and are willing to review/comment on the draft by 
>> 201600429.  Note that the extensions is pretty straight forward, but the 
>> chairs still need people to comment on the draft as we’re processing it down 
>> the path.
> 
> I support and will review the document. I think it is a great idea that
> will help deploying DNSSEC and TLSA for browsers.

+1

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

[TLS] Actions and issues from the IETF 95 TLS meeting

[Joseph Salowey]

Below are some of the more significant issues discussed at the meeting in
Buenos Aires:

1. Adopt David Benjamin's signature and hash algorithm negotiation
structure that ties both together.   New code points to define signature
algorithm, curve and hash as a unit.

- PR incorporated into draft - https://github.com/tlswg/tls13-spec/pull/404

2. Adopt Anti-Downgrade mechanism proposed by Green/Bhargavan.

- PR incorporated into draft - https://github.com/tlswg/tls13-spec/pull/284

3. Adopt a simplified NewSessionTicket Format.  The ticket format should
indicate if the server would accept ECDHE-PSK or PSK  and indicate if early
data is allowed or not.  The use of a bit mask was discussed in the
meeting.

- PR to be discussed on the list when available.

4.  Adopt proposal to add back encrypted extensions for early data.
Encrypted extensions provide application identification (ALPN) and elapsed
timestamp.

- PR to be discussed on the list when available.

5.  Adopt simplified more linear key separation derivation.

- PR to be discussed on the list when available.

6.  Adopt proposal for demuxing handshake message from data messages.  New
handshake key is derived to encrypt post initial handshake messages.
Proposed solution is to wrap encrypted handshake message in encrypted data
message.  This is pending cryptographic evaluation.

- PR to be discussed on the list when available.

7.  Adopt proposal to include OCSP stapling as part of certificate
messages.

- PR to be discussed on the list when available.

8.  Adopt proposal to allow server to send known groups (Issue 415).

- PR to be discussed on the list when available.

9.  Park proposal to add receive generation field in the key update so
client knows it is safe to release keys  (PR 426)

- We do not have consensus to move forward with this PR
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Viktor Dukhovni]

On Mon, Apr 25, 2016 at 08:12:17AM -0700, Sean Turner wrote:

> - Support adoption and are willing to review/comment on the draft

I support the adoption of this draft.

-- 
Viktor.

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

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Aaron Zauner]

> On 25 Apr 2016, at 22:12, Sean Turner  wrote:
> - Support adoption and are willing to review/comment on the draft by 
> 201600429.  Note that the extensions is pretty straight forward, but the 
> chairs still need people to comment on the draft as we’re processing it down 
> the path.

...

> 
> [0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf
> [1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf

This seems like a good idea. I support adoption of this draft.

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Salz, Rich]

I support adoption.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


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

[TLS] NewSessionTicketFormat - for PSK

[Jim Schaad]

I was looking at how TLS 1.3 was going to fit into an upgrade from the
existing 1.2 version that is used for RADIUS and having vague memories of
what was going on during the F2F meeting and I ended up with the following
question.

We are planning to indicate in the NewSessionTicket items such as if early
data is going to be allowed.  Do we need to make some statements someplace
about if early data is going to be accepted for a pure PSK (or PSK-ECDH)
configuration either as an marker that it needs to be configured into the
client or as a indication sent back from the server to the client that it
will or will not accept early data when connecting?   Does this apply to
some of the other fields that were being discussed as being encoded into the
ticket as well?

Jim


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

Re: [TLS] NewSessionTicketFormat - for PSK

[Eric Rescorla]

On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad  wrote:

> I was looking at how TLS 1.3 was going to fit into an upgrade from the
> existing 1.2 version that is used for RADIUS and having vague memories of
> what was going on during the F2F meeting and I ended up with the following
> question.
>
> We are planning to indicate in the NewSessionTicket items such as if early
> data is going to be allowed.  Do we need to make some statements someplace
> about if early data is going to be accepted for a pure PSK (or PSK-ECDH)
> configuration either as an marker that it needs to be configured into the
> client or as a indication sent back from the server to the client that it
> will or will not accept early data when connecting?


There is no way to do do early data with PSK-ECDH because the data is
encrypted under the PSK only.

-Ekr


 Does this apply to
> some of the other fields that were being discussed as being encoded into
> the
> ticket as well?
>
> Jim
>
>
> ___
> 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] NewSessionTicketFormat - for PSK

[Jim Schaad]

 

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday, April 25, 2016 11:10 AM
To: Jim Schaad 
Cc: tls@ietf.org
Subject: Re: [TLS] NewSessionTicketFormat - for PSK

 

 

 

On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

I was looking at how TLS 1.3 was going to fit into an upgrade from the
existing 1.2 version that is used for RADIUS and having vague memories of
what was going on during the F2F meeting and I ended up with the following
question.

We are planning to indicate in the NewSessionTicket items such as if early
data is going to be allowed.  Do we need to make some statements someplace
about if early data is going to be accepted for a pure PSK (or PSK-ECDH)
configuration either as an marker that it needs to be configured into the
client or as a indication sent back from the server to the client that it
will or will not accept early data when connecting?  

 

There is no way to do do early data with PSK-ECDH because the data is

encrypted under the PSK only.

 

-Ekr

 

What about the case of just pure PSK?  

 

I also assume that there is nothing to stop from getting a ticket if I connect 
using PSK to begin with.

 

Jim

 

 

 

 Does this apply to
some of the other fields that were being discussed as being encoded into the
ticket as well?

Jim


___
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] Call for WG adoption of draft-shore-tls-dnssec-chain-extension

[Daniel Migault]

I support the adoption of the draft.

On Mon, Apr 25, 2016 at 1:53 PM, Salz, Rich  wrote:

> I support adoption.
>
> --
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
>
>
> ___
> 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] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

[Andrei Popov]

I support adoption of this draft. No reason to limit ECDHE_PSK to CBC.

Cheers,

Andrei 

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner
Sent: Monday, April 25, 2016 8:22 AM
To: tls 
Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead

sigh and here as well - they should have been 20160510.

spt

> On Apr 25, 2016, at 08:17, Sean Turner  wrote:
> 
> All,
> 
> draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed 
> for TLS1.3.  We need to get these officially registered so the chairs would 
> like to hear whether there is WG support for adopting 
> draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you:
> 
> - Support adoption and are willing to review/comment on the draft by 
> 201600429; the chairs still need people to review the draft to show there’s 
> support for it as we process it down the path.
> 
> - Object to the adoption of this draft as a WG item, please respond to the 
> list indicating why by 201600429.
> 
> Note 1: This draft will get published using the new rules we’ve been 
> concocting on the list so the IANA considerations section will get tweaked as 
> we settle on what words need to be included.
> 
> Note 2: The other option is to put the registrations in the TLS1.3 spec, but 
> that would add four pages that I’m pretty sure no implementer is going to 
> read so there seems to be little point in included the registrations in the 
> TLS1.3 spec.  And, these cipher suites do apply to TLS1.2.
> 
> Cheers,
> 
> J&S

___
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] NewSessionTicketFormat - for PSK

[Eric Rescorla]

On Mon, Apr 25, 2016 at 12:13 PM, Jim Schaad  wrote:

>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Monday, April 25, 2016 11:10 AM
> *To:* Jim Schaad 
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] NewSessionTicketFormat - for PSK
>
>
>
>
>
>
>
> On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad 
> wrote:
>
> I was looking at how TLS 1.3 was going to fit into an upgrade from the
> existing 1.2 version that is used for RADIUS and having vague memories of
> what was going on during the F2F meeting and I ended up with the following
> question.
>
> We are planning to indicate in the NewSessionTicket items such as if early
> data is going to be allowed.  Do we need to make some statements someplace
> about if early data is going to be accepted for a pure PSK (or PSK-ECDH)
> configuration either as an marker that it needs to be configured into the
> client or as a indication sent back from the server to the client that it
> will or will not accept early data when connecting?
>
>
>
> There is no way to do do early data with PSK-ECDH because the data is
>
> encrypted under the PSK only.
>
>
>
> -Ekr
>
>
>
> What about the case of just pure PSK?
>
>
>
> I also assume that there is nothing to stop from getting a ticket if I
> connect using PSK to begin with.
>

Yes... Maybe I'm missing your point

-Ekr


>
> Jim
>
>
>
>
>
>
>
>  Does this apply to
> some of the other fields that were being discussed as being encoded into
> the
> ticket as well?
>
> Jim
>
>
> ___
> 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