[TLS] Deprecating alert levels

2016-10-14 Thread Kyle Nekritz 
After PR #625 all alerts are required to be sent with fatal AlertLevel except 
for close_notify, end_of_early_data, and user_canceled. Since those three 
alerts all have separate specified behavior, the AlertLevel field is not 
serving much purpose, other than providing potential for misuse. We (Facebook) 
currently receive a number of alerts at incorrect levels from clients 
(internal_error warning alerts, etc.). I propose deprecating this field to 
simplify implementations and require that any misuse be ignored.

PR: https://github.com/tlswg/tls13-spec/pull/693

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

Re: [TLS] Newcomer’s Implementation Experience of TLS 1.3 Draft 16

2016-10-14 Thread Ilari Liusvaara 
On Fri, Oct 14, 2016 at 05:10:01PM +0200, Hubert Kario wrote:
> On Thursday, 13 October 2016 23:33:19 CEST Ilari Liusvaara wrote:
> > Ok, dumped the handshake using wireshark. Wireshark seems to think
> > the SNI with two lengths is perfectly sane.
> 
> that's because wireshark doesn't perform length checks on many fields of TLS
> 
> There are both valid messages rejected by wireshark (fragmented over multiple 
> records) and invalid messages accepted by wireshark.

Actually, AFAICT, the message was encoded like it should (one length
from the outer list length and one from the name length, as specified
by the TLS standard).


-Ilari

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

Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?

2016-10-14 Thread Ilari Liusvaara 
On Fri, Oct 14, 2016 at 05:15:48PM +0200, Hubert Kario wrote:
> On Friday, 14 October 2016 14:34:49 CEST Kazuho Oku wrote:
> > Considering that, to me it seems preferable if the draft stated that
> > both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in
> > certificates. Or is there any need to handle PKCS1 and SHA1
> > differently in protocol implementations?
> 
> there isn't, the only case is when you also implement TLSv1.2
> 
> Pure TLSv1.3 implementation shouldn't ever generate messages or try to verify 
> messages signed with SHA-1 (or MD5 for that matter)

Unfortunately while one sees less and less use of SHA-1 as certificates
expire, there still is use of SHA-1 in OCSP. The only place where my
TLS library uses SHA-1 is with OCSP.


-Ilari

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

Re: [TLS] Which SHA function should I use for CertificateVerify of a rsa_pkcs1_sha1 certificate?

2016-10-14 Thread Hubert Kario 
On Friday, 14 October 2016 14:34:49 CEST Kazuho Oku wrote:
> Considering that, to me it seems preferable if the draft stated that
> both PKCS1 and SHA1 are obsoleted, and are allowed to be only used in
> certificates. Or is there any need to handle PKCS1 and SHA1
> differently in protocol implementations?

there isn't, the only case is when you also implement TLSv1.2

Pure TLSv1.3 implementation shouldn't ever generate messages or try to verify 
messages signed with SHA-1 (or MD5 for that matter)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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] Application layer interactions and API guidance

2016-10-14 Thread Watson Ladd 
On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson
 wrote:
> On 11 October 2016 at 07:57, Kyle Rose  wrote:
>> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
>> that the web is substantially broken without retry logic in the browsers,
>> that naturally make application-level replay mitigation a necessity. But I
>> don't think (nor do I think he claimed) that the same is true of all
>> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be
>> okay for browsers in particular given the other constraints under which they
>> operate, it is probably not good to bake that into the API for the general
>> case.
>
> The 0-RTT API in NSS allows a server to detect this transition.  The
> problem that I think David was referring to is that the specific
> instant of the transition is lost when the multiple layers of stack
> that sit on top of TLS get involved.
>
> If an HTTP client sends a request that relies on HPACK state that was
> established during 0-RTT, is it a 0-RTT request?  I'm going to go with
> probably not.
>
> If an HTTP client sends the first octets of a message in 0-RTT but
> completes the request after the handshake completes, is it 0-RTT?  I
> suspect that this again is not a concern.
>
> I agree that we should make it clear that 0-RTT data needs to be
> treated specially.  I would like to see someone propose some text
> rather than read more vague emails on the subject.

See https://github.com/tlswg/tls13-spec/pull/694. This is for API
guidance rather than applications, and definitely needs expansion. I
don't think we can say anything about HTTP without more details.



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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