Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Joseph Salowey]

The chairs are forwarding this document to our AD to progress towards
publication.

Cheers,

Joe

On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey  wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> Hi,
>>
>> Thank you for the review and comments received. Given the discussion our
>> understanding was that the consensus was to remove CCM-256 so that suites
>> defined by the document apply both for TLS1.2 as well as for TLS1.3. The
>> draft available on github [1
>> ]
>> has been updated as follows:
>>
>>
>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>
>> MGLT: This was a mistake in the IANA section. The cypher suite was
>> correct in the remaining text. However, the current version does not
>> consider anymore CCM-256* which also solves this issue.
>>
>> 2.  Since the security considerations mention passwords (human chosen
>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>
>> MGLT: The issue of human chosen passwords and dictionary attacks has been
>> mentioned in the security consideration with the following text:
>>
>> """
>>Use of Pre-Shared Keys of limited entropy may allow an active
>>attacker attempts to connect to the server and tries different keys.
>>For example, limited entropy may be provided by using short PSK in
>>which case an attacker may perform a brute-force attack.  Other
>>example includes the use of a PSK chosen by a human and thus may be
>>exposed to dictionary attacks.
>> """
>>
>>
>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>> than necessary.
>>
>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>> 1.3 specification.
>>
>> MGLT: CCM-256 has been removed from the specification so that suites can
>> be defined for TLS 1.2 as well as TLS1.3. The following text is considered.
>>
>> """
>>This document defines new cipher suites that provide Pre-Shared Key
>>(PSK) authentication, Perfect Forward Secrecy (PFS), and
>>Authenticated Encryption with Associated Data (AEAD).  The cipher
>>suites are defined for version 1.2 of the Transport Layer Security
>>(TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>[I-D.ietf-tls-tls13].
>> """
>>
>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>> section 4 that states:
>>
>> "TLS 1.3 and above name, negotiate and support a subset of these cipher
>> suites in a different way."  (TLS 1.3 does not support
>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM
>> _8_SHA256)
>>
>> MGLT: As CCM-256 has been removed, we do not have to deal with the
>> situation where TLS1.3 only considers a subset of the suites defined for
>> TLS1.2.
>>
>> The following sentence in section 3 clarifies that codes points are only
>> defined for TLS1.2: “””The assigned code points can only be used for TLS
>> 1.2.”””. The description of the TLS1.3 negotiation has been limited in
>> section 4 to the following sentence: “””TLS 1.3 and above version,
>> negotiate and support these cipher suites in a different way.”””
>>
>> 4. Section 3 should contain a bit more detail about relationship to 4492
>> bis and RFC 4279:
>>
>> Something like the following may be enough.
>>
>> "This messages and pre-master secret construction in this document are
>> based on [RFC4279].  The elliptic curve parameters used in in the
>> Diffie-Hellman parameters are negotiated using extensions defined in
>> [4492-bis]."
>>
>> MGLT: The sentence mentioned above has been added with [4492-bis]
>> mentioned as normative.
>> “””
>> Messages and pre-master secret construction in this document are
>>based on [RFC4279].  The elliptic curve parameters used in in the
>>Diffie-Hellman parameters are negotiated using extensions defined in
>>[I-D.ietf-tls-rfc4492bis].
>> “””
>>
>> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/m
>> aster/draft-ietf-tls-ecdhe-psk-aead
>>
>> Yours,
>> Daniel and John
>>
>>
>> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  wrote:
>>
>>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>>>
>>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>>
>>> 2.  Since the security considerations mention passwords (human chosen
>>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>>
>>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>>> than necessar

[TLS] GH repo for draft-rescorla-tls-dtls13

[Sean Turner]

We’ve created a GH rep for the DTLS1.3 draft @ 
https://github.com/tlswg/dtls13-spec

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

[Sean Turner]

Thanks!

spt

> On Apr 28, 2017, at 12:50, Eric Rescorla  wrote:
> 
> Draft submitted (it should be identical to the individual submission)
> 
> -Ekr
> 
> 
> On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner  wrote:
> It’s now the 7th so the call for adoption is complete.  Though Ben was the 
> only commenter on list (and thanks Ben) there was definitely support for 
> adopting this draft at the Chicago session.  This bit of administrivia is 
> complete so authors feel free to submit a WG version at your leisure.  I’ve 
> pre-approved "draft-ietf-tls-dtls13" as the draft's name and created a github 
> repo: https://github.com/tlswg/dtls13-spec.
> 
> spt
> 
> > On Mar 22, 2017, at 18:50, Sean Turner  wrote:
> >
> > All,
> >
> > -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2].  It’s 
> > now at version -01 and GH issues are slowly rolling in.  It’s also on our 
> > agenda again at IETF 98, and DTLS a chartered work item, so it seems like 
> > it’s time to get the WG adoption process started for this individual draft. 
> >  Please let the list know whether you support adoption of the draft and are 
> > willing to review/comment on the draft before 20170406.  If you object to 
> > its adoption, please let us know why.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://github.com/ekr/dtls13-spec
> > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13
> > [2] https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-13-01.pdf
> 
> ___
> 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] WG review of draft-ietf-tls-rfc4492bis

[Sean Turner]

Thanks to MT and Ben for their reviews.  Joe and I have asked Kathleen to 
progress this draft towards the “approved” state.

spt

> On Apr 11, 2017, at 09:09, Sean Turner  wrote:
> 
> All,
> 
> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree 
> with Yoav’s statement at the mic in Chicago that the WG should review the 
> changes before we ask Kathleen (our newly appointed AD) to continue 
> progressing the draft.  Please review the differences from the -12 version 
> that went through WGLC and the latest version [0] and let us know by 20170426 
> whether there is anything that would stop progression of the draft.
> 
> Thanks,
> 
> J&S
> 
> [0] 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-rfc4492bis-12&url2=draft-ietf-tls-rfc4492bis-16

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

[TLS] Fwd: Publication has been requested for draft-ietf-tls-tls13-20

[Sean Turner]

Note that I’ve requested Kathleen begin her AD review.

For those not in the know about IETF process, there’s still a two-week IETF LC 
after Kathleen’s review so if anything earth shattering gets uncovered we can 
still address it before it gets to the IESG.

spt

> Begin forwarded message:
> 
> From: Sean Turner 
> Subject: Publication has been requested for draft-ietf-tls-tls13-20
> Date: April 28, 2017 at 16:49:53 EDT
> To: 
> Cc: Sean Turner , iesg-secret...@ietf.org, 
> tls-cha...@ietf.org, s...@sn3rd.com
> 
> Sean Turner has requested publication of draft-ietf-tls-tls13-20 as Proposed 
> Standard on behalf of the TLS working group.
> 
> Please verify the document's state at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
> 

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

Re: [TLS] Key update routine

[Ken Ivanov]

Hi Ilari

I see your point, thank you. Maybe we shall think about replacing the MUST 
(in 'then the receiver MUST send a KeyUpdate of its own') with SHOULD then, 
not to lead the originator into confusion about the mutual nature of the key 
update, and treat the 'request_update' parameter as a suggestion rather than 
a request? Besides taking the question of enforcing that MUST off the scene, 
this would level the things up and make each direction truly independent.


Ken



-Original Message- 
From: Ilari Liusvaara

Sent: Friday, April 28, 2017 8:03 PM
To: Ken Ivanov
Cc: tls@ietf.org
Subject: Re: [TLS] Key update routine

On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote:

Hi Eric and everyone,

Specifically, while the spec instructs the party that receives a KeyUpdate
with its request_update set to update_requested to respond with its own
KeyUpdate with request_update set to update_not_requested, there are no
provisions as to what the originator of the key update should do if it 
never
receives the requested KeyUpdate response from the remote party (or does 
not

receive it within a reasonable time scope).


The problem is that any time bound would cause keyupdate to couple the
directions, which is harmful from API standpoint.

The KeyUpdate mechanism is explicitly designed for fully asynchronous
operation. Which impiles there is no time bound.



-Ilari 


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

Re: [TLS] Session ticket (re-)use in multi-process applications?

[Viktor Dukhovni]

> On Apr 28, 2017, at 2:29 PM, Eric Rescorla  wrote:
> 
>> What does this mean in practice?  What happens if Postfix continues to use 
>> the
>> same ticket multiple times anyway?  Will servers somehow invalidate the 
>> ticket
>> after first use?  Are the consequences of reuse more severe than with TLS 
>> 1.2?
> 
> Shouldn't be. Mostly, it allows attackers to correlate multiple sessions from 
> the same
> client, which sounds like it's not an issue in your case.

Well, the server 220 banner, client EHLO command and server 250 EHLO response 
that
precede STARTTLS pretty much take care of correlating sessions from the same 
client.

Also SMTP is not usually tunneled through proxies, and there is no issue 
similar to
identifying which HTTP pages a client is loading by correlating multiple 
requests.
Each message delivery is independent.

Just the client and server IP addresses leak essentially all the data of 
interest.
The only thing not leaked by these is leaked via SNI and DNS MX lookups.

So I take it that reuse would (in this case) be reasonably harmless.
So I can use the "latest" tickets as often as it remains the "latest"
ticket.  And servers will likely cooperate?

The only change might then be that I might see a much higher rate of session
updates as each handshake obtains another new ticket?  Unless of course whether
to issue a new ticket, or let the current ticket stand is left to the 
application.

This raises an interoperability question:

* Should SMTP servers always issue a new ticket when a client resumes a
  session with an existing ticket?

On the one hand, a lot of churn can be saved if the server can replace only
tickets that are close to expiring.

On the other hand, if most clients follow the draft recommendation and discard
tickets on first use, then not issuing a replacement ticket each time will mean
that each session will be resumed just once, and 50% of connections will incur
the cost of a full handshake.

Is the question of whether/when to issue new tickets expected to be part of
an "application profile"?  Do we need a TLS 1.3 application profile for SMTP?
Or just issue a fresh ticket on every resumption?

-- 
Viktor.

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

Re: [TLS] Key update routine

[Ilari Liusvaara]

On Fri, Apr 28, 2017 at 07:41:59PM +0100, Ken Ivanov wrote:
> Hi Eric and everyone,
> 
> Specifically, while the spec instructs the party that receives a KeyUpdate
> with its request_update set to update_requested to respond with its own
> KeyUpdate with request_update set to update_not_requested, there are no
> provisions as to what the originator of the key update should do if it never
> receives the requested KeyUpdate response from the remote party (or does not
> receive it within a reasonable time scope).

The problem is that any time bound would cause keyupdate to couple the
directions, which is harmful from API standpoint.

The KeyUpdate mechanism is explicitly designed for fully asynchronous
operation. Which impiles there is no time bound.



-Ilari

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

[TLS] Key update routine

[Ken Ivanov]

Hi Eric and everyone,

Glad to meet you all here in this group.

I've been working my way through the latest TLS 1.3 draft (the 20th), and I 
hope you wouldn't mind me putting in my 2p about the key update routine.


While section 4.6.3 (Key and IV update) provides good insight as to what the 
implementations should do if everything goes right, it is unclear on what 
they should do if something goes wrong.


Specifically, while the spec instructs the party that receives a KeyUpdate 
with its request_update set to update_requested to respond with its own 
KeyUpdate with request_update set to update_not_requested, there are no 
provisions as to what the originator of the key update should do if it never 
receives the requested KeyUpdate response from the remote party (or does not 
receive it within a reasonable time scope).


As, following the spec, the originator will be prepared to, I'm going to 
quote it here, 'receive an arbitrary number of messages between sending a 
KeyUpdate with request_update set to update_requested and receiving the peer’s 
KeyUpdate, because those messages may already be in flight,' I am afraid 
this might lead to various implementation mistakes where the implementations 
will simply wait for the KeyUpdate response to come in infinitely, thus 
creating a security flaw (the inbound key may never get actually updated). I 
guess we need clearer rules here, for the sabotage of the remote party to 
participate in the key update routine wasn't tolerated.


We probably also need a well-defined cap on how many key update requests are 
allowed to be sent within a given time frame, as excessive key update 
requests from clients may consume valuable server resources. Such cap will 
also be helpful against buggy implementations which will always be 
responding to the other's KeyUpdate messages with their own request_update 
set to update_requested, effectively creating an endless loop of key 
updates.


Hope this makes sense.

Thanks in advance.

Kind regards,

Ken Ivanov
EldoS Corporation 


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

Re: [TLS] Session ticket (re-)use in multi-process applications?

[Eric Rescorla]

On Fri, Apr 28, 2017 at 11:20 AM, Viktor Dukhovni 
wrote:

>
> Unlike many/most browsers, Postfix makes each TLS connection from a
> separate smtp(8) client process.
>
> TLS session reuse is supported via a shared service process tlsmgr(8)
> which maintains a cache of
> saved sessions for peer destinations that have provided session resumption
> data (session tickets,
> or just a session id).
>
> Once a session is saved into the session database, it is used by multiple
> clients until it
> expires (with TLS <= 1.2, resumption typically does not create a new
> session, and the same
> session remains in the cache).
>
> How should this change with TLS 1.3?  The draft says:
>
>Clients SHOULD attempt to use each
>ticket no more than once, with more recent tickets being used first.
>
> What does this mean in practice?  What happens if Postfix continues to use
> the
> same ticket multiple times anyway?  Will servers somehow invalidate the
> ticket
> after first use?  Are the consequences of reuse more severe than with TLS
> 1.2?
>

Shouldn't be. Mostly, it allows attackers to correlate multiple sessions
from the same
client, which sounds like it's not an issue in your case.


To avoid re-use, it would seem that tlsmgr(8) would have to delete the
> ticket
> from the cache after vending it to an smtp(8) client.  For the cache to
> work
> at all well, with sessions consistently resumed after an initial ramp-up,
> it
> would seem that the cache would now need to store a list of tickets, rather
> than just a single ticket for each destination.  If so, that's considerable
> new complexity. :-(
>

Well, the idea is that the server gives you a new ticket on each handshake,
so that
you don't have to reuse.


When resuming with a TLS 1.3 peer, what happens if the peer is behind a load
> balancer, and some of the nodes are still TLS 1.2?  Does the handshake
> fail,
> or we somehow end-up doing a full TLS 1.2 handshake?
>

You should get a TLS 1.2 handshake, modulo bugs.

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

[TLS] Session ticket (re-)use in multi-process applications?

[Viktor Dukhovni]

Unlike many/most browsers, Postfix makes each TLS connection from a separate 
smtp(8) client process.

TLS session reuse is supported via a shared service process tlsmgr(8) which 
maintains a cache of
saved sessions for peer destinations that have provided session resumption data 
(session tickets,
or just a session id).

Once a session is saved into the session database, it is used by multiple 
clients until it
expires (with TLS <= 1.2, resumption typically does not create a new session, 
and the same
session remains in the cache).

How should this change with TLS 1.3?  The draft says:

   Clients SHOULD attempt to use each
   ticket no more than once, with more recent tickets being used first.

What does this mean in practice?  What happens if Postfix continues to use the
same ticket multiple times anyway?  Will servers somehow invalidate the ticket
after first use?  Are the consequences of reuse more severe than with TLS 1.2?

To avoid re-use, it would seem that tlsmgr(8) would have to delete the ticket
from the cache after vending it to an smtp(8) client.  For the cache to work
at all well, with sessions consistently resumed after an initial ramp-up, it
would seem that the cache would now need to store a list of tickets, rather
than just a single ticket for each destination.  If so, that's considerable
new complexity. :-(

I'd need to prepend tickets to the cache slot, rather than replace the cache
slot, and trim tickets from the end if the list of available tickets grows
too long.  Then when a client asks for a ticket, pop the first entry of the
list.

This design would have to coexist with the existing support for TLS <= 1.2
session resumption.  So some cache slots would be single-instance multi-use,
and others multi-instance single-use.

When resuming with a TLS 1.3 peer, what happens if the peer is behind a load
balancer, and some of the nodes are still TLS 1.2?  Does the handshake fail,
or we somehow end-up doing a full TLS 1.2 handshake?

(Postfix will in many cases "see through" load-balancers, because STARTTLS
is preceded by the peer's SMTP banner and EHLO response which include a
notional remote server name, and when that's server-specific, I use a
separate cache entry for each server).

I'll also need to figure out how all of this plays out in the new OpenSSL
1.1.1 code and its "new session" callbacks.

Unlike most other TLS 1.3 changes, this one is not going to be particularly
transparent to the application, unless ignoring the "SHOULD" and just
reusing session tickets works against peer servers and within the updated
OpenSSL "new session" callback implementation.

Obviously, the OpenSSL-specific issues I'll be hashing out elsewhere, just
mentioning that there are API implications to changes in how resumption is
to be handled...

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

[Eric Rescorla]

Draft submitted (it should be identical to the individual submission)

-Ekr


On Fri, Apr 7, 2017 at 2:14 PM, Sean Turner  wrote:

> It’s now the 7th so the call for adoption is complete.  Though Ben was the
> only commenter on list (and thanks Ben) there was definitely support for
> adopting this draft at the Chicago session.  This bit of administrivia is
> complete so authors feel free to submit a WG version at your leisure.  I’ve
> pre-approved "draft-ietf-tls-dtls13" as the draft's name and created a
> github repo: https://github.com/tlswg/dtls13-spec.
>
> spt
>
> > On Mar 22, 2017, at 18:50, Sean Turner  wrote:
> >
> > All,
> >
> > -00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2].
> It’s now at version -01 and GH issues are slowly rolling in.  It’s also on
> our agenda again at IETF 98, and DTLS a chartered work item, so it seems
> like it’s time to get the WG adoption process started for this individual
> draft.  Please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170406.  If you
> object to its adoption, please let us know why.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://github.com/ekr/dtls13-spec
> > [1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13
> > [2] https://www.ietf.org/proceedings/97/slides/slides-
> 97-tls-dtls-13-01.pdf
>
> ___
> 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] I-D Action: draft-ietf-tls-dtls13-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Authors : Eric Rescorla
  Hannes Tschofenig
  Nagendra Modadugu
Filename: draft-ietf-tls-dtls13-00.txt
Pages   : 36
Date: 2017-04-28

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-00
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[TLS] draft-ietf-tls-tls13-20 is up

[Eric Rescorla]

This version incorporates the WGLC feedback and discussions in Chicago.

Changes in -20:

- Add "post_handshake_auth" extension to negotiate post-handshake
authentication
  (*).

- Shorten labels for HKDF-Expand-Label so that we can fit within one
  compression block (*).

- Define how RFC 7250 works (*).

- Re-enable post-handshake client authentication even when you do PSK.
  The previous prohibition was editorial error.

- Remove cert_type and user_mapping, which don't work on TLS 1.3 anyway.

- Added the no_application_protocol alert from {{RFC7301}} to the list
  of extensions.

- Added discussion of traffic analysis and side channel attacks.


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

[TLS] I-D Action: draft-ietf-tls-tls13-20.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

Title   : The Transport Layer Security (TLS) Protocol Version 
1.3
Author  : Eric Rescorla
Filename: draft-ietf-tls-tls13-20.txt
Pages   : 137
Date: 2017-04-28

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-20
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-20


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-01.txt

[Sean Turner]

All,

Joe and I updated the draft. GH repo is @:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates

Note that I’d to rewrite the introduction to be briefer and move the rationale 
for the changes to the section where the change is suggested.  I think this 
will make it easier to review, i.e., there will be less scrolling around trying 
to remember why the change was made.

And, I’ll need to fix the non-wrapping notes :/

After these two changes, I think this one will be ready for WGLC.

spt

> On Apr 28, 2017, at 08:51, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security of the IETF.
> 
>Title   : D/TLS IANA Registry Updates
>Authors : Joe Salowey
>  Sean Turner
>   Filename: draft-ietf-tls-iana-registry-updates-01.txt
>   Pages   : 13
>   Date: 2017-04-28
> 
> Abstract:
>   This document changes the IANA registry policy for a number of
>   registries related to DTLS and TLS, renames some of the registries
>   for consistency, and adds notes to many of the registries.  As a
>   result, this document updates many RFCs (see updates header).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-01
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] I-D Action: draft-ietf-tls-iana-registry-updates-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

Title   : D/TLS IANA Registry Updates
Authors : Joe Salowey
  Sean Turner
Filename: draft-ietf-tls-iana-registry-updates-01.txt
Pages   : 13
Date: 2017-04-28

Abstract:
   This document changes the IANA registry policy for a number of
   registries related to DTLS and TLS, renames some of the registries
   for consistency, and adds notes to many of the registries.  As a
   result, this document updates many RFCs (see updates header).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-01
https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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