Re: [TLS] Recommended yes->no for max_fragment_length extension?

[Sean Turner]

Just a reminder ...

> On Feb 7, 2018, at 15:33, Sean Turner  wrote:
> 
> All,
> 
> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs to 
> confirm that draft-ietf-tls-record-limit should change max_fragment_length 
> [1] from “Yes” in our soon to be created Recommended column (see [2]) to a 
> “No”.  Please indicate by 2359 UTC on 14 Feb whether you are for or against 
> this change; and if you are against please indicate why.
> 
> spt
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/
> [1] https://datatracker.ietf.org/doc/rfc6066/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Martin Thomson]

On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
 wrote:
> What's the behavior when the middlebox is a proxy, let's say existing
> a managed network?  I presume from from section 3.1 that this
> negotiation doesn't work in that instance unless sites configured for
> this are not subject to the proxy as is often done for financial site
> access from corporate networks.  It would be good to know if it does
> work and that is addressed with the text Mirja calls out for her #1
> question.  Having this clarified could be helpful.

If there is a MitM, then this extension simply isn't negotiated.
That's pretty well understood.  I don't see why that requires special
mention.

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty]

On Thu, Feb 8, 2018 at 9:32 AM, Shumon Huque  wrote:
> On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop  wrote:
>>
>> Op 08-02-18 om 03:27 schreef Shumon Huque:
>> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > > > wrote:
>> >
>> > Mirja Kühlewind has entered the following ballot position for
>> > draft-ietf-tls-dnssec-chain-extension-06: No Objection
>> >
>> >
>> > --
>> > COMMENT:
>> >
>> > --
>> >
>> > Two minor, mostly editorial comments:
>> >
>> > 1) Intro (sec 2): " It also provides the
>> >ability to avoid potential problems with TLS clients being unable
>> > to
>> >look up DANE records because of an interfering or broken
>> > middlebox on
>> >the path between the client and a DNS server."
>> > Is that actually a well-known problem (can you provide a reference?)
>> >
>> >
>> > Some folks (at Google and NLnet Labs if I recall; maybe others) have
>> > done
>> > measurements to show this is an actual problem -- for a relatively small
>> > but
>> > still non-trivial fraction of clients. We'll try to see if we can dig up
>> > specific
>> > references to documents that could be cited.
>>
>> I wouldn't call it a relatively small fraction :)  DNSSEC is severely
>> hampered for end-entities by broken infrastructure in many different
>> ways.  Sometimes an upstream resolver can be used for positive DNSSEC
>> answers (i.e. existing records), but not for non-existent or wildcard
>> answers, because it simply doesn't forward the NSEC(3) proof for it.
>>
>>
>>
>> The last measurements we at NLnet Labs did was in July 2015:
>>
>> Gorjón, Xavier Torrent, and Willem Toorop.
>> "Discovery method for a DNSSEC validating stub resolver."
>> (2015)
>>
>> https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf
>>
>> Measurements were done with RIPE Atlas, with at the time +-8200 probes.
>> At the time only 56% of probes received enough DNSSEC data from their
>> upstreams to be able to perform DNSSEC validation for both positive and
>> non-existent answers (required for DANE).
>
>
> Ah, thanks. I'd forgotten that it was so high!
>
> I think my "relatively small" comment was recalling an earlier study (I
> think by
> Google) that saw a breakage of around ~ 5%, but I think that was just
> measuring
> the ability to lookup and obtain less common RR types and did not measure
> ability
> to perform full DNSSEC validation.

What's the behavior when the middlebox is a proxy, let's say existing
a managed network?  I presume from from section 3.1 that this
negotiation doesn't work in that instance unless sites configured for
this are not subject to the proxy as is often done for financial site
access from corporate networks.  It would be good to know if it does
work and that is addressed with the text Mirja calls out for her #1
question.  Having this clarified could be helpful.

Thanks.

>
> Shumon.
>



-- 

Best regards,
Kathleen

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