[TLS] Fwd: [rfc-dist] RFC 7983 on Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)

2016-09-29 Thread Gonzalo Salgueiro (gsalguei) 
Forwarding for awareness to the other relevant WGs. Thanks to all who helped 
get this done.

Cheers,

Gonzalo

Begin forwarded message:

From: >
Subject: [rfc-dist] RFC 7983 on Multiplexing Scheme Updates for Secure 
Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer 
Security (DTLS)
Date: September 29, 2016 at 7:40:41 PM EDT
To: >, 
>
Cc: >, 
>, 
>

A new Request for Comments is now available in online RFC libraries.


   RFC 7983

   Title:  Multiplexing Scheme Updates for Secure
   Real-time Transport Protocol (SRTP) Extension for
   Datagram Transport Layer Security (DTLS)
   Author: M. Petit-Huguenin, G. Salgueiro
   Status: Standards Track
   Stream: IETF
   Date:   September 2016
   Mailbox:m...@petit-huguenin.org,
   gsalg...@cisco.com
   Pages:  13
   Characters: 24894
   Updates:RFC 5764

   I-D Tag:draft-ietf-avtcore-rfc5764-mux-fixes-11.txt

   URL:https://www.rfc-editor.org/info/rfc7983

   DOI:http://dx.doi.org/10.17487/RFC7983

This document defines how Datagram Transport Layer Security (DTLS),
Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),
Session Traversal Utilities for NAT (STUN), Traversal Using Relays
around NAT (TURN), and ZRTP packets are multiplexed on a single
receiving socket.  It overrides the guidance from RFC 5764 ("SRTP
Extension for DTLS"), which suffered from four issues described and
fixed in this document.

This document updates RFC 5764.

This document is a product of the Audio/Video Transport Core Maintenance 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to 
rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
rfc-dist mailing list
rfc-d...@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-29 Thread Hannes Tschofenig 
Hi Ryan,

people working in the security field know what features TLS provides and
those are highly valued since otherwise it wouldn't be used so widely.

I prefer to finalize the work on TLS 1.3 as planned. There are various
groups successfully working on their implementations and I am looking
forward to a well-attended Hackathon at the next IETF meeting.

Ciao
Hannes


On 09/29/2016 09:01 AM, Ryan Carboni wrote:
> I've never quite understood what TLS was supposed to be protecting
> against, and whether or not it has done so successfully, or has the
> potential to do so successfully.
> 
> Well, I don't think anyone here even knows how to protect a mailing list
> from multi-billion dollar threat actors so...???
> 
> Let me quote RFC 3526: 
> "The
>strengths of the groups defined here are always estimates and there
>are as many methods to estimate them as there are cryptographers."
> 
> But whatever. You people aren't even willing to do what the Germans
> did... twice.
> 
> Personally I think TLS should be scrapped, replaced with a protocol
> without negotiation, replace PKI with trusted notaries
> ( https://en.wikipedia.org/wiki/Convergence_(SSL) ), etc.
> 
> But, no one has been able to program anything correctly, not even
> certificate authorities: 
> 
> https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com
> 
> I'm not paying you people anyway. At least the protocol is theoretically
> secure.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-29 Thread Ryan Carboni 
I've never quite understood what TLS was supposed to be protecting against,
and whether or not it has done so successfully, or has the potential to do
so successfully.

Well, I don't think anyone here even knows how to protect a mailing list
from multi-billion dollar threat actors so...???

Let me quote RFC 3526:
"The
   strengths of the groups defined here are always estimates and there
   are as many methods to estimate them as there are cryptographers."

But whatever. You people aren't even willing to do what the Germans did...
twice.

Personally I think TLS should be scrapped, replaced with a protocol without
negotiation, replace PKI with trusted notaries (
https://en.wikipedia.org/wiki/Convergence_(SSL) ), etc.

But, no one has been able to program anything correctly, not even
certificate authorities:

https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com

I'm not paying you people anyway. At least the protocol is theoretically
secure.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls